[Bug 1001456] HAL misses Interrupt Clear-Pending Registers handling:wasted processing power

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001456

--- Comment #29 from Bernard Fouchà <bernard.fouche@kuantic.com> 2012-09-27 14:36:11 BST ---
(In reply to comment #28)
>
> this is in fact how most drivers are already written today.
> 
> would'nt that be OK for you too?
> 
> Regards,
> Bernd Edlinger

Hi Bernd,

if the current interrupt handling management was able to fix this issue then
the problem would not exist. Please look at the chronograms:

1) when a 1st ISR occurs, the ISR handler is called, that's ok.
2) the ISR handler schedules a DSR and disable interrupt for the concerned
vector.
3) however a second interrupt condition occurs at that point: the pending bit
is raised because the interrupt can't be triggered by the MCU and hence the
pending bit could not have been cleared earlier in ISR code. This happens
generally in hardware having FIFO or buffers because they have many interrupt
conditions.
4) the DSR is run and processes all interrupt conditions, even the interrupt
condition that made the pending bit to be raised: this is the general design of
all DSR I've seen in eCos: do as much as possible in a single DSR run.
5) There is no API to clear the pending bit at the end of the DSR, hence:
6) the ISR is called again because of the pending bit previously set, even if
the DSR did all required work.
7) the DSR is triggered and have no work to do.

So one have to choose between:

- consider this problem to be cortex-m specific. Side effect: it is not
possible to have generic drivers (UART, SSP, CAN, etc) that can run efficiently
across cortex-m and other architectures because there isn't a common API call
to cancel the pending bit.

- abandon the idea of generic drivers shared between cortex-m and architectures
that don't have the need to manage the pending bit: re-adapt each driver,
mainly by copying files 99.9% identical from some architecture to cortex-m
(IMHO this is where the real bloat risk is)

- change DSR to do as less as possible in a single run: it sounds sarcastic but
today if a driver doesn't handle this issue, this is what happens: ISR and DSR
are triggered multiples times for nothing so why bother to make an efficient
DSR?

- ignore the problem. But cortex-m isn't some bizarre arch that will disappear
in a few months.

- increase eCos API to add a pending bit clearing call.

If there is another solution I would be glad to here about it!


  Bernard

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.