Motherboard Forums


Reply
Thread Tools Display Modes

Recommend good RT Linux ?

 
 
Anton Erasmus
Guest
Posts: n/a
 
      09-02-2003, 05:24 PM
Hi,

I am finally reaching the end of my patience in trying to keep Test
code running under DOS/Win98 etc. It is fast becomming a situation
where I am spending 10 times more time trying to get my test app going
on a PC than I spend coding the embedded app in the first place.
I am thinking of using a "Real Time" linux on a PC for hosting my test
apps. Most of the time I only need to be able to get a number of
reasonably accurate "Timer Ticker" tasks in which I Rx/Tx to my
embedded system. (Typical 100Hz with 5 to 10% jitter is good enough,
1kHz would be nice)

Is it possible to load the RT components on top of RH9 or some other
distribution. If so which RT Linux would people recommend. I would
like to purchase a reasonable starter kit with good docs to get me
started. If some support exists for porting code from RT Kernel (16
bit), it would be a bonus.

If versions exists for ARM and PPC for embedded SBCs, it would be even
nicer.

Regards
Anton Erasmus


 
Reply With Quote
 
 
 
 
Amused
Guest
Posts: n/a
 
      09-02-2003, 06:16 PM
Anton Erasmus wrote:

> Hi,
>
> I am finally reaching the end of my patience in trying to keep Test
> code running under DOS/Win98 etc. It is fast becomming a situation
> where I am spending 10 times more time trying to get my test app going
> on a PC than I spend coding the embedded app in the first place.
> I am thinking of using a "Real Time" linux on a PC for hosting my test
> apps. Most of the time I only need to be able to get a number of
> reasonably accurate "Timer Ticker" tasks in which I Rx/Tx to my
> embedded system. (Typical 100Hz with 5 to 10% jitter is good enough,
> 1kHz would be nice)


With OS/2 warp3 warp4, you are slicing 1 second into about 32 slices, so
you would be able to do something like 30hz somewhat okay.
Win9x, NT is similar in structure... and possibly the other windows series.
You may have some luck with ecomstation (www.ecomstation.com) since I
understand the OS/2 kernel was updated and you could slice into smaller
portions (probably allowing you 128hz or 256hz accuracy.... you would have
to setup the timeslicing in config.sys)

Linux/Unix, from what I understand is more of a sequential OS and not a RT
OS, so you may be able to load-it-down to the point that everything looks
frozen and it still don't break, but real-time is not the priority.....the
latest kernels are more desktop oriented, and have better response, so
maybe the "real-time" factor you are looking for exist here.... I'd look at
Mandrake 9.x if you are not familiar with linux since it takes care of most
of the bumps and hiccups. Since you're running Win98, you could make the
same machine dual-boot, just scandisk, defrag, and save your drive 1st
before installing linux.

> Is it possible to load the RT components on top of RH9 or some other
> distribution. If so which RT Linux would people recommend. I would
> like to purchase a reasonable starter kit with good docs to get me
> started. If some support exists for porting code from RT Kernel (16
> bit), it would be a bonus.


There was a RT linux distro/fork at one point in time called Turbo linux I
believe.... you are best asking for a RT linux in comp.os.linux.advocacy
(watch out for trolls, there are many of them), plus I'd mention the 100hz
requirement too.

If you really need the "100hz factor", realize that whatever OS you have,
whether it's Linux, OS/2 or Windows, you are going to have "overhead" which
likely makes the 100hz fairly jittery.
I would preferably tend to remove the OS-factor by running DOS on the
machine which talks to your embedded project.... this means you're going to
have to roll-your-own serial I/O and use timers to keep accurate time, but
atleast "you" control timing accurately, versus getting the jittery results
due to OS overhead.
If you don't have DOS any longer, you could test in Win98, then when it
comes to "actual" running tests, use a freeDOS bootdisk.

Linux may be your answer, but I'm not expert enough to recommend which
distro at this point..... check the comp.os.linux.advocacy

 
Reply With Quote
 
 
 
 
Ian Molton
Guest
Posts: n/a
 
      09-02-2003, 07:32 PM
On Tue, 02 Sep 2003 19:24:55 +0200
Anton Erasmus <(E-Mail Removed)> wrote:

> (Typical 100Hz with 5 to 10% jitter is good enough,
> 1kHz would be nice)


I've read 12bit data from the paralell port at ~22kHz with no problems
ubder linux 2.2.x

