UNIX for Dummies Questions & Answers

Sorry, typo on the my post.
With the command

Code:

stty -F /dev/ttyS0 9600

, There is no output message. The cursor moves to the next line ready for the next command.

When I run the command on the UNIX system

Code:

stty 9600 < /dev/tty00s

the cursor moves to the next line, but there is no command prompt #. I don't know what the exact term for this is, but I can still type to the screen and press enter, but there is no command processed. This probably means that /dev/tty00s isn't the correct serial port, right?

It may mean it's having trouble opening the serial port -- that the shell tries to open it to redirect into it, and is stuck waiting for it to become ready.

It may need the cable to be plugged in. It may even be waiting for the other end to be ready. And, of course, it may be the wrong port.

I tried stty with all 4 of my tty files. It seems to pass the command with no message if I use tty, but the other 3 stop and wait. If I press delete on either of those three, I get the message

Code:

/dev/tty00s: could not open

.

An interesting thing did happen. I had Ubuntu run

Code:

cat /dev/ttyS0

while I tried some of the echo commands within UNIX. I switched my monitor (working with one monitor, makes it a little more difficult) and I guess the graphics had crashed on Ubuntu. I told it to run in low graphics for this session. It went to a command prompt to reload the graphics, and one line said this

Code:

Stopping System V runlevel compatibility

I don't know if this is standard with Ubuntu, or if it was set up to talk to UNIX. It makes me think that Ubuntu is reading UNIX, but I'm not using the correct device file within UNIX.

edit....
There is another tty file called systty. It seems to behave much like the file tty.

/dev/tty is a special device that ends up just pointing to your own terminal.

You are opening these files with the cable plugged in and the other end trying to write?

Could these ports be in use already on your UNIX machine, for login prompts or something?

The cable is plugged in to both computers. I'm not real sure if the ports could be in use or not. I don't see how they could be used for login prompts, as it is a standalone computer on no network.
These are the exact steps I have been taking...

Log onto both computers.
On Ubuntu, I run from a root user terminal

Code:

stty -F /dev/ttyS0 9600

I receive no message, so I assume the command went through.
I then swap to UNIX, logged in as root, and run

Code:

stty 9600 < /dev/tty00s

The screen then goes to the "waiting mode" with no real prompt, only a cursor. If I press DEL, I receive the message

Code:

/dev/tty00s: cannot open

I tried that command using tty00h and tty00 as well. I pressed DELETE after a couple seconds, how long should I wait for it try to connect?

Correct me if I'm wrong, but I think of the commands like this.

Code:

stty -F /dev/sttyS0   |   stty 9600 < /dev/stty00

This attempts to open said devce and connect to the computer on the other end of cable to set up communications.

Code:

cat /dev/ttyS0    // From Ubuntu, Opens ttyS0 for reading

Code:

echo "Hi" > /dev/tty00h   // From UNIX, Write "Hi" to tty00h. "Hi" should appear on other Ubuntu screen

Okay.

It does not prepare one end for reading and the other for writing. It sets the baud rate on the serial port so that they can send letters to each other instead of gibberish.

It has to open the device file to do so, though! And depending on how it's configured, it may be waiting for some signal line or other to be set 'ready' on the far end.

Serial ports have the ability to tell each other when they're ready. Hardware flow-control means "if this bit on the serial port isn't active, wait before sending more data". It may be waiting for that bit to be set before letting you open the port. It's possible to turn off this flow control, probably, but to do so you have to open the port! Grrr. I take it your UNIX system has nothing for 'man stty'.

So when I say 'writing' I mean that literally. After you do 'stty -F /dev/ttyS0 9600' on Ubuntu, do 'echo asdf > /dev/ttyUSB0' to set that bit, so that it knows there's something on the other end. Ubuntu may wait too, until the other end is open, to send the data.

And, of course, we have no idea if you're even opening the right device

Because I did a lot of service work with equipment running serial ports my diagnostics included a laptop with a terminal emulator looking at the signals crossing between machines. Only used the Rx and common lines and could connect to the Tx of either side. Trying to figure out what is going on with 2 not communicating can be impossible and a known quantity can help.

Also helped that the laptop dual booted either unix or dos and could be used to emulate either end for testing purposes.

YMMV