Tue, 18 Apr 2000 Eric Keller wrote:
> Hi, i am trying to port a MS-Dos program over to RTL. This program controls
> the load of a fatigue machine, which is capable of smashing expensive things
> flatter than a pancake.
Cool! *hehe* (Always fun when there's some physical movement involved!
Although, my machines aren't all that powerful... *sob* ;-)
> I think i will use shared memory for some
> communications, but i would like to generate and store my load reference
> trajectories in kernal mode.
>
> The ms-dos program has "trusted" code that generates and stores the load
> trajectories, and then issues a handle to the "user" portion of the program.
> This allows a certain amount of freedom in the coding of the user portion,
> because the trusted code will not let the user part do something stupid.
> The actual controller is implemented as an interrupt service routine.
> When i change load trajectories, the trusted code checks the new trajectory
> for reasonableness and then disables interrupts and then changes some
> pointers, then reenables interrupts.
That is, you want your kernel RTL "driver" to load and verify data that it'll
use for the operation...?
> I like this setup and would like to use it under RTL. My thought is that i
> would like to use a fifo to communicate, but not do all the setup and
> verification in the controller itself. The only thing i don't really have a
> plan for is how to wake up the task that changes trajectories. Can a real
> time thread wait on a fifo?
Well, it can be done, but I've been too busy to keep up, so I don't know if
it's readily availabe in the current versions. Anyway, an alternative is to use
a handler that wakes the RTL thread up when there is [enough] data available.
> I guess the controller could check the fifo,
> but how does the controller wake up the "changer thread" so that it runs
> asynchronously to the controller?
I'm not sure what you mean by "asynchronously" in this context, but sure, the
controller (interrupt handler?) could activate/deactivate the periodic
scheduling of RTL threads and that kind of stuff. However, I think a FIFO
handler that does what your "trusted code" of the DOS version used to do seems
more natural here. I'd try to put the "trusted code" in user space though,
possibly in it's own process (daemon), but there might be reasons why you want
it in the kernel. Are there some kind of hard RT requirements on it? (Of
course, if the code is simple, it might not matter much where you put it, as
long as no one can mess it up.)
> Anybody ever do something like this?
I've hacked drivers with blocking file I/O (RTL posixio) calls... As the I/O
calls run in the same thread as the caller, you can just use the normal RTL
thread sync mechanisms pretty much as if it was right inside your normal code.
David Olofson
Programmer
Reologica Instruments AB
Scheelev�gen 30
S-223 63 LUND
+46 (0)46 - 12 77 60
..- M u C o S --------------------------------. .- David Olofson ------.
| A Free/Open Multimedia | | Audio Hacker |
| Plugin and Integration Standard | | Linux Advocate |
`------------> http://www.linuxdj.com/mucos -' | Open Source Advocate |
..- A u d i a l i t y ------------------------. | Singer |
| Rock Solid Low Latency Signal Processing | | Songwriter |
`---> http://www.angelfire.com/or/audiality -' `-> [EMAIL PROTECTED] -'
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
