Embedded Linux Vs. Real time Linux - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Embedded Linux Vs. Real time Linux


Quoted text here. Click to load it

I don't know, I have no experience with Blackfin and/or uCLinux. You
could try the related forum or mailing lists.

Kind regards,
    Johan Borkhuis

Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

The main architectures are x86, powerpc (not ppc!!) and arm. As RT-Preempt
fights against system management mode on x86 and other ugly broken x86
hardware, its easier to use RT-Preempt on non x86 architectures.

JB

Re: Embedded Linux Vs. Real time Linux

Quoted text here. Click to load it

But this is the approach of the RT Preempt patch: To reduce the need of
disabling the interrupt and replace this code by simple spin locks or
mutexes. This means the word "preemption". Ensure every piece of code can
be preempted if something with a higher priority is ready to work. So also
the interrupt service routines are kernel threads now, and with a priority.

On a DualCore-Pentium with RT Preempt we need more than 10000 hackbench jobs
and a two ping floods to see latency violations on this box....

JB

Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

You could use a serial port configured in loopback mode to transfer in one
direction.
Need two serial ports to transfer in both directions.

Quoted text here. Click to load it




--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

Why bother with Montavista, if you just want ordinary Linux?
www.kernel.org?

Quoted text here. Click to load it

You are likely to run with a MMU enabled.
Your code and data needs to be in the virtual address space of a Linux
process.

Quoted text here. Click to load it

Anything is possible, given the right interrupt controller, but
that does not mean that it is supported by Linux.
On the AT91, you could will get a vectorized interrupt
but I assume all vectors are the same in Linux.
Doing something else will require modifying the linux kernel.

The key problem is probably the transfer of data between your
interrupt and the linux kernel.

Quoted text here. Click to load it

You use a fast enoķgh processor, or rely on the TCP/IP protocol
to resend data that gets lost because you do not have time to process it.
At 1 Gbit, you hopefully have a DMA which can store multiple packets without
CPU intervention.

Quoted text here. Click to load it




--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded Linux Vs. Real time Linux
Hey Ulf,


Quoted text here. Click to load it

We are considering montavista because of the support that they supply
- we would like to use a kernel port that is fully supported. We are a
small R&D and a even smaller SW team, therefore we would like to dodge
the hard-core linux problems and concentrate on application
development.

Quoted text here. Click to load it

But still working as a totally independent part - not being a part of
the Linux system in any way?

Quoted text here. Click to load it

The right interrupt controller? In my world I need to have a
possibility to mask the interrupt that I want to interrupt the Linux?
Regarding the transfer between the ISR and the kernel - how can I do
this when MMU is enabled and without needing to modify the kernel?


Best Regards

MMJ


Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it


If you have a prioritized interrupt controller like the AT91 AIC,
then you can have one level of interrupts which will enter the
Linux Interrupt routine, and other (higher) levels could
be used to generate interrupt vectors to high priority interrupts,
including the FIQ (Fast Interrupt).

You will have to have your code in the linux kernel address space,
but there is no need to link it with the kernel.

Use of FIQ, will require you to have your non-linux code right
after the exception vector table.

--
Best Regards,
Ulf Samuelsson
We've slightly trimmed the long signature. Click to see the full one.
Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

Next to the commercial versions there are also some open source
versions, like Xenomai or RTAI. These have the same concept: a small
realtime kernel, and Linux as a low priority task of this kernel.
I don't have experience with the commercial version, only with
Xenomai, so the answers below relate to this, but are probably also
true for other realtime versions of Linux.

Quoted text here. Click to load it

Yes, this is possible, even when Linux is processing another interrupt
the realtime interrupt can interrupt this.
An interrupt can be processed by Xenomai, or by Linux, or even by
both. When leaving the ISR you can indicate if the interrupt was
handled. If not the interrupt will be serviced by Linux.

Quoted text here. Click to load it

Real time Linux allows your user level applications to run in real
time, even under stress conditions. Using a very simple application it
is possible to test this: wait for timer interrupt, read timestamp,
calculate difference with previous timestamp. If you use a 10 msec
timer interrupt you would expect the difference to be 10 msec. Under
low/no load this is true: the variation is within 20 usec. Under load
however the variation can be a number of msecs, which is not real time
behavior.  When using Xenomai (or other RT-Linux versions) this
variation is still around 20 usec.

Quoted text here. Click to load it

Xenomai is part of the Linux kernel, so the drivers exist within the
kernel. This means that you have access to all the resources of the
kernel. You are also using the same address scheme as Linux. If you
want you can even write multimode drivers: both RT and non-RT drivers
combined into one driver.
Your applications are also running as normal Linux application, only
with some restrictions: as long as you don't do standard Linux system
calls your application works as a realtime application. You can also
have a thread in an application run as real time thread, while others
are running as Linux threads. As these are thread they share the same
address space, so you have access to the same memory, and can use this
to communicate between RT and non-RT.

Quoted text here. Click to load it

The interrupt routine will be called, but the processing of the data
will be suspended until no more realtime tasks are running. This means
that if the buffer between the interrupt routine and driver is not
large enough you might loose data.

Kind regards,
    Johan Borkhuis

Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

RTAI is depreciated. Don't use it for new projects.

JB

Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

I don't know about that (I don't follow RTAI closely), but as far as I
can see there is still development going on (a new test release was
released this year), and the mailing list is quite active as well.

Kind regards,
    Johan Borkhuis

Re: Embedded Linux Vs. Real time Linux

Quoted text here. Click to load it

Development for current kernels?

JB

Re: Embedded Linux Vs. Real time Linux


Quoted text here. Click to load it

I did see references to 2.6.19 and 2.6.20 kernels, so that seems
pretty current.

Kind regards,
    Johan Borkhuis

Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

Why using a separate kernel for hard realtime, when you can get a whole hard
realtime Linux kernel? Give RT Preeempt a try. This adds fully hard
realtime feature to the Linux kernel (and most of it is already mainline).
And: You can use the hard realtime feature also in userspace, to program
hard realtime application with POSIX-API only.
Refer: http://www.kernel.org/pub/linux/kernel/projects/rt /
We are using this kernel patch for our x86, ARM and PowerPC boards.

Quoted text here. Click to load it

With RT Preempt there is no need for such tricks. You can use all resources
from Linux, your can write your drivers like all other drivers, you need no
special knowledge about drivers in a separate RT kernel.

JB

Re: Embedded Linux Vs. Real time Linux
Hello Juergen,

Quoted text here. Click to load it


That sound really interesting. Exactly what I am looking for - a complete
solution that allows for hard RT performance without forcing us to do
experiments trying to integrate outside RT code. I'll look into that for
sure

--
MMJ



Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

Also for PowerPC ?
that's interesting. Last time I tried (2.6.19) things didn't seem to build/work
for our MPC82xx based PowerPC boards.

I you don't mind me asking, what kind of PowerPC CPUs/board you did successfully
apply
the RT patch for ? with what kernel version ?

---
NvB

Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

Also for PowerPC ?
that's interesting. Last time I tried (2.6.19) things didn't seem to build/work
for our MPC82xx based PowerPC boards.

I you don't mind me asking, what kind of PowerPC CPUs/board you did successfully
apply
the RT patch for ? with what kernel version ?

---
NvB

Re: Embedded Linux Vs. Real time Linux
Quoted text here. Click to load it

Freescale's MPC5200B with a 2.6.23.1 and currently 2.6.24.rc5. But the
2.6.24.rc5 has still some regressions.

JB

Re: Embedded Linux Vs. Real time Linux
MMJ,

Of all the options posted, which one did you end up using?

Site Timeline