> I'm happy to introduce my Real Time port to uClinux.
[ ... ]
> About a few weeks ago, Bernhard Kuhn posted his RTEC v0.4 in this mailing
> list. And I was very excited for hearing that. But after patching RTEC to
> uClinux and testing on uCsimm, I realized that it didn't works correctly in
> real hardware.
That's quite simple to explain: the patch was only against xcopilot
and didn't affected other plattforms (since i hadn't real hardware
[ ... ]
> So, i just waited another posting from Bernhard Kuhn.
> But Bernhard Kuhn said, in his mail, that RTEC v0.4 is his final release
> becase hi didn't want to re-invent wheel.
Spending more time on RTEC for xcopilot would have ment to reinvent
the wheel ... :-) (It was only ment to be a basic playground)
> Does this mean that some official RT porting is progressing?
What does official mean in the linux-context?
Arnold Niessen from the Philips Research Labs lend me a uCsimm,
that i got last week ... Just today evening i intended to
push RTEC from xcopilot to uCsimm ... so you had a realy good
timing announcing your results!
> But i coudn't wating, i'm a silly person who cannot wait yet
> unknown future event.
IMHO, with open source software that is a rather inteligent behavior!
> Therefore i've hacked uClinux based on Burnhard Kuhn's great job.
> After Some hard work and surveying papers from RTL site, i decided that
> i must start from basics.
I had a similar experience: if you are not familiar with the
RTL (RTAI as well) source code, then it is easier to
start your own implementation, but it doesn't make much sense
to go the full way, because if you are coming to schedulers,
fifos and semaphores, you will realize, that you are just reprogramming
what's already existent :-)
> My porting is based on RTL release 9J (it's for 2.0.36), and have almost no
> differences from original code except hardware specific sti/cil emulateion code
> in entry.S
> RT-fifo, RT-scheduler is the same with RTL release 9J and as you geuss
> RT interface routine is exactly that of RTL realease 9J.
Wow, that's realy fine! So you succeeded, where i failed with my
first try :-)
> I'm now seeing two rectagular waves on my oscilloscope and it's beautiful.
> one has 4 msec interval and another has 5 msec interval. Drift is about
That sounds quite ok: with RTEC/xcopilot i had "emulated" latencies
with about 50-100 탎 (16MHz) - but testing with real hardware,
is much better, of course!
> And this wave is running about 24 hours and keeps going.
> I tryed 'ping -f 192.168.1.200' (this ping flood test will almost hang
> uCsimm with normal uClinux) and wave does not change. Yah, it works!
> and tested frank example (an example in the examples directory of RTL
> release9J which
> test ft-fifo with one control rt-task and two periodic task) and it works
That's realy good and exciting news!
> I'm preparing my patch for uClinux 2.0.38, and all of you could see it
> within a week.
I hardly can await it!
> BTW, May RTL from rtlinux.cs.nmt.edu be changed to have another interface
Not very likely with version 0.x/1.x ... btw: was there a specific reason
for using 0.9J? the current version is 1.3, but AFAIK Versions 1.0 to 1.2
had a strange timing problem ...
> and that's the reason what Burnhard Kuhn thought?
> If that's true, then i'm silly for this temporary job.
No, i think your work will stay permanent:
Currently, FSMlabs don't spend much time on improving Version 1.x,
since they are working on RTL3.0 (with PPC-Support).
RTL-versions 2.0 and up have a posix-like api, but the basic
concept is of course quite the same as with 1.x.
So if you (we?) like to join the current efforts of FSMLabs, then
we should do a backport from RTL3.0 to uClinux-2.0.38.
I took a look into the source code of RTL3.0pre3:
looks much better arranged and prepared for porting
to other platforms than 1.x or 2.0, but i think that is because
the linux-kernel itself was strongly rearranged that
makes things easier for both, "standard"- and "real-time"-developers.
IMHO, it should be feasible to do a backport of RTL3.0,
but since the "target-kernel" is a 2.0.x, i assume, that it
will be harder than porting 0.9J (that was intended for
kernel 2.0.x). At least, i tried to backport RTlinux-2.0 directly
to uClinux-2.0.38.x and didn't make fast progresses. But that
doesn't mean very much, since i'm not a "hard-core programmer".
Another way would be to "upgrade" uClinux to kernel 2.4.x, but
that wouldn't be a simple task ...
But the best way, IMHO, would be to stay with uClinux-2.0.38.x
and RTLinux-0.9J (or maybe 1.3, later) since both are
convenient for most embedded applications the uCsimm can be
used for. Or do you need SMP, video for linux, quality of
service, etc. for the 683xx? Not very likely! Ok, it
would be nice to have a - what Phil Wilshire would
call - pointy-haired-posix, but IMHO, that's not necessary
for new developments.
So my suggestion would be to stay with uClinux-2.0.38.x and
This message resent by the email@example.com list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:34 EST