home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / dcom / modems / 10884 < prev    next >
Encoding:
Internet Message Format  |  1992-07-21  |  1.3 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!randvax!edhall
  2. From: edhall@rand.org (Ed Hall)
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re:  Serial and Parallel interface ??????
  5. Message-ID: <3622@randvax.rand.org>
  6. Date: 21 Jul 92 22:52:07 GMT
  7. References: <zgam_3l.wolfgang@netcom.com> <clemon.08gc@lemsys.UUCP> <1992Jul21.205557.29123@cc.ic.ac.uk>
  8. Sender: news@randvax.rand.org
  9. Organization: RAND Corporation.
  10. Lines: 20
  11. Nntp-Posting-Host: ives.rand.org
  12.  
  13. The problem isn't serial vs. parallel.  After all, from the CPU's
  14. perspective, it gets eight bits at a time either way.  Whether
  15. serial-to-parallel conversion occurs on the interface card or not
  16. doesn't change the CPU timing requirements at all: without hardware
  17. buffering, each character must be dealt with as it arrives.
  18.  
  19. The issue here is flow-control and buffering.  Interrupt-per-character
  20. is simply a dumb way to do things.  Flow-control should be a hardware
  21. function, and should be able to work fast enough to prevent
  22. character lossage.  The "handshake" used by the PC printer port
  23. allows for this, but this has nothing to do with it being a parallel
  24. port.
  25.  
  26. Serial solutions to the problem already exist, in the form of "smart"
  27. serial cards and (to a lesser extent) UARTs with small amounts of
  28. buffering (like the 16550A).  Why blame modern OS's for problems
  29. caused by antiquated interface cards?
  30.  
  31.         -Ed Hall
  32.         edhall@rand.org
  33.