This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Timing considerations
- From: Andrew Lunn <andrew at lunn dot ch>
- To: eibach at gdsys dot de
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Thu, 11 Sep 2003 08:47:52 +0200
- Subject: Re: [ECOS] Timing considerations
- References: <DIIE.00000956000588E8@gdproxy2.gdsys.de>
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