Re: [ECOS] Timing considerations

Re: [ECOS] Timing considerations

[Andrew Lunn]

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

Re: [ECOS] Timing considerations

[Eric Doenges]

eibach@gdsys.de wrote:

[ ... ]
> 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
> 
> Am I on the right way? Has anybody better ideas?
> Could changing the time between ticks cause any problems?

Since every tick will cause an interrupt, you might end up swamping your
target. 100us seems a pretty hefty load for an EB40 to me (I have run
an application successfully with 100us timer interrupts under QNX, but
that was on a 300MHz AMD K6 pc).

If your application is not going to be doing anything else while waiting
for the serial data, it would probably be better to poll the timer to
check if 1ms has passed.
-- 
--------------------------------------------------------------------
|     Eric Doenges              |     DynaPel Laboratories GmbH    |
|     Tel: +49 89 962428 23     |     Fraunhoferstrasse 9/2        |
|     Fax: +49 89 962428 90     |     D - 85737 Ismaning, Germany  |
--------------------------------------------------------------------


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

[ECOS] Timing considerations

[eibach]

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

Am I on the right way? Has anybody better ideas?
Could changing the time between ticks cause any problems?

Regards,
Dirk Eibach


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

Re: [ECOS] Timing considerations

[Andrew Lunn]

On Thu, Sep 11, 2003 at 09:29:13AM +0000, eibach@gdsys.de wrote:
>
> It is really a good idea to do a blocking read in a thread. I was
> not really aware that this would cause the thread to go
> sleeping.

What did you expect a blocking read 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

Re: [ECOS] Timing considerations

[eibach]

Hello,

thank you very much for your helpful ideas.
It is really a good idea to do a blocking read in a thread. I was not really aware that this would cause the thread to go sleeping. For sure this is much better than changing the eCos tick timing.

Best regards,
Dirk

-------- Original Message --------
> > 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


To: andrew@lunn.ch
Cc: ecos-discuss@sources.redhat.com


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