Ok, so the same interrupt will never nest itself then? Good, thanks!
On Mon, Apr 28, 2014 at 2:14 PM, Sebastian Huber < sebastian.hu...@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@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.hu...@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@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