I believe the scheduler interrupt is 1kHz now, compared to only 100Hz
back then.

obviously when the scheduling happens you get glitching but its not bad
at all.


--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with
ketchup.
 
Reply With Quote
 
Roger Larsson
Guest
Posts: n/a
 
      09-02-2003, 09:40 PM
Amused wrote:

> Anton Erasmus wrote:
>
>> Hi,
>>
>> I am finally reaching the end of my patience in trying to keep Test
>> code running under DOS/Win98 etc. It is fast becomming a situation
>> where I am spending 10 times more time trying to get my test app going
>> on a PC than I spend coding the embedded app in the first place.
>> I am thinking of using a "Real Time" linux on a PC for hosting my test
>> apps. Most of the time I only need to be able to get a number of
>> reasonably accurate "Timer Ticker" tasks in which I Rx/Tx to my
>> embedded system. (Typical 100Hz with 5 to 10% jitter is good enough,
>> 1kHz would be nice)

>
> With OS/2 warp3 warp4, ...


Huh? Where did he ask about warp?

>
> Linux/Unix, from what I understand is more of a sequential OS and not a RT
> OS, so you may be able to load-it-down to the point that everything looks
> frozen and it still don't break, but real-time is not the priority.....the
> latest kernels are more desktop oriented, and have better response, so
> maybe the "real-time" factor you are looking for exist here.... I'd look
> at Mandrake 9.x if you are not familiar with linux since it takes care of
> most of the bumps and hiccups. Since you're running Win98, you could make
> the same machine dual-boot, just scandisk, defrag, and save your drive 1st
> before installing linux.


Real-time IS the priority for some developers.

Some history, do also take a look at the test program
(but you do not need to run with the maximum possible priority):
http://www.gardena.net/benno/linux/audio/

Note: a accidental infinite loop in SCHED_FIFO/RT thread WILL
lock up your computer. (An even higher priority monitor can help you
regain control)

For more recent information take a look at
http://www.linuxdevices.com/articles/AT8073314981.html

>
>> Is it possible to load the RT components on top of RH9 or some other
>> distribution. If so which RT Linux would people recommend. I would
>> like to purchase a reasonable starter kit with good docs to get me
>> started. If some support exists for porting code from RT Kernel (16
>> bit), it would be a bonus.

>
> There was a RT linux distro/fork at one point in time called Turbo linux I
> believe.... you are best asking for a RT linux in comp.os.linux.advocacy
> (watch out for trolls, there are many of them), plus I'd mention the 100hz
> requirement too.


No, Turbo Linux = server. Look at embedded or professional audio
workstations instead. I think there exist precompiled kernels for RedHat.

>
> If you really need the "100hz factor", realize that whatever OS you have,
> whether it's Linux, OS/2 or Windows, you are going to have "overhead"
> which likely makes the 100hz fairly jittery.
> I would preferably tend to remove the OS-factor by running DOS on the
> machine which talks to your embedded project.... this means you're going
> to have to roll-your-own serial I/O and use timers to keep accurate time,
> but atleast "you" control timing accurately, versus getting the jittery
> results due to OS overhead.


It is of cause possible to run without dOS. Build the application and
flash it over the computers BIOS. :-)

> If you don't have DOS any longer, you could test in Win98, then when it
> comes to "actual" running tests, use a freeDOS bootdisk.
>
> Linux may be your answer, but I'm not expert enough to recommend which
> distro at this point..... check the comp.os.linux.advocacy


comp.os.linux.embedded would be a much better choice...

/RogerL

--
Roger Larsson
Skellefteċ
Sweden
 
Reply With Quote
 
TCS
Guest
Posts: n/a
 
      09-02-2003, 10:16 PM
On Tue, 2 Sep 2003 20:32:09 +0100, Ian Molton <(E-Mail Removed)> wrote:
> On Tue, 02 Sep 2003 19:24:55 +0200
> Anton Erasmus <(E-Mail Removed)> wrote:
>
>> (Typical 100Hz with 5 to 10% jitter is good enough,
>> 1kHz would be nice)

>
> I've read 12bit data from the paralell port at ~22kHz with no problems
> ubder linux 2.2.x
>
> I believe the scheduler interrupt is 1kHz now, compared to only 100Hz
> back then.
>


