BSP question: nested interrupts?

[Ben Gras]

Ok, so the same interrupt will never nest itself then?

Good, thanks!


On Mon, Apr 28, 2014 at 2:14 PM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 2014-04-28 13:32, Ben Gras wrote:
>
>> Dear all,
>>
>> I have a question about managing interrupts in a BSP that I have not been
>> able
>> to answer satisfactorily by looking at other BSP code, nor looking
>> throught the
>> documentation or googling. Or asking on the IRC channel :)
>>
>> My question is: are BSPs expected to allow nested interrupts?
>> Specifically,
>> must bsp_interrupt_dispatch() turn interrupts on before calling
>> bsp_interrupt_handler_dispatch for everything else to work properly?
>>
>
> If you want nested interrupts, then you can do it like this BSP:
>
> http://git.rtems.org/rtems/tree/c/src/lib/libbsp/arm/
> lpc24xx/irq/irq-dispatch.c
>
>
>
>> Some BSPs do this, some don't. In the Beagle BSP I can do this by masking
>> the
>> currently active interrupt and then enabling them at the CPU level; but
>> enabling all interrupts before the hw-specific handler is called won't
>> deassert
>> the irq at the peripheral so I'm having trouble seeing how that should
>> work.
>>
>
> This is the job of the interrupt controller.  It must block interrupts of
> lower or equal priority.
>
>
>> Example: if we are in a timer ISR and loop on polling the uptime ticks,
>> do we
>> expect the ticks to be able to increase? I'm wondering if any of the
>> remaining
>> failing tests are due to this. But also what the best shape of a BSP is.
>>
>> Thanks!
>>
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>
>>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20140428/51d1aad2/attachment.html>