home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / dcom / modems / 16866 < prev    next >
Encoding:
Text File  |  1992-11-15  |  2.9 KB  |  68 lines
  1. Newsgroups: comp.dcom.modems
  2. Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!agate!ames!data.nas.nasa.gov!taligent!kip-9.taligent.com!user
  3. From: creed@blowfish.taligent.com (Creed Erickson)
  4. Subject: Modem/Comm port abstractions
  5. Message-ID: <creed-151192120136@kip-9.taligent.com>
  6. Followup-To: comp.dcom.modems
  7. Sender: usenet@taligent.com (More Bytes Than You Can Read)
  8. Organization: Taligent, Inc.
  9. Date: Sun, 15 Nov 1992 21:09:28 GMT
  10. Lines: 56
  11.  
  12. The recent discussion of 16550 UARTS and Windows comm port abstraction
  13. prompts me to ask this newsgroup for some opinions on the subject of comm
  14. port abstractions.
  15.  
  16. For those familiar with the 16550 and why a FIFO is A Good Thing, skip the
  17. next two paragraphs.
  18.  
  19. If you have a modem delivering bytes to the port at the full bandwidth of a
  20. 14.4Kbaud channel then you have a little less than 700 microseconds to
  21. service a received buffer full interrupt.  For arguments sake, let's add
  22. 2:1 modem compression on top of that and you reduce that time to about 350
  23. microseconds.  In a premptive multi-tasking situation (OS/2, UNIX, or what
  24. have you) which is loaded with a bunch of other interrupt stuff happening,
  25. this is not an abundance of time.  Allowing time for other interrupts and
  26. task scheduling latencies, you could ocassionaly have the machine
  27. effectively locked into interrupt service loops and not get enough time for
  28. the comm program task to process the character before the next one needs to
  29. be read.
  30.  
  31. If a 16550 (16 byte FIFO) is used, this maximum bearable latency goes up
  32. potentially by a factor of 16 to somewhere around 5.5 milliseconds.  This
  33. is a more comfortable timeframe in which to snag characters from the chip,
  34. pass them off to the comm program, and expect the comm program to actually
  35. have enough time scheduled to do something with the data.  This is one
  36. reason there are so many proponents of the 16550 for multi-tasking
  37. environments. The FIFO is a highly desirable feature because it gives
  38. breathing room.
  39.  
  40. It has been said here that Windows abstracts the hardware and presents a
  41. 8250 interface to the software. This seems like a least common denominator
  42. approach. 
  43.  
  44. My questions are (assume FIFOs can be efficiently emulated in software): 
  45.  
  46.    1) Why is the Windows LCD approach the right one?  (Or is it?)
  47.  
  48.    2) Why not abstract the hardware as a 16550? I.E., programs would see
  49. the comm port as a 16550, regardless of what is actually there (8250,
  50. 16450, etc.)? 
  51.  
  52.    3) Using the theory that if something is worth doing then it's worth
  53. over-doing, why not make the base abstraction a 16550 with a 1Kb FIFO?  
  54.  
  55.    4) Let's go one step further and make the abstraction handle a user
  56. specified FIFO size, what's wrong with that?
  57.  
  58.    5) What does this higher level hardware abstraction break? How does it
  59. break it?
  60.  
  61. Thoughts? Opinions? Inquiring minds want to know.
  62.  
  63. Creed Erickson,
  64. Software Dweeb and Spurious Interrupt
  65.  
  66. Opinions expressed here are not neccessarily those of my employer, but I'm
  67. working on it.
  68.