Serial port baudrate hard limit. Is it possible?

[jlourenco]

Hi,

I need to limit the baudrate of a serial port (eg /dev/ttyS0) to 9600 bauds, disallowing the possibility for programs to augment this baudrate when using the serial port.

Is this possible?

Uart: 16550A
Fedora 13, 32 bits, with a 2.6.3.23 kernel.

Thanks for any help.
Jose

[PabloTwo]

Hello, and welcome to the forum.

I don't know of anyway of "locking" the baud rate of a serial port. You can use the setserial command to set the baud rate on a serial port, or you can let the program that is accessing the serial port set the baud rate. I think in general, serial ports will just conform to whatever' standard' baud rate is sent to it.

[jlourenco]

Thanks PabloTwo.

Unfortunatly (for me) you must be right.

setserial won't do because it just sets a default baudrate that can be changed.

I was wandering if someone had more knowledge and experience in this matter.

I don't really want to do this, but the only other option comming to my mind - and I am only guessing - would be to act at driver level, disallowing the change of baudrate of serial port and setting it to the desired value. If this is possible...

Thanks again for your attention and welcoming.

[jpollard]

I don't understand why you would need to impose such limits. IF the baud rate is too high (or low) for the connected device, then it just won't work.

Getting the baud right right would be up to the application using the serial line. If you are concerned about interrupts... don't be. Most of the serial interfaces have a buffer queue and send all characters received in one interrupt.

[jlourenco]

The case is I have a device (with a microcontroller) serially connected do the computer that is communicating at 9600 baudrate which I can't modify.

In the pc side I must use a closed library that has a function to open the serial port. The only thing I know for sure is that it works by passing the device name of the serial port to it (eg /dev/ttyS0). It may allow other arguments, such as the baudrate, parity, stop bits, ..., but don't know the format used. Ah, the device is no longer supported so there are things I must guess.

I used objdump to disassembler it and am trying to get additional information on passing arguments. My assembly knowledge is very rusty, though.

So, trying to limit the pc serial connection to the needed 9600 baudrate, despite being an ugly option, would allow me to continue working.


Thanks for your interest.

[jpollard]

Then the application should either set the baud rate itself from a configuration, or accept whatever the existing baud rate is, and for that setserial should work.

If, however, the application always sets the wrong baud rate, then the application may have other uses for the speed - such as internal timers (computing a timeout based on its idea of the interface speed) and externally limiting the baud rate becomes a bad idea - the timing will be wrong.

In most such cases setserial should just work.

[RupertPupkin]

I don't know if it will be any different than using setserial, but you could try the stty command (as root):

stty -F /dev/ttyS0 9600

You can then check the settings like this:

stty -F /dev/ttyS0 -a

[PabloTwo]

I don't know if this is applicable/transferable... but, I don't have any real serial ports but I do have and use a single port USB>Serial converter that creates /dev/ttyUSB0. I use that with a ham radio TNC modem for ax25 packet radio. When all setup, /dev/ttyUSB0 gets kissattached to an ax25 network socket and which puts a LOCK file on that port. /var/lock/LCK..ttyUSB0.

