[ECOS] Some newbie questions

[ECOS] Some newbie questions

[Andreas Hofer]

Hello, list,

I need some advice on the coice of the proper OS for our application and
eCos (for me) is one of the candidates.

We have developed a SA1110 based board used to perform CAN bus
communication. The CAN controller in use is the Philips SJA1000. Some
communication partners on the CAN bus expect our board to respond within
a guaranteed time limit of 40 Microseconds. Guaranteed means hard
realtime, right? Can eCos meet these requirements?

Since we already are using Linux on a similar board (but without the
realtime constrains we are facing now) the first thought was to use a
Linux / RtLinux or Linux / RTAI combo. This could give us the
possibility to reuse some code. On the other hand, there seem to be some
disadvantages: Lengthy startup, large memory footprint. Also, we still
have to port RTAI or RTLinux.

Since I don't know very much about eCos I would be glad to receive some
opinions about the pros and cons of the two approaches. How difficult do
you expect the adaption of eCos to a new SA1110 based board like ours to
be?

Any response is very much appreciated.

Andreas

Re: [ECOS] Some newbie questions

[Andrew Lunn]

> We have developed a SA1110 based board used to perform CAN bus
> communication. The CAN controller in use is the Philips SJA1000. Some
> communication partners on the CAN bus expect our board to respond within
> a guaranteed time limit of 40 Microseconds. Guaranteed means hard
> realtime, right? Can eCos meet these requirements?

eCos is not a hard real time OS. There is no deadline scheduling, no
guarantees. Everything it best effort. You do have priorities per
thread, so you can priorities your CAN bus handler above everything
else to improve is responce time.

Whats your definition of responce time? The time taken for an ISR to
run? The time before a thread starts to run? I have an application
also on an SA1110 processor which requires that the schedular is not
disabled for longer than 200us. eCos can do that without a problem on
our target hardware.

> How difficult do
> you expect the adaption of eCos to a new SA1110 based board like ours to
> be?

How different is it to the other SA1110 platforms that are supported?
Does it use the same flash chips? Same memory layout? etc. The more
similar it is, the less work involved.

        Andrew

Re: [ECOS] Some newbie questions

[Lewin A.R.W. Edwards]

>eCos is not a hard real time OS. There is no deadline scheduling, no
>guarantees. Everything it best effort. You do have priorities per
>thread, so you can priorities your CAN bus handler above everything
>else to improve is responce time.

In practice, regardless of the APIs eCos provides, you can put whatever 
hardware is connected to the CAN controller on a high-priority interrupt 
and disable every other interrupt as soon as you get into that ISR.


-- Lewin A.R.W. Edwards
Embedded Engineer, Digi-Frame Inc.
Work: http://www.digi-frame.com/
Tel (914) 937-4090 9am-6:30pm M-F ET
Personal: http://www.larwe.com/ http://www.zws.com/

"Far better it is to dare mighty things, to win glorious triumphs, even 
though checkered by failure, than to rank with those poor spirits who 
neither enjoy much nor suffer much, because they live in the gray twilight 
that knows not victory nor defeat."
(Theodore Roosevelt)

AW: [ECOS] Some newbie questions

[Andreas Hofer]

Hi, Andrew,

> -----Ursprungliche Nachricht-----
> Von: Andrew Lunn [ mailto:andrew.lunn@ascom.ch ]
> Gesendet: Dienstag, 26. Juni 2001 13:55
> An: Andreas Hofer
> Cc: ecos-discuss@sources.redhat.com
> Betreff: Re: [ECOS] Some newbie questions
>
>
> > We have developed a SA1110 based board used to perform CAN bus
> > communication. The CAN controller in use is the Philips
> SJA1000. Some
> > communication partners on the CAN bus expect our board to
> respond within
> > a guaranteed time limit of 40 Microseconds. Guaranteed means hard
> > realtime, right? Can eCos meet these requirements?
>
> eCos is not a hard real time OS. There is no deadline scheduling, no
> guarantees. Everything it best effort. You do have priorities per
> thread, so you can priorities your CAN bus handler above everything
> else to improve is responce time.

But there is no doubt that a thread will be preempted by a interrupt
regardless of its priority, right?

>
> Whats your definition of responce time? The time taken for an ISR to
> run? The time before a thread starts to run? I have an application
> also on an SA1110 processor which requires that the schedular is not
> disabled for longer than 200us. eCos can do that without a problem on
> our target hardware.
>

My definition of response time is the time between receiving a CAN
message from node A and sending back our response to node A. So, within
40us we have to read the CAN message, generate a response message and
send it  back to node A again. Even if the timing would be relaxed to
100 or 200us, we have to guarantee the timeline.

> > How difficult do
> > you expect the adaption of eCos to a new SA1110 based board
> like ours to
> > be?
>
> How different is it to the other SA1110 platforms that are supported?
> Does it use the same flash chips? Same memory layout? etc. The more
> similar it is, the less work involved.
>
>         Andrew
>

Our board has 16Meg of SDRAM and 16Meg of Strata Flash. Porting Linux to
that board was not that much of a pain.

Andreas

AW: [ECOS] Some newbie questions

