This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Interrupt-free scheduler


On Mon, Apr 04, 2005 at 04:57:45PM +0100, Nick Garnett wrote:
> What exactly are you trying to do? If you don't have any interrupting
> devices, then eCos will run just fine.

The task is to provide a uitron API to an existing PPC850 card, which
does have interrupting devices. The original OS knows nothing about
interrupts. Our ISRs handle all that. If eCos were to fiddle with
interrupts, we couldn't just leave the ISRs in place, as part of the
port.

Fortunately, I've now learned enough about enabling and disabling
components in a .ecc file to disable everything that smells of
interrupts, and resolve the conflicts. Hopefully eCos will now be
unaware of interrupts.

> Some things, like timers, will not work, but presumably you have
> already allowed for that.

Oh yes, the timers. It took several cycles to resolve those conflicts,
but with persistence, they're gone too. The application provides timers
from a task. As a first cut, I'm kinda hoping to re-use that as is.
Although a bit weird, it works like a bought one.

Reconfiguring eCos is faster and more robust than recoding all the timer
stuff in the application. (You wouldn't want to know the proposed
schedule for this. But then, you've probably been there, at least once. ;)

Things are now fine up to cyg_user_start(), running on the target. (Just
turning on a few LEDs.) Next step is a thread or two, but I'll have to
translate the examples to uitron API first.

Erik


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]