I think the default is still 100hz. I used the 2.4 kernel on the
axis cris 100lx processor and it was 100hz, but it was easy enough to
find the code the set up the timer and the time.h files to push it to
3200hz.
 
Reply With Quote
 
Amused
Guest
Posts: n/a
 
      09-03-2003, 02:35 AM
Roger Larsson wrote:

> Amused wrote:
>
>> Anton Erasmus wrote:
>>
>>> Hi,
>>>
>>> I am finally reaching the end of my patience in trying to keep Test
>>> code running under DOS/Win98 etc. It is fast becomming a situation
>>> where I am spending 10 times more time trying to get my test app going
>>> on a PC than I spend coding the embedded app in the first place.
>>> I am thinking of using a "Real Time" linux on a PC for hosting my test
>>> apps. Most of the time I only need to be able to get a number of
>>> reasonably accurate "Timer Ticker" tasks in which I Rx/Tx to my
>>> embedded system. (Typical 100Hz with 5 to 10% jitter is good enough,
>>> 1kHz would be nice)

>>
>> With OS/2 warp3 warp4, ...

>
> Huh? Where did he ask about warp?


Hehehe. He didn't ask.
Would you have replied here if I said FreeBSD?

When he said DOS/Win98....I made an assumption that it isn't a very fast
machine by today's standards, so threw in a comparison.
I know warp is about 30 something slices a sec, so it won't be that far-off
for win9x. the structures will be somewhat similar in some respect. That
is, you can have about 30 processes running evenly per second, same amount
of time divided up per process. If you have less, then one or more of those
slices will be given to a process that needs it. So supposing you have 5
processes running, it means each process would get about 6 slices each and
if it don't need it, it gives the rest of it's time to other processes
(assumming you don't give priority to some process over another process).
Now supposing he has only 2 processes running, that means about 15 slices
given per process. Okay, he's got 1 program running, that means 30 slices
right? Wrong! Windows is not running that DOS program 100% of the time,
it's got to take care of other stuff like clocks, task managers,
back-end-stuff, whatever..... so let's say that's about 29 slices for the
DOS program and 1 slice for windows...if it doesn't need it, it surrenders
the rest of it's time to his program...... but it's that 1 slice that is
screwing up his "evenly spaced" 100hz rate.
So, from what I understand of warp 3 or 4, with about 30 slices, yes I can
understand that he has a major headache trying to keep 100hz because there
will always be that 1 slice that creeps in and messes things up for him.
Warp, Win9x were created for 20mhz machines in 1994 or there abouts. 30
slices per second is probably a close guess. 100hz with a little jitter
would be a headache for Windows9x, 30hz would be realistic.

If he runs DOS, the OS overhead is a non-issue and he does as he pleases.
If the OS allows for 100 slices per second, he's sort of okay.
If the OS has more slices, better, less jitter, but realize you need faster
machines for more slices too, otherwise you get bogged down.

>> Linux/Unix, from what I understand is more of a sequential OS and not a
>> RT OS, so you may be able to load-it-down to the point that everything
>> looks frozen and it still don't break, but real-time is not the
>> priority.....the latest kernels are more desktop oriented, and have
>> better response, so maybe the "real-time" factor you are looking for
>> exist here.... I'd look at Mandrake 9.x if you are not familiar with
>> linux since it takes care of most of the bumps and hiccups. Since you're
>> running Win98, you could make the same machine dual-boot, just scandisk,
>> defrag, and save your drive 1st before installing linux.

>
> Real-time IS the priority for some developers.


Yes it is, but don't know what you want to say here since most of my reply
above is about easiest way to get into linux if he never seen linux before.
Dual boot allows him to get to his old tools assuming he's got just 1
machine. You don't simply throw out your old tools, .... you migrate to
your new tools.

If the person that asked, is an expert, then end of discussion, but
supposing not, you have to provide/suggest the easiest path.
As there was no indication, got to assume not an expert in linux.
My suggestion is get Mandrake, not Debian, not Gentoo. Get Mandrake.
You don't put a beginner skier on the black diamond runs.... you put em on
the gentle bunny hills first. ;-)

> Some history, do also take a look at the test program
> (but you do not need to run with the maximum possible priority):
> http://www.gardena.net/benno/linux/audio/
>
> Note: a accidental infinite loop in SCHED_FIFO/RT thread WILL
> lock up your computer. (An even higher priority monitor can help you
> regain control)


