RT Linux (was: LinuxPLC: POSIX timer functions)

K

Thread Starter

Ken E.

Hi Mario,

You are correct about the pointer thing. I wish that RTLinux(TM) had some sort of process MMU protection of some sort. I guess to have determinism it is worth the risk for some people. They also have a debugger which you can supposedly run all the time that helps to safeguard a lot of these kinds of problems ... I am currently researching and developing for RTLinux now and haven't gotten that far yet.

I like your idea of trying out a port of Puffin on RTLinux at the early stage. As far as device drivers, you have direct access to the IO ports ( inb() outb() , etc) and also direct access to memory but you have to use some function calls first. My guess is that any device driver written for direct access would port very nicely. You might have to add some ifdefs or something to the code, but other than that the code should be the same I would think. The biggest problem with running puffin in RTLinux (I am guessing) will be in the segregation of real time space and linux space. This becomes most apparrent with the HMI interfaces and such which need linux services. I will be willing to contribute as time goes on with helping to acheive this. Right now I am in a learning curve with RTLinux(TM), but it is subsiding a bit. I'll let you guys know as I learn.

~Ken

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
My first transmission came back with errors, trying again...

In a message dated 6/7/01 7:56:40 AM Eastern Daylight Time, [email protected]
writes:

<< Subj: RT Linux (was: LinuxPLC: POSIX timer functions)

>
> as for the scan value, 32 bit is fine I think. The most frequent need to
increase the scan time is to get better average free CPU time, but when you
get up into seconds and minutes, it doesn't really matter I think. I would be
definitely happy with a scan of 1us to 71 minutes!

Anyway, you have convinced me that 1 ms resolution is not enough! I'll
change this as soon as I get the chance. But I still think 71 minutes
is not enough!
>>

Apologies if I overlooked part of this exchange, but are we talking scan period or timer resolution here?

Timer Resolution:
If it's timer resolution vs. duration, perhaps we can live with two timer classes, one high precision timer with a 1 microsecond resolution (or less), and an extended-range timer with 1
second resolution. (Typically, the longer period you are measuring, the less precision you
require).

Scan Rate:
Presumably module scan rate is an externally regulated rate. That is, scan rate is not enforced by the code being run at that rate (with the exception of a "change scan rate" call), but by an outer level (e.g. operating system) level.

I don't think it's unreasonable to have the externally controlled scan rate at 60 minutes or less and force the module itself to do it's own "give up my scan" when it's own long-period timer hasn't yet elapsed.

i.e. a given code module is run every hour or faster, and if it wants a daily scan, the first instruction is basically "has a day elapsed? no->exit, yes->continue"

Rufus

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

Mario de Sousa

[email protected] wrote:
> (...)
> Apologies if I overlooked part of this exchange, but are we talking scan
> period or timer resolution here?

Scan period.

(...)
> Scan Rate:
> Presumably module scan rate is an externally regulated rate. That is, scan
> rate is not enforced by
> the code being run at that rate (with the exception of a "change scan rate"
> call), but by an outer
> level (e.g. operating system) level.
>
> I don't think it's unreasonable to have the externally controlled scan rate
> at 60 minutes or less and
> force the module itself to do it's own "give up my scan" when it's own
> long-period timer hasn't yet
> elapsed.
>
> i.e. a given code module is run every hour or faster, and if it wants a daily
> scan, the first instruction
> is basically "has a day elapsed? no->exit, yes->continue"
>

Yes, this is possible, but it would be better if we could avoid it. Especially considering it doesn't take too much effort to avoid it, which seems to be the case at the moment.

Cheers,

Mario.

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

The box said it requires Windows 95 or better, so I installed Linux

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