Paul Thornton wrote: > Ed Schouten wrote: >> * Paul Thornton <[email protected]> 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. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