[Andreas Hofer]

Lewin,

> -----Ursprungliche Nachricht-----
> Von: Lewin A.R.W. Edwards [ mailto:larwe@larwe.com ]
> Gesendet: Dienstag, 26. Juni 2001 15:06
> An: Andrew Lunn; Andreas Hofer
> Cc: ecos-discuss@sources.redhat.com
> Betreff: Re: [ECOS] Some newbie questions
>
>
>
> >eCos is not a hard real time OS. There is no deadline scheduling, no
> >guarantees. Everything it best effort. You do have priorities per
> >thread, so you can priorities your CAN bus handler above everything
> >else to improve is responce time.
>
> In practice, regardless of the APIs eCos provides, you can
> put whatever
> hardware is connected to the CAN controller on a
> high-priority interrupt
> and disable every other interrupt as soon as you get into that ISR.
>
>
>

But what can I do if I must perform a task "exactly" 123us from now or
if I want to perform periodic tasks with very low jitter? Can I do this
with eCos or do I need a hard realtime OS?

Andreas

Re: [ECOS] Some newbie questions

[Andrew Lunn]

> > eCos is not a hard real time OS. There is no deadline scheduling, no
> > guarantees. Everything it best effort. You do have priorities per
> > thread, so you can priorities your CAN bus handler above everything
> > else to improve is responce time.
> 
> But there is no doubt that a thread will be preempted by a interrupt
> regardless of its priority, right?

Yes, unless the thread has turned interrupts off. But where is your
code to processes the request? Probably in a thread? Your ISR calls a
DSR, and the DSR calls the thread. Under some conditions this is not
imeadiate, eg if there are other DSRs already running, or waiting to
run etc. 

> My definition of response time is the time between receiving a CAN
> message from node A and sending back our response to node A. So, within
> 40us we have to read the CAN message, generate a response message and
> send it  back to node A again. 

Whats the worse case time to generate the responce? From that you can
work out how much time you have to receive and send from the chip. You
can then decide if to do it all in the ISR, or have a DSR or thread. 

        Andrew

Re: AW: [ECOS] Some newbie questions

[Lewin A.R.W. Edwards]

Hi Andreas,

> > In practice, regardless of the APIs eCos provides, you can
> > put whatever hardware is connected to the CAN controller on a
> > high-priority interrupt
> > and disable every other interrupt as soon as you get into that ISR.
>
>But what can I do if I must perform a task "exactly" 123us from now or
>if I want to perform periodic tasks with very low jitter? Can I do this
>with eCos or do I need a hard realtime OS?

eCos isn't guaranteed to provide services of this type. In such an 
application, if I was using eCos (for cost/ease of use/other reasons) again 
I would subvert the OS for this functionality. I would steal the ISR for 
the main periodic timer and install my own ISR for it to provide the kind 
of high-resolution timed events you require, then give the eCos scheduler a 
lower-priority timer. This would require a lot of care about what your 
"magic" periodic task is doing, since it would be dancing on the hardware 
without the OS's direct knowledge.

You might not be gaining anything useful from using eCos in such a 
situation. It depends what other tasks you have to run apart from your 
exotic hard realtime task.

If for instance you wanted eCos's TCP/IP stack, that would be a good 
reason. Essentially what I'm talking about is establishing a hard realtime 
layer that can preempt eCos at any time, and eCos becomes conceptually 
almost a "background task" of the hard realtime layer.

I have something vaguely like this in one product, when it detects a USB 
attached host attempting to upload new firmware, it halts the OS and 
disables all interrupts, performs the firmware update and reboots. Lower 
level of complexity than your application though.


-- Lewin A.R.W. Edwards
Embedded Engineer, Digi-Frame Inc.
Work: http://www.digi-frame.com/
Tel (914) 937-4090 9am-6:30pm M-F ET
Personal: http://www.larwe.com/ http://www.zws.com/

"Far better it is to dare mighty things, to win glorious triumphs, even 
though checkered by failure, than to rank with those poor spirits who 
neither enjoy much nor suffer much, because they live in the gray twilight 
that knows not victory nor defeat."
(Theodore Roosevelt)

[ECOS] Re: Some newbie questions

[Richard Panton]

On Tue, 26 Jun 2001, Andreas Hofer wrote:

> We have developed a SA1110 based board used to perform CAN bus
> communication. The CAN controller in use is the Philips SJA1000. Some
> communication partners on the CAN bus expect our board to respond within
> a guaranteed time limit of 40 Microseconds. Guaranteed means hard
> realtime, right? Can eCos meet these requirements?

eCos CAN meet that requirement, but you may have to be careful of how you
use the various DMA channels on the SA1110 (if you use them at all, that
is).

For instance, the LCD controller loads the palette at the beginning of
each frame. This may contain up to 512 bytes, that MAY be loaded in one
DMA burst. Also, the larger the screen resolution, the less cycles are
available for the processor. Finally, it is possible for PC-Card accesses
to take a VERY long time when using the PWAIT feature or when the access
times are set to maximum. So, even at the hardware level, it can be
difficult to have guaranteed response times from the StrongARM.

Richard Panton
3G Lab Ltd.