Trouble with serial cable to a Windows PC

[scottd431]

I have an odd situation, we have a program we wrote that runs perfect communicating via serial port with RH Linux and we have the identical program for SCO, and we are changing the port identifier between the 2 OS (for example S0 for Linux and 1a for SCO), we are using an 9pin serial cable (custom made) utilizing pins receive, transmit, and ground (total of 3). We take the exact cable and move it from the Linux box that works perfect to the SCO and we get nothing. Seems like there is something with the OS that could be the issue because RS232 is RS232, do you have any idea if it is something caused by SCO or should we use another pin-out. It seems really strange. I appreciate any help.

 

[apeasecpc]

I am not sure if I understand the situation correctly. Are you using the windows computer as a terminal to the SCO box, or is this special software on the SCO box that is triggering some kind of process on the windows computer based on the signal over the port.

Here's what to check if it is a terminal related issue:


First, before making any configuration changes, make sure both the modem control and non-modem control versions of the port are disabled:

disable tty1a
disable tty1A


Second, make sure the terminal type is defined for that port.
The file /etc/ttytype should contain a line similar to:

ansi tty1a

Other terminal types such as "vt100" may also be used (see the "terminals" man page for a list of valid types).

It is also a good idea to define the terminal type for the modem control version of the port (tty1A).

ansi tty1A

Third, make sure the port has a valid gettydef entry.
The file /etc/inittab should contain two lines similar to:

Se1a:2:off:/etc/getty tty1a n
Se1A:2:off:/etc/getty -t60 tty1A n

Note: If the port is currently enabled it will say "respawn" instead of off. Do not alter the contents of the files while the port is enabled.

Also note: The last field on each line sets the communication speed ("n" happens to be 19200 on my system). Use a value defined in your /etc/gettydef file that matches the speed you want. I recommend you use one of the "a" through "n" entries. I do not recommend speeds above 19200 for a terminal.

Make sure the the exact same entries from the /etc/inittab file are also in the /etc/conf/init.d/sio file.


Fourth, enable the port.
If this port is just going to be used for a terminal you can probably use the non-modem control version of the port:

enable tty1a

Or if this port is going to be used for file transfers or printing, you may want to use the modem control version of the port to allow for hardware flow control:

enable tty1A

But do NOT enable both versions of the port.


If this is not a terminal related issue, you should try using the modem control port (tty1A) instead of the non-modem control port (tty1a).

If this doesn't help, try posting some more detail about what your program is designed to do.

 

[edfair]

RS232 is RS232 but you haven't said anything about what handshaking you are employing. And you haven't considered what the actual chips may require.

Try connecting the RTS/CTS and DTR/DSR handshake pins together at the SCO connector.

And is it send, receive, ground or send, receive , and common? There is a difference, and wierd stuff happens if you use the wrong one.

You could also short the send and receive lines at the SCO end of the cable and verify that the win box is receiving. Ed Fair
unixstuff@juno.com
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.

 

[mramo]

Hi,

I had a similar problem using Unixware instead OPenServer : it happends because Unixware needs some RS-232 pins active to open the port.

In a DB9 connect pins 1,4,6 and 9 ( DTR with DCD and DSR,CTS ) and it going to work.

SOLUTION B:

There is another solution if the program is coded by yourself: When opennig the port set the O_NONBLOCK flag in the "open" system call. But then, the read procedures will not block and you'll need another delay procedure ( anyway, if you need it a delay you'll see it by observing the CPU consumption of your program.

Regards.