From: russell DOT thamm AT dsto DOT defence DOT gov DOT au Newsgroups: comp.os.msdos.djgpp Subject: Re: Realtime & DJGPP Date: Thu, 20 Aug 1998 01:34:01 GMT Organization: Deja News - The Leader in Internet Discussion Lines: 64 Message-ID: <6rfue9$vat$1@nnrp1.dejanews.com> References: NNTP-Posting-Host: 203.5.217.4 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk In article , Andris Pavenis 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