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: Timing considerations


On Thu, Sep 11, 2003 at 06:02:46AM +0000, eibach@gdsys.de wrote:
> Hello,
> 
> one of the things my eCos application has to do is to serve a serial port. Platform is an Atmel EB40A.
> 
> The device connected to the serial port needs answers to its requests within 1 ms to work properly.
> 
> My idea was the following:
> - use the EB40A hardware driver for the serial port
> - poll the driver every 1 ms using the cyg_io_read command (non-blocking)
> - polling could be triggered by an alarm
> - that would require a clock with a timing faster than 10 ms between ticks (which is the standard)
> - so i use CYGNUM_KERNEL_COUNTERS_CLOCK_OVERRIDE_... options to set the ticks to 100 us
> - then i can trigger the alarm every 10 ticks

That's not the way i would do it. eCos is a soft RTOS. Make your
thread doing the read from the serial port the highest priority. Let
it do blocking reads. As soon as the data becomes available, the
thread will be awoken, it can do its work imeadiately and respond with
the answer. So long as your CPU is fast enough, it should be able to
respond within 1ms. 

We have a system with a 233MHz StrongArm. It has to respond to an
interrupt, do a lot of processing and be finished within 0.8ms. It
does with 100% of the time, even when the CPU is fully loaded with
other tasks. The eCos scheduler does a good job of getting higher
priority threads run when they have stuff to do.

         Andrew

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


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