Communications over /dev/ttyUSB0 is at 19200 baud (the TNC is hardwired to that speed on it's serial port) and the network socket is configured in software to match that speed. Before the ax25 network socket and lock file exist, I can view/change any of the port parameters, including speed, on /dev/ttyUSB0 using the stty command. Once the lock file for it is in effect, I can't even view the settings, much less change them.

Exactly what all is involved in creating a lock file on a port other than the lock file itself being in existence, I have no clue. But if it would be that simple...

- use setserial to set the baud rate on your /dev/ttyS0 port
- create a lock file for /dev/ttyS0

The above is probably wild thinking and destined not to work, but it's a sliver of a possibility.
I have to agree with jpollard though, and I really can't see any reason for setting the baud rate on a serial port into concrete.

[Chilly Willy]

Now assuming that the ports still works the same as they once did...

From the old DOS days, we used the serial port quite a bit for external devices, especially HAM RADIO. (still do to some degree) The norm was, IIRC,

9600, 8,1, e
(& this ALL has to match - between the device & port - or it won't work)

Which meant, 9600 baud, eight bit, one stop bit & even parity. There is no "lock" as you are thinking BUT once the "handshaking" is done, the rate will stay in sync. & yes as some have mentioned, some devices can set all this itself (the old dial-up modems do), & some can vary the rate if needed. But since you say the device NEEDS 9600, then it is the DEVICE that is "locked" at that speed (most likely by hardware design) & all that is needed is to set the port to match.

BTW: it is the bit, stop bit, & parity that is the most crucial, & will stop the communication. (or at least was)

Also, those USB to serial devices work the same way - they set up a virtual port that as far as the computer is concern, looks real.

[jlourenco]

Yes, I expected setserial to work.

Unless I am doing it wrongly, setserial does configure initially the serial port at 9600. However, I know that the baudrate is changed to 115200 inside the library because I am monitoring the serial line and logging the communication. Before is at 9600, during and after execution is 115200. By the way, it's RS-485 and I am using RS-232 to RS-485 converters, so it should be the same as RS-232, no drivers needed.

I am trying to change an older controller (to a pc) and it does communicate at 9600. So using 9600 is the desired and correct rate. I don't feel speed should be a problem. It must be the setting on the program that isn't properly done.

Regarding set serial, I am using the following configuration on rc.serial:

###AUTOSAVE-ONCE###
setserial /dev/ttyS0 port 0x3f8 irq 4 baud_base 115200 divisor 12 spd_cust skip_test
setserial /dev/ttyS1 port 0x2f8 irq 3 autoconfig ^skip_test

echo
echo "/dev/ttySx settings:"
echo
setserial -a /dev/ttyS0
setserial -a /dev/ttyS1


I am not very experienced on Linux programming and configuration. From my research and testing this one seems to be working.

Thanks again for your interest and help.

[PabloTwo]

Regarding set serial, I am using the following configuration on rc.serial:

###AUTOSAVE-ONCE###
setserial /dev/ttyS0 port 0x3f8 irq 4 baud_base 115200 divisor 12 spd_cust skip_test
setserial /dev/ttyS1 port 0x2f8 irq 3 autoconfig ^skip_test

echo
echo "/dev/ttySx settings:"
echo
setserial -a /dev/ttyS0
setserial -a /dev/ttyS1

Why not reset "baud_base 115200" to "baud_base 9600" in your rc.serial file?

[jlourenco]

Well, again, if I did it correctly, using baud_base 9600 didn't work. I find this odd.

I will do a new installation on a different computer and I will test this again.

So, I used baud_rate 115200 with a divisor of 12 giving 9600.

[PabloTwo]

Maybe try,

setserial /dev/ttyS0 port 0x3f8 irq 4 baud_base 9600 spd_normal divisor 0 skip_test

[Chilly Willy]

It sounds like (to me anyway) that you are getting confused as to how the port works & it sounds to me like it is working as it should. On SOME devices, the initial baud rate is a starting point to get the communications going, once it is established & the devices determine that they can "talk" at a higher rate, they will kick up the rate. As you are having here. As long as the signal is clean & errors are minimum or non-existent, this rate will be maintained, otherwise it will fall back. (& as long as the devices ARE talking, what is the big deal if the rate DOES go up? This is a desired thing)

Now, bare in mind that not all devices can do this & some are "locked" at one rate. The ones that can be varied usually have the capability of being TOLD at what rate to work at. - note: IIRC, some devices, when the higher rate has been established, (especially if manually reset to higher rate) may require this at later dates - so if you can't get it to go, try the higher rate.

My advice to you is to look up how to set up an "old" HAYES modem, this should help.

[PabloTwo]

See edit to my last post: added "divisor 0" to the parameters.