USB Serial Port on Mac using socat
I have a piece of hardware that is connected over a Prolific Serial to USB cable and I need to use socat to send/receive traffic to/from this and a TCP port. So far it's installed and works fine with minicom using:
minicom -D /dev/tty.usbserial -b 9600
Socat works in one direction to a TCP port using:
socat /dev/tty.usbserial,clocal=1,nonblock=1,cread=1,cs8,ixon=1,ixoff=1 TCP4:localhost:8080
How do I get it working two way? I often see repeated characters or double lines which suggests an incorrect serial setup right?
Thanks! Chris
Edit: Some example code (that doesn't actually work in a bidirectional way).
Chris-MacBookAir:~ chrisbridges$ socat -d -d - /dev/tty.usbserial,clocal=1,nonblock=1,cs8,ixon=1,ixoff=1,ispeed=9600,ospeed=9600,icanon=1
2013/01/09 13:13:34 socat[8501] N reading from and writing to stdio
2013/01/09 13:13:34 socat[8501] N opening character device "/dev/tty.usbserial" for reading and writing
2013/01/09 13:13:34 socat[8501] N starting data transfer loop with FDs [0,1] and [3,3]
Answer
I'm most probably telling you a lot of stuff that you know already but debugging such situations usually welcomes a complete picture.
Issue 1: classical serial communication (pure RS-232)
From wikipedia for serial port:
In computing, a serial port is a serial communication physical interface through which information transfers in or out one bit at a time (in contrast to a parallel port) (...) the term "serial port" usually identifies hardware more or less compliant to the RS-232 standard, intended to interface with a modem or with a similar communication device. (...)
From wikipedia for RS-232:
In telecommunications, RS-232 is the traditional name for a series of standards for serial binary single-ended data and control signals connecting between a DTE (Data Terminal Equipment) and a DCE (Data Circuit-terminating Equipment) (...)
So, a DTE is your Mac while DCE is a "piece of hardware". To setup a serial connection you need to set the following parameters:
- baudrate - the maximum data sending speed that can be achieved
- data bits - that many bits will comprise one character
- stop bits - stream synchronization
- parity - error checking
E.g. common values for some POS peripherals are 9600/8/1/none, but the only relevant thing is that both DCE and DTE must have the same values for those parameters in order to beahve as intended. A Mac/PC can use any of the predefined values, so you'll need to check the manual for your "piece of hardware" to see what values to choose.
If one of these two equipments has a bigger baudrate set you'll see rubbish data on the other side. Also, the size of the received rubbish data will be smaller than the original sent data size. If the data bits are not set the same you should also see rubbish data but of the same size. I'm not sure what happens if the stop bits or parity are not the same.
And the most important thing - you need to know the protocol of your piece of hardware - probably in detail - to make it behave as intended. Generally speaking, RS-232 communication means that both DCE and DTE process some data and then send some data over the serial cable (bidirectional communication).
However, while we are nowadays accustomed to multitasking on the DTE side that might not be true on the DCE side - it is possible that your "piece of hardware" cannot listen on its serial port while processing data, and vice-versa. Meaning, if you try to send some data to it while it is busy processing some other data - it won't receive it.
Since RS-232 is older that multitasking - considering when their widespread use occured it is way older - the correct approach would be to use the RS-232 synchronization mechanisms. Let's decompose the bidirectional communication in two directions:
DTE (Mac) => DCE (piece of hw): DTE activates the RTS (request to send) wire, and waits until the DCE activates the CTS (clear to send) wire. Then it sends the data.
DCE (piece of hw) => DTE (Mac): DCE activates the DSR (data set ready) wire, and waits until the DTE activates the DTR (data terminal ready) wire. Then it sends the data.
Judging form your setup (minicom, socat) you're probably using some sort of shell piping/redirection so I don't know how you could read the state of the wires from the shell (though, it must be possible). For a shell/OS architecture layman like me it is a real sweet problem, but unfortunatley I have no DCE to try it:(
Using a program library like Java simple serial connector it becomes as trivial as reading a value of a boolean variable.
Issue 2: adapted serial communication (RS-232 to USB)
I saw two (different vendors) of these, cables with RS-232 and USB connectors and a hardware adapter, usually on the serial connector side. They came with no manual, nor any statment of their behavior but the "serial-to-usb" phrase. One of them didn't work as expected, e.g. it was not transffering the state of the wires correctly, although it is a "serial-to-usb". Not much to do in this situation, but to acqiure the one that works.
Conclusion
Once the bytes reach the TCP port, they will be transffered correctly. Since socat is a very complex program, you might have misconfigured it. The repeated lines and characters point to that more than to serial connection misconfiguration. But since you are stating that the "piece of hardware" to TCP port works, it might also mean that the data coming from the TCP port is misconfigured.
However, first you must ensure that you know the protocol to communicate with your "piece of hardware", so I recommend to try to simulate the data coming from TCP port and to send it directly to the serial port. E.g. write a shell script or a program with some basic commands that communicates with your "piece of hardware" directly over the serial port. If that proves to behave as intended you know that the problem is either in socat or, more likely, the data coming from the TCP port. I hope you have a manual for your "piece of hardware" :)
pls, feedback.