Serial port read/write with bash

[clickit]

I searched the Internet for any code snippet that could capture data from the serial port.
All tests were preceded by stty -F /dev/ttyS0 raw ispeed 9600 ospeed 9600 -ignpar cs8 -cstopb -echo
and were either
echo ATDT4256669999 > /dev/ttyS1
read LINE < /dev/ttyS1
OR
(stty -F /dev/ttyS0 raw ispeed 9600 ospeed 9600 -ignpar cs8 -cstopb -echo
[shell read/write commands]
) </dev/ttyS0 >/dev/ttyS0
I tried using dd also.
In all cases the process hung after writing to the port or trying to read. I also tried in interactive mode.
If everyone else is so successful with these can someone enlighten me why these do not work for me.
Be aware there was no other activity on the port when I tried these. The ports are OK as they are used for other purposes at different times.

[sixdrift]

Assuming you have rw access to the port (this is not always the default case), you need something on the other end of the port to complete the read/write. When you issue the read request on the port, if there is nothing there, the read will hang until something is there, or you ctrl-c the command/script. I think this may be true for the write, depending on the settings of the serial port.

So did you have a device connected to the port at the time and could you verify that the settings were correct?

Try minicom to get an interactive terminal on the serial port and test it out.

[clickit]

Thanx. Exactly the info needed. Settings checked with stty OK and no current device connected. Trying to set up a read write via serial port to a pair of cd4053 muxes to drive scientific instruments. I need capability to send control codes to the muxes and will be writing script to read the ADC connected to the output of the muxes. If you have more info regarding the best way to read write in this configuration it will be helpful. I already have c code to read the ADC so will be converting.

[Rubberman]

First, the examples you are working from are pretty much for communicating with a modem attached. You need to know several things that the muxes are expecting:

1. Baud rate - 9600 is pretty slow for a directly connected device.
2. Number of start/stop/parity bits.
3. Flow control - xon/xoff, dte/dce, etc.

You use the stty command to set the port parameters appropriately. If you have the mux documentation about this stuff, we can help you a bit more. RIght now, you don't provide enough information.

[theNbomr]

There could be a worse programming language than bash for doing serial communications, but I'd hate to see it. For the greatest, easiest, control, C would be far better. Especially if your T&M gear requires non-ASCII data to be sent.
I would suggest you start with either minicom (include with most Linux distros), or C-Kermit (easily installable from sources), which was born to talk serial IO, and which is highly configurable and also scriptable. These interactive tools will allow you to get a feel for what settings and behavior works with your computer and your instrument.
Once you have the basic communications (data comm's parameters, connectors and cables, etc.) worked out, then start writing code, using known good parameters and infrastructure.
Recommended reading:

Serial-Programming-HOWTO.html
Serial Programming Guide for POSIX Operating Systems
Serial HOWTO

(sorry, can't post links yet; low post count. Maybe someone more privileged can do so)

--- rod.

[clickit]

As far as I know at the moment a CD4053 mux chip gets 3 bits to change the configuration as to which input port will be connected with which output. Each input has 2 ports for options and one port for output but there are 3 of those.
The 3 bit control selects which ports to use.
Hence, I was just trying to figure if I could connect to the chip via ttyS0/1 with bash. Yes, I know bash is not really efficient but want to see if it is at all viable for this purpose. My original tests did not have anything connected to the serial port. I was hoping that I would be able to read my output with my input code. That configuration is apparently not viable.
I've checked out beyondlogic.org's serial/serial.htm and found the registers. I presume these are the registers I need to use with control bits to communicate with the chip. Can someone correct or verify this for me.
I am familiar with using C to read the ports but this is not the way I want to do it here. I do not need the 100 samples per second rate that I have on my seismometer reading code nor the accuracy I have on my gravity meter. The output of the (pair) of CD4053's will be sent to an AD which I already have C code to read. This configuration I've planned should allow 6 devices meuon detector, fluxgate and torsion magnetometers, etc. to attach to a single port. If every thing else is viable. Thanks for your help guys!

[theNbomr]

The reference you cited is a very good one, but includes very little that is useful from a Linux userspace application.
I get the sense that you are confusing bits in the PC UART with bits in your Mux device. Normally, instruments that have serial interfaces define some communications 'language' that is used to control the device serially. In such a case, there would be a sequence of bytes that your application would send on the serial interface to set the bits in the instrument. It seems improbable that you will have any success unless the 'language' that the device uses is documented.
The information in your reference would be of great use to a Linux device driver writer for serial ports, and it is almost certain that any existing standard serial port will embody the knowledge that is expressed in the web site to which you refer. You should be able to glean knowledge of how to construct or specify a suitable cable for your circumstance (again, device documentation for your mux would be very helpful).
--- rod.

[clickit]

U R correct re confusion. I was trying to figure out which serial output pin responded to which serial register so that I could then wire a cable to control pins 9, 10, 11 on the CD4053 so I could control it. Thinking the registers would/will lead me to that info unless U have same. The info on the chip is embodied in the datasheet and that is available from several outlets on the web. Try "CD4053 datasheet" as you probably already know.

[theNbomr]

You cannot use a serial interface to control a mux chip in the way you intend. RS-232 signaling levels (+/- 12 V nominally) are completely inappropriate for the purpose, and even if you were able to resolve the voltage compatibility issues, bash would be as inadequate to the task as I could imagine.

My analysis of your problem is like this: you need to deliver a small number of nominally TTL level signals to discrete input pins of a chip. The pins need to be individually controllable. The standard PC parallel port is capable of performing just such a purpose, and has been perverted to do so by many others in the past (myself included, and ironically, to control a mux in one instance). The parallel port has at least one output register which can be written to control the state of 8 output bits. The pins are driven by line drivers for each bit, and the bits are connected directly to the connector pins.

The bad news is that parallel ports have become all but obsolete, and especially in a form that is easily addressable. A USB-Parallel dongle is NOT the same, and will probably not serve your purpose without controlling the device through driver modification. If you can locate a motherboard which has a built-in parallel port (most older ones do, and older gear makes sense when hardware hacking), you should be able to drive the pins fairly easily from a userspace application, using either the ioperm() + outb() family of services, or through the /dev/port interface.

Hope this helps.

--- rod.

[clickit]

It may be possible to control voltage via a zener but I vaguely recall the mux chip will handle that voltage. I will check later.
The real bad news is that I plan to use the mux (CD4053) to control 3 seismometers feeding a single AD to sample seismic data at up to 100 s/s rather than mounting additional parallel ports as I did on one box.
Thanks 4 UR help