So, which one is best? :)
I am new to RT development, and have been assigned the task of
determining the "best" RT on Linux strategy for an embedded control
system on an industrial machine - we are definitely wanting to use an
" Linux" method, as there are several other, non-RT tasks/services
that this system will do/provide - the RT task, while it is the *most*
important thing that this system will be doing (triggering/capturing
data samples via serial port), will be one of the *least* system
resource-intensive processes that run on this embedded system.
services (all non-RT) will include database, live video stream
capture/re-package/re-transmit, UDP broadcasting of custom data
packets, and TCP/IP network routing between an external network and the
machine-internal network.
I have been researching all 3 options for about 1 week (full time) now,
and I have not found any comprehensive, *recent*
that involve the latest
versions/capabilities of the 3 possibilities.
Thanks for the assistance!
-James

James Ausmus <james.ausmus@gmail.comwrote:
So, which one is best? :)
I am new to RT development, and have been assigned the task of
determining the "best" RT on Linux strategy for an embedded control
system on an industrial machine - we are definitely wanting to use an
" Linux" method, as there are several other, non-RT tasks/services
that this system will do/provide - the RT task, while it is the *most*

I suppose that you're not willing to consider putting the RT part on a
dedicated microcontroller? Seems like it'd be much simpler to deal with.

ttyl,

Unfortunately, that part of the design is outside of my scope of
influence :) This is the hardware configuration that we're stuck
with, no matter what. Luckily, it is a very beefy embedded system -
Pentium M 1.4GHz, 1GB ECC DDR (400) RAM, 4GB CF, 200GB Hard Drive -
obviously, we're not in a power-constrained environment. <grin>
-James

James Ausmus wrote:
So, which one is best? :)
Define best and the answer will become clear.
Ian

That is part of the problem - being new to RT development and
methodologies, I don't know exactly how "best" *should* be defined for
my situation. most basic need for having RT on Linux is that we
want a deterministic turn-around time on our handling of the device
response on the serial port - as soon as an "answer" comes in, we're
just going to send the exact same "question" back out to the device,
triggering another "answer" - we just want to ensure that the handler
always will run immediately on receive, with nothing else being able to
delay it, even if the system is under a very heavy load from the video
stream processing, UDP broadcasting, DB hits, TCP/IP routing, and
custom TCP/IP protocol handling. The (theoretical) turn-around time on
the device is transmit time + around 2.5 mS processing (device-side) +
transmit time, so around 3-5 mS total round trip on a query/response
pairing - so if we send out a new "question" as the first thing in the
handler, we will have about 3-5 mS to process the response and shove it
into a shared memory area or a FIF or mailbox or whatever, in order
for a userland process to grab that data and shove it into the database
and out through the UDP broadcast - if it's practicle, we'd like the
"grab and shove" routine to be at least soft realtime, as we want
"live" data from the device to be part of the constant UDP broadcasting
packets. However, if updating what is sent out via the UDP packets is
delayed slightly, it's not as big a deal - as long as we have very
precise handling of the actual data, and it is recorded as such in the
database. Above all, though, no matter what else is going on, we need
an "immediate" handling of the serial device response, so we can get
another query sent out, and process the response we got before the new
response comes in.

My current slight leaning is towards just the 2.6 kernel with the
real-time preemption/HRT patch applied, however, I am worried that if
the system gets heavily loaded down, since that isn't a co-kernel
approach, the latency of the interrupt handling could get to be too
high - I haven't been able to find a definitive answer on whether or
not having the real-time preemption patch allows a specific thread to
be handled in a deterministic real-time fashion, no matter the load on
the rest of the system. So, that makes me lean towards RTAI (+/- LXRT),
however, this locks the code into a specific API, and if the Linux
kernel gets to the point that it can guarantee deterministic RT thread
handling, my preference would be to go the kernel path, as it seems
much more simple and clean to only have 1 S running at a time :) - but
that easily could be my mistaken impression from not knowing enough
about RT in general.

Now, when I get the embedded system hardware in here, I could run
benchmarks of all 3 configurations, however, this project is on a
fairly tight schedule, so if I can find enough "hard" information, or
even an overwhelming amount of experiential data, I would be able to
pre-select an option, and start diving into exactly what it will take
to do what we want with that option, before the hardware even gets
here.

So, lots'o'post later, anyone have any opinion/data on which one is
"best"? even any guidance or insight into what "best" I should be
looking for in this situation?

Thanks much for your time and patience with a "noob". <grin>
-James

What is your interest in "real-time" and what does th term mean to you.

The proper use of the term "real-time" means that your system has
dead-lines and the dead-lines must be met. So you need to quantify what
that means.
1) What are the dead-lines you have to meet? As an example you may say
that you are required to respond to a signal when it occurs within say 2 ms.
2) What are the consequences of not meeting that dead-line? Is it
detrimental to your system or will you recover?

This is the type of analysis you need to do.

Also when you deal with a kernel like Linux, you'll find that the
response to interrupts can be fast when the system is not loaded but as
the system goes through busy spurts then the response time may become a
couple of order of magnitudes larger. Thus large enough to not be able
to guarantee that the dead-lines will be met.

So you need to do a careful timing analysis.

In the dual kernel approach, you have Linux being scheduled a thread
between on top of a real-time kernel. The issue you run into is
synchronizing and communicating adequately between the real-time and non
real-time applications.

So you need to ask yourself: Is the use of Linux a requirement? IS
real-time a requirement? Perhaps you are looking for a Posix API but
don't actually need Linux? In that case consider Linux S?
on the other hand you require an open source kernel, and in that case
you may consider

Feel free to ask me to elaborate more.

Sari

James Ausmus wrote:
So, which one is best? :)
I am new to RT development, and have been assigned the task of
determining the "best" RT on Linux strategy for an embedded control
system on an industrial machine - we are definitely wanting to use an
" Linux" method, as there are several other, non-RT tasks/services
that this system will do/provide - the RT task, while it is the *most*
important thing that this system will be doing (triggering/capturing
data samples via serial port), will be one of the *least* system
resource-intensive processes that run on this embedded system.
services (all non-RT) will include database, live video stream
capture/re-package/re-transmit, UDP broadcasting of custom data
packets, and TCP/IP network routing between an external network and the
machine-internal network.

I have been researching all 3 options for about 1 week (full time) now,
and I have not found any comprehensive, *recent*
that involve the latest
versions/capabilities of the 3 possibilities.

Thanks for the assistance!

-James