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
