Real Time Networking

C

Thread Starter

Curt Wuollet

Hi all

Sorry for the low profile but I've been working pretty hard on some robot code and have needed to
stay "in the zone". There's been some chatter on display stuff, not my forte but I'm glad to see it. What time I have had to spend on lplc has been looking at realtime issues for very high speed ( eg machine control ) applications. I've been checking out TimeSys, they've put RTLinux and
RTAI together with some tools and it looks pretty interesting. Here's a little more info I ran
across on realtime networking.
wysiwyg://256/http://alllinuxdevices.com/news_story.php3?ltsn=2000-08-30-004-03-IN-LF-CM

I'm trying to determine if this is compatible with the current code, but I'm only getting little bits of time to read the docs and it's tough sledding that way. Haven't heard much from Jiri, did we ever find Mario?

Regards

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet:
> I'm trying to determine if this is compatible with the current code, but
> I'm only getting little bits of time to read the docs and it's tough
> sledding that way.

Docs? What docs? We haven't been writing any docs...

(Actually, we have written a little, but very little.)

> Haven't heard much from Jiri,

Since about June or July I've often been sick, overseas or both. What gaps
there have been I've been trying to do my Uni stuff; so my contributions
have been on the order of one-line here or there, or maybe convert a
#define into a static inline function or something.

> did we ever find Mario?

No worries, it was just a momentary mail misconfiguration.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Hello everybody,

Curt Wuollet wrote:

> I've been checking out TimeSys
> they've put RTLinux and
> RTAI together with some tools and it looks pretty interesting.

I did exactly the same thing a couple weeks ago. I mailed my results to Chetan and Jiri, but
here they are for all to see.

I only used the resource kernel (RK) and not RTAI. I Skimmed through the docs of RTAI and it
seems that the LPLC may need some porting to run there, but maybe not too much.

I ran my very basic PID controller on a 360 MHz PII, with 200 MB RAM. This means all the
code was locked into RAM, so no swapping to disk.

I ran the module at the maximum configurable frequency of 2 kHz (period = 500 us). The code
took around 160 us to execute, most of the time (150 us) in plc_update() (using 2 pages = 8
kB of mem for the LPLC). This can probably be optimized by using plc_update_points();

Sometimes the module execution was delayed, but it practically never missed it's deadline.
All the delays I saw were due to interrupt handling. Typical interrupt handling times I
measured:
int 0 - timer - <=12 us
int 10 - eth - <=120 us
int 14 - ide - <=150 us

> Haven't heard
> much from Jiri, did we ever
> find Mario?
>

I haven't been away. I've mostly been playing with the RT Linux (needed to add some code to
the Linux kernel itself to measure the interrupt handling times), and waiting for Jiri to
come back before embarking on a synchronisation module for the LPLC.

Mario.


--
----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top