home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / dcom / modems / 12014 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  3.3 KB
  1. Path: sparky!uunet!hayes!tnixon
  2. From: tnixon@hayes.com
  3. Newsgroups: comp.dcom.modems
  4. Subject: Re: Hardware vs xon/xoff flow control.
  5. Message-ID: <5865.2a8a3f6d@hayes.com>
  6. Date: 13 Aug 92 10:54:37 EDT
  7. References: <1992Aug11.185428.13958@tvnews.tv.tek.com>
  8. Distribution: usa
  9. Organization: Hayes Microcomputer Products, Norcross, GA
  10. Lines: 58
  11.  
  12. In article <1992Aug11.185428.13958@tvnews.tv.tek.com>,
  13. dougs@tvnews.tv.tek.com (Doug Stevens) writes: 
  14.  
  15. > We're having a disagreement about how 'standard' use of hardware flow control
  16. > (that is, RTS-CTS signalling) is for serial communications. I know that the
  17. > the RS232 'standard' is not really a standard (in the sense of having all 
  18. > details fully specified), but how off-the-wall is use of hardware
  19. > flow control? 
  20.  
  21. Hmmm.  As a member of the TR-30.2 standards committee on Data 
  22. Transmission Interfaces, which is the formulating committee for 
  23. EIA-232, I must first object (in a good-natured way, of course) to 
  24. the characterization of EIA-232 as being "not really a standard" or 
  25. "[not] having all details fully specified".  I can only imagine that 
  26. comment coming from someone who has not read the document. Certainly 
  27. there are a lot of devices in the field which use the term "RS-232" 
  28. very loosely, but that does NOT imply any defect in the standard.
  29.  
  30. EIA-232-E most definitely includes specific provisions for hardware 
  31. flow control, as does CCITT Recommendation V.24 and ISO 2110 (the 
  32. "international" EIA-232).  Flow control of transmitted data is done 
  33. by the Clear to Send circuit (V.24 circuit 106), and flow control of 
  34. received data is done by the Ready for Receiving circuit (V.24 
  35. circuit 133).  In a typical implementation, circuit 133 uses the 
  36. same physical wire as circuit 105 (Request to Send) when such flow 
  37. control is being used, and circuit 105 is assumed to be in the ON 
  38. condition.
  39.  
  40. > We need to be able to operate to 115 Kbaud and transfer binary data. Does
  41. > anyone know whether packages that operate at this speed and do binary transfer
  42. > (LapLink and Commute come to mind as examples) use hardware flow control?
  43. > Do any packages use xon/xoff to do this?
  44.  
  45. I doubt that any of these packages use XON/XOFF.  They most likely 
  46. use flow control at a block level (since they're all 
  47. protocol-based) or hardware flow control.  XON/XOFF would not be 
  48. acceptable because it is not transparent to all data patterns unless 
  49. you apply some type of transparentization scheme, but that would 
  50. reduce throughput.
  51.  
  52. > The statement has been made that many communication packages commonly used on 
  53. > the PC have no provision for dealing with hardware flow control. How true is 
  54. > this? 
  55.  
  56. Perhaps it was true at one time, but these days virtually all comm 
  57. programs support RFR/CTS ("RTS/CTS") hardware flow control.
  58.  
  59. > Another statement was made that QuickBASIC has no provision for using
  60. > hardware flow control. I don't use BASIC; is this true?
  61.  
  62. That wouldn't surprise me, but I can't say for sure.
  63.  
  64. -- 
  65. Toby Nixon, Principal Engineer      | Voice   +1-404-840-9200  Telex 401243420
  66. Hayes Microcomputer Products, Inc.  | Fax     +1-404-447-0178  CIS   70271,404
  67. P.O. Box 105203                     | BBS     +1-404-446-6336  AT&T    !tnixon
  68. Atlanta, Georgia  30348             | UUCP uunet!hayes!tnixon  Fido   1:114/15
  69. USA                                 | Internet                tnixon@hayes.com
  70.