techno@lime.in-berlin.de (Frank G. Dahncke) (12/10/90)
The company I work for has just bought 20 Hewlett Packard QS/2 with 20MHz
386/387 and Ethernet to control some robots with. My question now:
What would be the best language to develop applications with, considering
that the available OS can only be OS/2, Xenix 2.5 or DOS 4.1 ?
Thanks for any help,
Techno
--
| techno@zelator.in-berlin.de ||| Please do not e-mail from outside Germany ! |
| techno@lime.in-berlin.de / | \ Hardcore ST user ! ====================== |
| Nothing that's real is ever for free, you just have to pay for it sometime. |
| (Al Stewart) | walden@nairobi.eecs.umich.edu (Eugene Marvin Walden) (12/10/90)
In article <1T4LV0P@lime.in-berlin.de> techno@lime.in-berlin.de (Frank G. Dahncke) writes: >The company I work for has just bought 20 Hewlett Packard QS/2 with 20MHz >386/387 and Ethernet to control some robots with. My question now: >What would be the best language to develop applications with, considering >that the available OS can only be OS/2, Xenix 2.5 or DOS 4.1 ? I am not exactly sure what OS/2 does, but unless it has a clock granularity of less than 1 second, it might be very tedious to do any kind of real-time control. Same thing goes for Xenix and DOS. The reason I mention clock granularity in the OS is that it is often nice to have, for instance, a task that runs periodically every 20 ms to update a register, read a value, etc. If the OSs mentioned above are anything like normal UNIX, then the most precise timing you can get is very approximate-- on the order of one second. For DOS, this is not really an issue, since it is a single-tasking OS. I am opposed to using single-tasking operating systems for real-time applications because the result is a monolithic, rather than a modular, program. Such programs are hard to test if they get fairly complex. If, indeed, the OSs mentioned above do not have more precise timing abilities, like versions of real-time UNIX OSs do, then it is the opinion os this hacker that you are going to have to muck around with using interrupts for timing control. If this is the case, I would probably use C, since C interfaces to assembler quite nicely. Some people I know swear by Turbo Pascal, since it has many extra features that overcome the rigidity of original Pascal. Then there is always trusty old assembler, which will do anything you tell it to do, but it introduces many problems. Real-time systems typically have complex timing requirements. Trying to verify the correctness of a real-time system written in a high-level language with a real-time OS is difficult enough as it is; trying to verify the correctness of a system written in assembler on a network of DOS machines is something I wouldn't wish upon my worst enemy. Anyway, I think your company probably should be asking the question, "What operating system should we use for this system," before asking the question of what language you should be using. Many operating systems have been designed specifically to be used for real-time applications. If you choose to use a non-real-time OS, you may find yourself reinventing the wheel (and I don't even work for a real-time OS company, so there is no ulterior motive in saying this). > Techno Good luck (you'll probably need it) - Eugene Walden