Problem detecting and reacting to serial break
prt at prt.org
Sun Aug 15 13:55:10 UTC 2010
Paul Thornton wrote:
> Ed Schouten wrote:
>> * Paul Thornton <prt at prt.org> wrote:
>>> I'm using 8.0-RELEASE with uftdi and ucom driving the serial port.
>> Somewhat unrelated question: have you ever tried running the this code
>> on 7.x? If so, did it work?
> I've just tried this on 7.2-RELEASE (that was the only 7.x CD I could
> find lurking about my desk).
I've been looking into this a bit deeper, both with 7.2 and on a Linux
box I had to hand.
I'm using a baud rate of 250000 - which of course is non-standard;
although the FTDI chip is more than capable of doing it.
The tcsetattr does not like setting the baud rate to this - which works
without complaint under 8 (I'm guessing this is one of the enhancements).
This lack of tcsetattr success is, I suspect, causing my block on the
read() call. When I set the rate to 9600, the tcsetattr succeeds, and I
do get data coming back from the read - albeit baud barf.
I made a quick hack to uftdireg.h and uftdi.c to add a rate of 250000
with a divisor of 12 - which results in my tcsetattr now succeeding, and
the data read looking more correct. However I'm now back to the same
problem as under 8.0 - the break has no effect and the position of data
byte 1 wanders around the buffer.
With Linux, it all works as expected - but the linux tcsetattr doesn't
like the nonstandard baud rate either. However, in linux I used
setserial to set a base baud rate of 24000000 and a divisor of 96 to get
250k baud rate. When I run, I have a stable buffer dump displayed which
always starts with byte 1; so I'm happy that in theory my code is
correct and the hardware is behaving as expected.
So it seems that the answer is that I get the same behaviour with 7.2 as
I did with 8.0.
More information about the freebsd-hackers