Priority is probably a new term to some windows users as it's not an option
presented on a windows menu.
On OS/2 running DOS tasks, it's a settable option.
Under Linux, I wasn't sure you could set it... it isn't something I found
using KDE (not something you can right-click or something), but the article
also mentions instability on slow machines running tiny slices.... 100hz or
10ms slices on a 133mhz machine may be pushing it . Tiny slices are great
for RT as long as you use a decently fast machine for the task.

> For more recent information take a look at
> http://www.linuxdevices.com/articles/AT8073314981.html
>
>>> Is it possible to load the RT components on top of RH9 or some other
>>> distribution. If so which RT Linux would people recommend. I would
>>> like to purchase a reasonable starter kit with good docs to get me
>>> started. If some support exists for porting code from RT Kernel (16
>>> bit), it would be a bonus.

>>
>> There was a RT linux distro/fork at one point in time called Turbo linux
>> I believe.... you are best asking for a RT linux in
>> comp.os.linux.advocacy (watch out for trolls, there are many of them),
>> plus I'd mention the 100hz requirement too.

>
> No, Turbo Linux = server. Look at embedded or professional audio
> workstations instead. I think there exist precompiled kernels for RedHat.


Excellent.
I didn't know that RT precomiled kernels existed either, glad someone
asked, otherwise this would not have occurred to me either.
Thanks for pointing out the article.

>> If you really need the "100hz factor", realize that whatever OS you have,
>> whether it's Linux, OS/2 or Windows, you are going to have "overhead"
>> which likely makes the 100hz fairly jittery.
>> I would preferably tend to remove the OS-factor by running DOS on the
>> machine which talks to your embedded project.... this means you're going
>> to have to roll-your-own serial I/O and use timers to keep accurate time,
>> but atleast "you" control timing accurately, versus getting the jittery
>> results due to OS overhead.

>
> It is of cause possible to run without dOS. Build the application and
> flash it over the computers BIOS. :-)


Yes it's possible. That would now be considered a "dedicated" machine until
you flash it back. :-(
Most of us tend to like to use a computer for more than 1 thing. ;-)

>> If you don't have DOS any longer, you could test in Win98, then when it
>> comes to "actual" running tests, use a freeDOS bootdisk.
>>
>> Linux may be your answer, but I'm not expert enough to recommend which
>> distro at this point..... check the comp.os.linux.advocacy

>
> comp.os.linux.embedded would be a much better choice...


Better.
 
Reply With Quote
 
Paul Keinanen
Guest
Posts: n/a
 
      09-03-2003, 07:32 AM
On Tue, 2 Sep 2003 11:16:43 -0700, Amused <(E-Mail Removed)> wrote:

>Anton Erasmus wrote:



>> I am thinking of using a "Real Time" linux on a PC for hosting my test
>> apps. Most of the time I only need to be able to get a number of
>> reasonably accurate "Timer Ticker" tasks in which I Rx/Tx to my
>> embedded system. (Typical 100Hz with 5 to 10% jitter is good enough,
>> 1kHz would be nice)


Assuming that the PC is fairly modern and you do not have a lot of
interrupt load from ethernet, IDE etc. cards, those jitter
requirements (0.5 .. 1 ms typical) does not seem to be too hard to
reach with a patched up 2.4.x kernel. Look for the low latency patch
and the kernel preemption patch.

To get a higher tick rate, you would have to change the HZ constant
and recompile, but of course, you would not get 5-10 % jitter at 1000
Hz :-).

If your external system would have contained a timer that would
generate an interrupt signal at regular intervals, then a device
driver (in practically any OS) could have serviced your device,
without messing around with the OS clock rate.

If you need better jitter performance than that, then you need some
proprietary real time kernel, doing all the time critical things in
various high priority tasks. Instead of running the lowest priority
idle/null task when there is nothing else to do, this null task is
replaced with an ordinary Linux (or Windows NT) operating system, thus
the whole ordinary OS runs simply as the lowest priority real time
task within the real time scheduler. The ordinary OS then schedules
its own processes, when no real time activity is going on in the high
priority RT tasks.

At least the WindowsNT + RT kernel systems are quite expensive and
often require programming the RT part of the application with
proprietary system service calls and may also run completely in kernel
mode, thus without any user mode memory protection.

>With OS/2 warp3 warp4, you are slicing 1 second into about 32 slices, so
>you would be able to do something like 30hz somewhat okay.
>Win9x, NT is similar in structure... and possibly the other windows series.


