home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / robotics / 2719 < prev    next >
Encoding:
Internet Message Format  |  1992-12-23  |  2.3 KB
  1. Path: sparky!uunet!timbuk.cray.com!shamash!ems!hollywood.ems.cdc.com!tbruseha
  2. From: tbruseha@hollywood.ems.cdc.com (Tom Brusehaver)
  3. Newsgroups: comp.robotics
  4. Subject: Re: DOS in real-time, is there a problem?
  5. Message-ID: <31327@nntp_server.ems.cdc.com>
  6. Date: 22 Dec 92 14:36:26 GMT
  7. References: <1992Dec20.153543.537@doc.bmd.trw.com>
  8. Sender: sys@ems.ems.cdc.com
  9. Organization: Empros Systems International, a division of Ceridian
  10. Lines: 40
  11. Nntp-Posting-Host: hollywood.ems.cdc.com
  12.  
  13. In article <1992Dec20.153543.537@doc.bmd.trw.com> nickgill@doc.bmd.trw.com writes:
  14. >Hello,
  15. >
  16. >I am looking for any information on DOS in a real-time enviroment.
  17. >Please e-mail me if you know of any leads on problems that occured
  18. >in a real-time environment or on embedded computers as a result of DOS.
  19. >Thanks,
  20. >Nick
  21.  
  22. I once supported a real-time monitoring system in a factory that was
  23. on a [MS]DOS system.  The whole thing was written in Turbo Pascal, and
  24. used a non-standard graphics display (NEC PC-8000), most of the
  25. comments in the code were in japanese, as were some of the function
  26. names (jikan=time).
  27.  
  28. Bascially there was a central launcher program that would fork off the
  29. actual working tasks.  The one task would read the inputs, and put the
  30. values in a shared memory area.  The next task would process this
  31. fresh data.  The next task was based on the current display desired,
  32. and would put the appropriate information on the screen.  I think this
  33. task would also poll the touch screen (another mess in itself).
  34.  
  35. The main screen would show a summary of the factory.  The next screens
  36. would show the 5 individual areas.  Then there was an individual item
  37. display showing status.  There was also some end of month reports, and
  38. end of year reports.
  39.  
  40. The biggest problem with this whole system was the polled nature.
  41. There were no event driven interfaces (although I suppose there could
  42. have been.  The touch screen processor (yup, a whole processor
  43. dedicated to the screen), queued about 10 actions (touch, release 2
  44. actions, although drag didn't work, and my japanese wasn't good enough
  45. to figure out if it were possible).  The actual problems were reported
  46. down a serial line, and that had a huge buffer also.
  47.  
  48. Also if there were any loops, or any of the modules launched never
  49. came back, nothing got serviced.  The display looked like everything
  50. was working, but something else would report that error.
  51.  
  52. Tommy
  53.