mike@penguin.gatech.edu (Mike Gourlay) (11/29/90)
Hiya, I know a way to test whether the serial port can _send_ data; nohup sleep 999999999 < /dev/serial & ; stty raw 9600 < /dev/serial and then cat > /dev/serial, and hook up something like a dumb terminal or a printer to see if that part works. I have done that, and it does work. Now I want to test if the computer can _receive_ data okay. How do I do it? I figure it's a similar process. My serial port has failed to propperly connect to a laserjet and an NIU (modem like thing), and in both cases, the computer could send data, but did not act as if it were receiving any. In the case of the printer, the printer's XON/XOFF was ignored, so the computer flooded the printer with data after the printer requested that the data flow be stopped. The computer even ignored the printer's dropped DTR. Some hardware guru help me please!!!! Is there a hardware HP number I can call and yell (calmly) into? Does anybody know what each of the 9 pins in a HP 9000 370 do? So far I've guessed: pin function --- ------ 1 chassis ground 2 transmit data 3 receive data 5 clear to send 6 data set ready 7 signal ground Are these right? What about 4, 8, and 9? Are there pins for DTR or RTS? Why is the computer ignoring a dropped DTR? is it ignoring a ^S (if in fact it is getting them)? How do I test to see whether the computer is getting any data at all? I know I can cat _to_ /dev/serial, but can I cat /dev/serial? Do I need to write a C program and open /dev/serial and read from it as a stream? If so, could someone test such a program before I use it and assume that the computer isn't working? Thanks, I'm desperate, Mike Gourlay, mike@penguin.gatech.edu
panek@hp-and.HP.COM (Jon Panek) (11/29/90)
| Some hardware guru help me please!!!! Is there a hardware HP | number I can call and yell (calmly) into? | | Does anybody know what each of the 9 pins in a HP 9000 370 | do? So far I've guessed: | pin function | --- ------ | 1 chassis ground | 2 transmit data | 3 receive data | 5 clear to send | 6 data set ready | 7 signal ground | | Are these right? The complete pin-out for a 9-pin RS-232 connector (DCE) is as follows: pin function --- --------------- 1 CD Carrier Detect 2 RX Receive Data 3 TX Transmit Data 4 DTR Data Terminal Ready 5 GND Chassis Ground 6 DSR Data Set Ready 7 RTS Request To Send 8 CTS Clear To Send 9 RI Ring Indicator And so to get this to work, you need to connect DCE DTE --- --- TX RX RX TX GND GND DTR DTR DSR DSR RTS RTS CTS CTS You can safely ignore RI and CD, usually. The lowest-level "handshake" are the RTS/CTS and DTR/DSR signals. The DTR/DSR are supposed to be used for "On-Line" or "Connected" type info- rmation, and has been used as a level 1 handshake. Depending on how the software is written, the RTS/CTS lines may or may not make a difference. Some port drivers require these lines to be set correctly before they'll squirt information out the port. I would recommend you buy the correct, full-fledged cable for your application and see what happens. I have spent, literally, days of accumulated time hacking up RS-232 cables of various flavors and vintages, and still find that I can spend additional hours on each one connecting, cross-connecting, looping back, or grounding any or all of the various hardware handshake lines. Good Luck. Jonathan Panek Hewlett-Packard, Andover Division panek@hp-and.an.hp.com (508) 687-1501
wehr@fmeed1.UUCP (Bruce Wehr) (11/29/90)
In article <1990Nov28.111522@dali.gatech.edu>, mike@penguin.gatech.edu (Mike Gourlay) writes: > > Now I want to test if the computer can _receive_ data okay. > How do I do it? I figure it's a similar process. A quick way to check communication in both directions is using a dumb terminal and cu. Connect the tube to /dev/serial, and fire up cu -l/dev/serial -s<baud> Anything you type on the computer should appear on the tube (you apparently have this direction working already). Similarly, anything you type on the tube should appear on your system's monitor. > is it ignoring a ^S (if in fact it is getting them)? That could be your stty values. Look at ixon and ixoff. > Why is the computer ignoring a dropped DTR? That could be the minor number. [Gone for several minutes .. trying to be helpful .. searching through manuals] I'm back, and I can't believe it! I can't find what I'm looking for in *any* of the manuals! I've recently started as HP-UX administrator at a new location, after being administrator somewhere else for almost 5 years. This activity got HP-UX for the first time just recently. The manual set here is different than what I had at my previous assignment. I was searching for the definition of the minor number bits for serial ports. This information is in one of the two SysAdmin manuals at my previous location under "Adding Terminals and Modems." But, I don't remember exactly what it says. The two new SysAdmin manuals at this location are called "SysAdmin Tasks" and "SysAdmin Concepts". For adding terminals and modems, SAM does all the work. The only guidance I got was that "The minor number's makeup is different for different devices. The `Installing Peripherals' manual gives specific minor number information." [p9-3, SysAdmin Concepts] Well, the "Installing Peripherals" manual basically says, "You want to connect a terminal? The last digit for your minor number is 4. You want to connect a modem? The last digit of your dial-in file is 0, and the last digit of your dial-out file is 1." And, rather than spending a page explaining how the minor number is put together, they waste 2 pages with these asinine tables saying "If your select code is XX, then your minor number is 0xXX0004, and if your select code is YY, then your minor number is 0xYY0004, and if ..." No explanation as to how to form the minor number yourself - nothing about what each bit does (like they did in the old manuals). BULL SCHTICK!! TELL ME WHAT EACH BIT DOES, THANK YOU VERY MUCH!! I even checked the place you're *supposed* to go to for minor number information (manual section 7) - termio(7). They talk all about port access interlock, direct connections vs. modem connections, simple modem control vs. CCITT modem control. But, it doesn't say *jack* about which minor number bits enable which mode! BULL SCHTICK!! TELL ME WHAT EACH BIT DOES, THANK YOU VERY MUCH!! Now, with a little memory jogging, I seem to remember that bit 0 defines dial-in vs. dial-out for port access interlock, bit 1 defines simple modem control vs. CCITT modem control, bit 2 defines direct connection (ignore modem controls completely) vs. modem connection, and bit 3 has something to do with hardware handshaking (don't rememeber what). But, I can't seem to remember which way each bit should be set for which function. And, I can't seem to find it anywhere in the new manual set. BULL SCHTICK!! TELL ME WHAT EACH BIT DOES, THANK YOU VERY MUCH!! Tell me ... where am I *supposed* to go to get specific minor number information? Is my new location missing a manual? Tell me, *please*, in which manual I'm supposed to find this stuff. I'm hoping that I'm simply missing a manual, rather than HP deciding to "make things easier" for me. Sorry about that tirade. Now, back to the original question: > Why is the computer ignoring a dropped DTR? That could be the minor number. I believe that, if your minor number ends in 4 (as the "Installing Peripherals" manual would suggest for terminals), you've selected a "direct connection." This ignores all modem control lines, including DTR. I think your minor number should end in 0 or 1 (wait till someone answers my tirade to find out which way :-) I hope this helps. And, I hope this answers more questions than it raises. -- Bruce Wehr (wehr%dptc.decnet@srlvx0.srl.ford.com) (...uunet!mailrus!sharkey!fmeed1!wehr) (wehr%fmeed1.uucp@mailgw.cc.umich.edu) Ford Motor Company - Engineering Technology Services P.O. Box 2053, Room 1153, Dearborn, Michigan 48121-2053 (313)337-5304