This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: FW: Is eCos running any background process?
- From: Gary Thomas <gary at mlbassoc dot com>
- To: "Paul D. DeRocco" <pderocco at ix dot netcom dot com>
- Cc: eCos Discuss <ecos-discuss at ecos dot sourceware dot org>
- Date: Thu, 09 Oct 2008 11:09:04 -0600
- Subject: Re: [ECOS] FW: [ECOS] Is eCos running any background process?
- References: <PGEAIGBPLOMOJDAPCOJHAEOHLLAB.pderocco@ix.netcom.com>
Paul D. DeRocco wrote:
>> From: Chris Zimman
>>
>> Turning off interrupts for a short period of time and polling may
>> be the only
>> way to guarantee the operation for this application. We had a somewhat
>> similar problem a few years back, and we had to disable
>> interrupts during a
>> critical write to meet timing requirements.
>>
>> Even if he was running at 180MHz, assuming perfect conditions
>> otherwise and
>> no external bus accesses, 4.72uSec is only about 850 clock cycles. That
>> doesn't leave a ton of overhead for an interrupt driven approach.
>
> I haven't tallied them up, but I'd be surprised if it took anything like 850
> clocks for the timer ISR to post the timer DSR, as long as all the
> instrumentation crap is turned off. And it's certainly enough to read a byte
> and stuff it into a buffer.
>
> But there's still another way with the ARM, which is to use FIQ. FIQ is good
> for really short handlers hand-crafted in assembly language, which perform
> the function of a smart DMA controller, using only the few shadow registers
> swapped by the FIQ. Such a handler can safely interrupt ISRs, as long as it
> doesn't make _any_ system calls (including posting a DSR), but for this to
> work well, the HAL_DISABLE_INTERRUPTS macro would have to be modified not to
> mask FIQ. (I think that's a design flaw in the ARM HAL, by the way.)
I tend to agree with this perspective. One problem is that not all
board/system designers understand this and they've used FIQ for IRQ
sorts of events. Hence the eCos interrupt system on ARM _tries_ to
handle both FIQ and IRQ equivalently. In retrospect, this is probably
not the best approach.
Feel free to propose changes/patches to support this. Of course,
such changes should be configurable using CDL, it *is* eCos(*) after all.
(*) n.b. eCos now stands for "Embedded Configurable Operating System",
thanks to a slip of my pen nearly a decade ago, when it was originally
named "Embedded Cygnus Operating System" :-)
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss