Mail Archives: djgpp/1998/08/19/22:47:02
In article <Pine DOT A32 DOT 3 DOT 91 DOT 980819102027 DOT 164952D-100000 AT ieva05 DOT lanet DOT lv>,
Andris Pavenis <pavenis AT lanet DOT lv> wrote:
> I don't think so. Writting driver for rtlinux is not complicated than
> doing it for DOS (I have developed rather compilicated real-time telescope
> control system for satellite objservations under MS-DOS in form of TSR
> that uses hardware interrupts and whether I should repeat this I would choose
> rtlinux)
My point is that I am trying to avoid writing any device drivers at all.
>
> If real time disk or network access is required then (as I think) one should
> reconsider the way of the solution of problem as this is not right way
> (I'm sure of it). Only part that is really required should be hard-realtime.
>
Realtime network access is required. I have to send an ethernet packet to
several devices every millisecond with less than 50 usecs jitter. These
devices need to respond within the millisecond.
This is easily managed from DOS and also from DJGPP using real-mode packet
drivers. My concern about real-mode is that it complicates preemptive
scheduling from the timer ISR. I am not concerned about the overheads
involved in switching modes.
If rt-linux will let me do this real-time ethernet communication without
having to write my own drivers, I am very interested. But the rt-linux
documentation says:
"This structure imposes some restrictions on RT-tasks. They can not easily
use Linux drivers, networking, etc. They can, however, transfer data
to/from ordinary Linux processes through memory buffers."
Memory is cheap and our real-time runs are restricted to 300 secs. Real-time
disk access is not an issue. But protected mode is desirable to get access
to all that memory. I have been managing real-time disk access under DOS
nevertheless.
> The second level of software that must be soft-realtime (data acqusition
> from real time driver for example) can run in user space and use
> sched_setscheduler() to set required priority.
>
The ability to support lower priority tasks and a user interface are
important. That is why I am investigating some sort of scheduling under
DJGPP. Unfortunately, it seems that systems that are strong in this area
are weak in the hard real-time area.
> Also disabling timer interrupts will break other things in system.
I've been running real-time DOS programs with the timer interrupt disabled
for several years. Nothing has broken yet. The system clock loses time
but that is no problem.
Don't get me wrong, I appreciate your input. My requirements are perhaps
atypical. Hard real-time ethernet communication is not commonly used.
I do hope to replace all ethernet links with reflective memory. That will
change the situation considerably. Rt-linux will be much more attractive
then.
Russell
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
- Raw text -