search

cbrake / linux-serial-test

Linux Serial Test Application
302 stars 154 forks source link

Running with --rs485 may lead to invalid RTS setting #48

Closed s-hemer closed 1 year ago

s-hemer commented 1 year ago

I stumbled upon some strange behavior when running linux-serial-test with --rs485 option (accidently forgot -Q) on a port that is already set to SER_RS485_ENABLED already (either by DT linux,rs485-enabled-at-boot-time; or i.e. https://github.com/mniestroj/rs485conf

Of course, in this case one potentially should not run linux-serial-test with --rs485 option at all as delays are also settable via DT or rs485conf but maybe linux-serial-test should respect the RTS_ON_SEND/RTS_ON_AFTER_SEND settings and either ignore the --rs485 setting or just adopt the given delays.

In both cases, running it results in a driver message like this: [ 1102.334825] omap8250 48022000.serial: ttyS1 (1): invalid RTS setting, using RTS_ON_SEND instead

And the port settings are reset to RTS_ON_SEND=1, RTS_ON_AFTER_SEND=0 (from the opposite).

Some background: AM335x seems to have the RTS pin high and drive it low on the (DT) serial8250 default settings rs485-rts-active-high, so one needs to use the un-intuitive rs485-rts-active-low setup.

s-hemer commented 1 year ago

Ok, just double checked: running without--rs485 is not an option as it disables rs485 (https://github.com/cbrake/linux-serial-test/blob/2ee61484167eab846f7b7c565284d7c350d738d3/linux-serial-test.c#L678) which also results in the driver message mentioned above.

s-hemer commented 1 year ago

Another finding during investigation: running linux-serial-test -p /dev/ttyS1 --rs485 0.0 -Q -A and stopping with Ctrl+C ends up in RTS pin staying high (whereas it should go low as when calling it with a defined send time like -o 2). Maybe it is worth a separate issue, comments welcome.

s-hemer commented 1 year ago

@cbrake I would appreciate some feedback on this topic before digging deeper. If my explanations are too weird, it would also be great to know where I lost you or where to get more specific.

cbrake commented 1 year ago

@s-hemer thanks for the report -- if I understand correctly, are you suggesting linux-serial-test should preserve the RS485 settings if they are set by another program?

s-hemer commented 1 year ago

@s-hemer thanks for the report -- if I understand correctly, are you suggesting linux-serial-test should preserve the RS485 settings if they are set by another program?

That is correct, programs or the Devicetree config. And the other aspect, that may be a separate issue, is that the proper reset of the RTS state when running endless and stopping with with Ctrl+C seems not to work. In other words: it seems to me that linux-serial-test.c:937 is never reached.

For the first one, I already could provide a patch, for the latter, I'd be happy about some input.

cbrake commented 1 year ago

patches are welcome -- I don't have the setup for RS485 convenient right now to do any testing.

On the 2nd, I wonder if it makes sense to add some verbose logging in the app, and have a command line flag to turn that on? Then we could get a trace of what all happened.

s-hemer commented 1 year ago

With the two patches merged, this issue can be considered as solved.