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.
Similar Threads
Linear Mode
