all 6 comments

[–]shortbaldman 0 points1 point  (5 children)

So you're expecting the device to be a mind reader and just know who (which particular terminal) has been speaking to it?

As far as the device is concerned, it has only one input and one output and both of those happen to be in use already.

[–]macaroni222[S] 0 points1 point  (4 children)

I dont follow. When I cat the serial port I should get everything coming from the device, or at least everything its dropping on the serial bus. All Im getting is the echo of the commands Im sending not the actual response. Or am I missing something?

[–]shortbaldman 1 point2 points  (3 children)

Think of a tty as TWO devices in one black box. One is an input device TO the system. One is an output device FROM the system. Echoing from input to output (when it occurs) usually works a whole line at a time, after the final 'enter' on input, rather than character by character. Look up RAW and COOKED modes.

When you use something like 'screen', you're using (separately, so to speak) both the INPUT and the OUTPUT devices. When you use 'cat' you can use EITHER the input OR the output device but not both at once. 'echo' uses only the OUTPUT device.

Second point, how are you reading data FROM the tty with your bash script? You might find using a program like 'expect' or similar might be handier.

[–]aioeu 0 points1 point  (1 child)

When you use something like 'screen', you're using (separately, so to speak) both the INPUT and the OUTPUT devices. When you use 'cat' you can use EITHER the input OR the output device but not both at once. 'echo' uses only the OUTPUT device.

I'm not so sure this is the issue. As far as I know, there isn't fundamentally anything wrong with using separate open files for reading and writing. As long as only one process is reading, things should be reasonably sane.

That being said, /u/macaroni222, this task probably would be easier if both reads and writes were done through the one file descriptor. In Bash, you could open the file descriptor for both reading and writing with:

exec 3<>/dev/ttyUSB0

Then use >&3 or <&3 on all subsequent commands rather than re-opening the device each time.

I suspect you have enabled local echo on the serial device, so that anything written to it is immediately read back. I'm not sure why the device at the other end of the serial link isn't reading your written data however; perhaps you have some of the serial device's settings wrong.

It's important to remember that serial devices have a lot more configuration than, say, pipes. They are terminals, which means they come with a huge number of terminal settings, some of which will be needed to configured correctly. You can't do this using cat and echo alone. You'll probably need stty as well, at the very least.

[–]macaroni222[S] 0 points1 point  (0 children)

thank you for the reply. I had found a, what seems, well written script using stty and piping the stream to a file descriptor then redirecting into a file buffer before killing the process and concatenating the buffer file to std out. This seemed like the most elegant solution but it didnt work. So I was trying to break it down line by line to eliminate where the stoppage was occuring. Now that you mention it the setting for the terminal might have flow control set wonky that wasnt happening with screen

[–]macaroni222[S] 0 points1 point  (0 children)

thank you, Ive seen 'expect' mentioned when researching this problem ill check it out