home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / next / programm / 7144 < prev    next >
Encoding:
Internet Message Format  |  1992-11-11  |  3.2 KB
  1. Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!sol.ctr.columbia.edu!ira.uka.de!chx400!urz.unibas.ch!lucy.ifi.unibas.ch!news
  2. Newsgroups: comp.sys.next.programmer
  3. Subject: Re: Serial port communication difficulties 
  4. Message-ID: <1992Nov11.091546.5251@urz.unibas.ch>
  5. From: frank@ifi.unibas.ch (Robert Frank)
  6. Date: Wed, 11 Nov 1992 09:15:46 GMT
  7. Reply-To: frank@ifi.unibas.ch
  8. Sender: news@urz.unibas.ch (USENET News System)
  9. References: <1992Nov10.115012.29368@doug.cae.wisc.edu>
  10. Organization: Institut fuer Informatik
  11. Nntp-Posting-Host: woodstock.ifi.unibas.ch
  12. Lines: 55
  13.  
  14. In article <1992Nov10.115012.29368@doug.cae.wisc.edu>  writes:
  15. > 
  16. > Friends,
  17. > This may be more UNIX than NeXT, but here goes.
  18. > 
  19. > I've been trying to get two way communication between a cheapy slave computer
  20. > and to a Next through their serial ports to shuffle data back and forth.
  21. > 
  22. > On the slave I can easily check the ports status, and if there is data,
  23. > I can read it off byte by byte. Writing is also smooth.  There are
  24. > good routines to make sure it doesn't get hung. 
  25. > 
  26. > But on the Next, it seems much harder.  I simply thought by opening
  27. > a file being /dev/cua, I could check the ports status via feof().
  28. > But alas, it always says theres more data there, and so it continially
  29. > gets hung on reading after the lasst charachter is read.  I tried all 
  30. > sorts of variations with the cable, conecting various permutaions of 
  31. > RTS/CTS and so on, but to no avail.
  32. > 
  33. > In sum, the Next has no trouble reading the data from the port.
  34. > But its only problem is that it can not find a correct answer 
  35. > for the status of the port.
  36. > 
  37. > Is there a simple solution or a better way?
  38. > 
  39. > I'll sumarize if theres enough interest.
  40. > 
  41. > Thanks,
  42. > Victor
  43. > v_white@janus.ece.wisc.edu
  44.  
  45. Just went through NeXT answers and found this about the serial devices and flow  
  46. control. It's possibly not what's causing you headaches but you mentioned  
  47. trying different RTS / CTS settings:
  48.  
  49. On 68040 systems, the /dev/ttyfa, /dev/ttydfa, and /dev/cufa (and corresponding  
  50. serial port B devices) may be used to enable flow control on the serial port  
  51. via the RTS and CTS signals. When the serial port is accessed via these  
  52. devices, output on the port will be halted whenever the CTS signal is  
  53. deasserted and resumed when CTS is asserted by the remote host. The RTS signal  
  54. will be asserted by the NeXT system whenever the NeXT system can receive input  
  55. on the port and will be deasserted when further input can not be accepted. When  
  56. the /dev/ttyfa, etc. devices are not used (e.g., the port is opened as  
  57. /dev/ttya), RTS is always asserted while the device is open and CTS is ignored.
  58.  
  59. To enable RTS and CTS you must use the /dev/ttyfa or /dev/cufa devices.
  60. But does this change the behavior of EOF???
  61. -Robert
  62. --
  63. Robert Frank                         tel. + (061) 321 99 67                 
  64. Institut fuer Informatik             fax  + (061) 321 99 15                 
  65. University of Basel, Switzerland                                            
  66. Mittlere Strasse 142      rfc822: frank@ifi.unibas.ch (NeXT mail accepted)  
  67. CH-4056 Basel          X400: S=frank;OU=ifi;O=unibas;P=switch;A=arcom;C=ch
  68.                    ( if all fails try frank@urz.unibas.ch )
  69.