Problem detecting and reacting to serial break

[Paul Thornton]

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.

Paul.