Time slices and quantums are concepts usually associated with time
sharing systems, in which a large number of equal priority runnable
programs are waiting to get access to the CPU, usually using some kind
of round robin system.

In a real time system everything is executed strictly according to the
different priorities. When the highest priority task after waiting for
an event becomes runnable, the execution of any low priority task is
suspended, the highest priority task gets the control and executes as
long as it needs. When the highest priority task no longer needs the
CPU, the suspended low priority task will continue execution.

Of course, the high priority task must be written in such a way that
it does not consume much time in a single session. I would consider it
a very bad design, if the highest priority task would execute for more
than a millisecond.

Typically, the highest priority task just waits for interrupts or
other signals, then execute a few hundred instructions, before waiting
for the next activation. During the time when the high priority tasks
are waiting for activation, the lower priority tasks may continue.

Paul


 
Reply With Quote
 
Ed Skinner
Guest
Posts: n/a
 
      09-03-2003, 01:42 PM
See RTLinux from FSMLabs (http://www.fsmlabs.com/). It will do everything
you need.

 
Reply With Quote
 
Ultimate Buu
Guest
Posts: n/a
 
      09-03-2003, 04:34 PM

"Anton Erasmus" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> I am finally reaching the end of my patience in trying to keep Test
> code running under DOS/Win98 etc. It is fast becomming a situation
> where I am spending 10 times more time trying to get my test app going
> on a PC than I spend coding the embedded app in the first place.
> I am thinking of using a "Real Time" linux on a PC for hosting my test
> apps. Most of the time I only need to be able to get a number of
> reasonably accurate "Timer Ticker" tasks in which I Rx/Tx to my
> embedded system. (Typical 100Hz with 5 to 10% jitter is good enough,
> 1kHz would be nice)
>
> Is it possible to load the RT components on top of RH9 or some other
> distribution. If so which RT Linux would people recommend. I would
> like to purchase a reasonable starter kit with good docs to get me
> started. If some support exists for porting code from RT Kernel (16
> bit), it would be a bonus.
>
> If versions exists for ARM and PPC for embedded SBCs, it would be even
> nicer.
>


Use eCos (http://sources.redhat.com/ecos/) which is a *real* real-time OS
for embedded applications. It's API compatible with Linux (which means most
Linux software should compile on for it).

There are also ARM and PPC versions available. And it's FREE!!








 
Reply With Quote
 
Amused
Guest
Posts: n/a
 
      09-03-2003, 06:24 PM
Paul Keinanen wrote:

> On Tue, 2 Sep 2003 11:16:43 -0700, Amused <(E-Mail Removed)> wrote:
>
>>Anton Erasmus wrote:

>
>
>>> I am thinking of using a "Real Time" linux on a PC for hosting my test
>>> apps. Most of the time I only need to be able to get a number of
>>> reasonably accurate "Timer Ticker" tasks in which I Rx/Tx to my
>>> embedded system. (Typical 100Hz with 5 to 10% jitter is good enough,
>>> 1kHz would be nice)

>
> Assuming that the PC is fairly modern and you do not have a lot of
> interrupt load from ethernet, IDE etc. cards, those jitter
> requirements (0.5 .. 1 ms typical) does not seem to be too hard to
> reach with a patched up 2.4.x kernel. Look for the low latency patch
> and the kernel preemption patch.
>
> To get a higher tick rate, you would have to change the HZ constant
> and recompile, but of course, you would not get 5-10 % jitter at 1000
> Hz :-).


hehehe.....of course at 1000hz there would be less jitter, but we're
starting to assume a lot based one posting now..... there is a point of no
return where our assumes turns into ass u me ;-)

I know what you're talking about for the rest of your message since I've
been there myself, but I think I'm going to safely leave this "as is" as we
haven't heard any more details from Anton (the original poster).
Anyhow, recent replies are pointing out good sources to look at.
 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Linux user: please support hardware vendors whith good Linux suppor. AnonymousFC4 Nvidia 6 12-29-2005 02:07 AM
Recommend Socket 939 board for Linux (Xandros) gridbias Asus 2 07-28-2005 12:57 AM
please recommend a good laptop for OpenGL, Linux, XP Matt Laptops 6 05-21-2005 08:25 PM


All times are GMT. The time now is 11:18 PM.


Welcome!
Welcome to Motherboard Point
 

Advertisment