real-time summary

J

Thread Starter

Jiri Baum

Hello,

(trying to summarize and wind up the thread here)

It seems to me there are four main options:
1. normal (ie, no attempt at real-time)
2. standard soft realtime
3. KURT soft realtime
4. RTlinux hard realtime

Of these, 1-3 can basically run the same programs, with a few extra syscalls added in for the real-time bits.

Option 4 requires that the programs be written as kernel modules.

Is that right?

If so, I suggest we go for options 1-3, leaving the choice up to the implementor of each system.


Jiri
--
Jiri Baum <[email protected]>
On the Internet, nobody knows if you are a @{[@{[open(0),<0>]}-1]}-line
perl script...

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S
Mostly I agree with you. However after having read the KURT documentation, it is my impression that implementing it would require
some major rewrites of the various tasks that needed to run under it.

Maybe someone with more knowledge about this can correct me?

--
Stan Brown [email protected] 843-745-3154
Westvaco
Charleston SC.
--

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
B
My understanding of RTLinux is that it will execute generic C code, as long as you do not make any system calls. As long as we stick
with ANSI C and write our own I/O drivers, I think that our code could be ported to many environments.

An important point for portability is to separate the machine specific and the non machine specific code. Everything except I/O drivers should
be done in ANSI C without concern for any operating system. We will need low level calls like inport() and outport() and ioperm() in our device drivers.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Sun, 23 Jan 2000, Bill Sturm wrote:

> My understanding of RTLinux is that it will execute generic C code,
> as long as you do not make any system calls. As long as we stick
> with ANSI C and write our own I/O drivers, I think that our code
> could be ported to many environments.

I wasn't aware that any standard device driver (kernel) could make syscalls anyway (barring stuf like printk). I thought the RT issue was more one for the scannerws and logic engines which will be using semaphores at least.


Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
B
Stan Brown wrote:
>
> On Sun Jan 23 19:37:03 2000 Bill Sturm wrote...
> >
> >An important point for portability is to separate the machine specific
> >and the non machine specific code. Everything except I/O drivers should
> >be done in ANSI C without concern for any operating system. We will
>
> I really don't think you mean we should invent our own system libraries, do you :)

I am suggesting that we avoid making any system calls. All of our I/O is going to be custom anyhow. For things like serial and ethernet I/O, Linux has file based interfaces that can largely be called from ANSI C.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
On Thu, 27 Jan 2000, Bill Sturm wrote:

> Stan Brown wrote:

> > I really don't think you mean we should invent our own system libraries, do you :)
>
> I am suggesting that we avoid making any system calls. All of our I/O is going
> to be custom anyhow. For things like serial and ethernet I/O, Linux has file based
> interfaces that can largely be called from ANSI C.

And how are you going to access those files withou making system calls?

ANSI C open() calls a system call.
ANSI C read() calls a system call.

There is no way around it unless you access the hardware directly.

Dave West E-Mail: [email protected]
Semiras Projects Ltd. PGP public key available on request.


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