Thanks to Jonathan McDowell for reminding me of 'stty' (it didn't show up on "apropos serial" since it's about "terminal line settings" and doesn't mention "serial"). I now recall that I used to use this a lot ... many years ago when I was networking Linux boxes using serial cable and SLIP! The only slight niggle is that "man stty" is not explicit about setting "Space" parity, though I dare say I can experiment until it works. A bit surprised, though, at some of the other replies. Some peremptory suggestions to read "man setserial". I did. I pointed out in my mail that 'setserial', as I read the manual, does not seem to have provision to set data bits, parity, or stop bits, though it seems possible to fiddle in some obscure way with "baudbase" to set the speed. So could anyone who thinks it's possible to use 'setserial' for data bits, parity and stop bits quote from the relevant bit of the man page? I would certainly be interested! And, a propos of Ian's comment below: On 14-Sep-05 Ian bell wrote:

I think what you want to do does not make sense. It is the responsibility of the application using the serial port to set its parameters. There is no 'global' setting. That's why minicon can config them. What application are you expecting to use once you have run your serialpars util?

Ian

The "application" I'm expecting to use is on the lines of cat /dev/ttyS0 > datafile or (in R, a program for statistical analysis of data) X<-scan(file="/dev/ttyS0",n=100) which would read 100 lines of text from /dev/ttyS0 and assign them to a 100-element vector X of character strings, and so on. In other words, I would have a device, connected to the serial port with a serial cable, which is simply spouting a stream of data as lines of ASCII text using "4800 7S1" as RS232 serial data format. All I want to do is to capture these lines. Once read, I can do anything else I want. It seems to me that this does make sense! In point of fact, one would need to do the same sort of thing to connect the computer to a serial-port printer (RS232, not USB of course). Indeed, once I had run 'minicom' and used it to set the serial port parameters, and then killed minicom, the serial port is configured to correctly interpret the incoming stream of voltage fluctiations. This is a matter of hardware configuration of the serial port UART so that the data lines seen on the computer side of the port represent the bits of the ASCII encoding. It's not a matter of "global settings". Using 'minicom' as described does succeed in doing this hardware setup once and for all. (As someone else reminded me, there's a DOS command on the lines of mode COM1:4800,7,E,1 which is *exactly* the sort of simple utility I was after in Linux) Anyway, thanks for the attention to the query! Best wishes to all, Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 14-Sep-05 Time: 12:22:07 ------------------------------ XFMail ------------------------------

On 14-Sep-05 Ian bell wrote:

(Ted Harding) wrote:

...

[...] It seems to me that this does make sense!

Silly me, of course it makes sense. However, I think some further thought is necessary. The serial input may well be buffered - presumably whether or not it is and by how much depends on start up parameters. Simply reading the last 100 chars from ttys0 may not get the next 100 received at the port but the last 100 in the buffer.

Ian

You're right, of course, about that sort of thing. It depends on how the external device is sending data. In the case of a monitoring instrument, for example, it may send a burst of maybe 100 chars of data once a second. This is not going to cause problems at speeds comfortably above 1000 baud, since this gives plenty of time for the program reading the data to pick it off char by char, thereby clearing the internal UART buffer in time for the next char. If, however, the external device is transmitting more or less continuously at an information rate close to the baud rate, then the opportunities for pile-ups, buffer overflows, and data loss accumulate! In that case one would have to ensure that flow control was carefully set up at both ends. Thanks! Ted. -------------------------------------------------------------------- E-Mail: (Ted Harding) <Ted.Harding@nessie.mcc.ac.uk> Fax-to-email: +44 (0)870 094 0861 Date: 14-Sep-05 Time: 14:07:24 ------------------------------ XFMail ------------------------------