[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 #31 from Bernard Fouchà <bernard.fouche@kuantic.com> 2012-09-27 19:09:39 BST ---
Thanks Nick to have taken the time to answer to this report!

(In reply to comment #30)
> 
> I wasn't sure what conclusion I would come to when I started writing this, but
> I think I have convinced myself that this is actually a non-issue. The proposal
> cannot eliminate these extra ISR/DSR calls completely; the problem is not eCos
> specific; it is not Cortex-M specific either; the issue only seriously affects
> systems that are on the edge of being too slow to cope with the interrupt rate.

The issue happens for all peripherals that can trigger an interrupt for
different and asynchronous reasons that the interrupt being processed.

This can happen at any clocking speed: typically you fill a FIFO or a buffer
for data output and the incoming side of the peripheral reports at that time
that an event from outside is to be considered. Or you are emptying a FIFO and
the transmit FIFO is available again. Or the CAN buffer you filled previously
is now available while you are filling a newer buffer.

The last time I checked, my system was running zero unneeded DSR while I can
have up to 4 UART, SSP and CAN working so the proposed fix is efficient, at
least in my case.

I'm really curious if some other tried to count ISR/DSR regarding to the volume
of exchanged data, but at the moment nobody gave me counts made on another
system.

> The worst aspect of the proposal is that it spreads its tentacles into all
> other architectures and device drivers.

I agree... 

> 
> However, comment #7 contains a seed of a better solution. Many device drivers
> are somewhat lazy in using cyg_drv_interrupt_mask() and friends to control
> interrupt delivery; and it is this that is the main cause of the problem. They
> should really use peripheral registers to do this, where possible. Certainly
> generic drivers like the 16x5x driver should. I switched the eCosCentric
> version of this driver over to doing exactly this earlier this year and can
> contribute a patch to do that for the public version. Other drivers should be
> converted as and when convenient. Those devices that don't have local control
> of interrupts will just have to continue with the current approach and accept
> the consequences.

IIRC some peripherals trigger an interrupt on the rising edge of an event but
won't make any interrupt if the enable interrupt bit is set in their interrupt
enabling register after the event occurred: if the peripheral event occurs
exactly after the DSR reads the peripheral register (so the DSR thinks there is
no more job to do) but before the DSR re-enables peripheral interrupts then an
event may be lost. If this can happen, then there is no other solution than to
handle that interrupt pending bit.

My guess is that the 'pending interrupt bit' is designed to avoid this race
condition, at least you go for another ISR and/or DSR round but you don't lose
anything.

Pure speculation from me: HW peripheral designers may count on this feature to
lower the gate count of their cell, they send to the MCU the pulse of the event
when it occurs, they don't check when the interrupt register is written if an
interrupt condition should be triggered (have the MCU do a bit more so all
peripherals can do and cost less).

Unless someone else count ISR/DSR runs in a fast clocking system different than
mine, I'll stay convinced that this problem occurs frequently in many different
systems.

-- 
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.