Detecting Breaks on Atmel AT91 SIO

Hello,

I'd like to detect BREAK conditions on the built-in SIO of an Atmel AT91RM9200 ARM processor. No matter which way I set all those stty flags (PARMRK, BRKINT, IGNBRK, IGNPAR etc.), I don't manage to read breaks as anything except 0x00 bytes, which is obviously no good. Only when I set parity enabled and odd parity I see the expected 0xff 0x00

0x00 sequence, but that's because a break is also a parity error in odd parity, and it's no good since I don't want to use parity.

Has anybody managed to actually see breaks on the SIO with this chip?

Any help appreciated,

--
Linards Ticmanis
Reply to
Linards Ticmanis
Loading thread data ...
24.6.3.11 Receive Break The receiver detects a break condition when all data, parity and stop bits are low. This corresponds to detecting a framing error with data at 0x00, but FRAME remains low. When the low stop bit is detected, the receiver asserts the RXBRK bit in US_CSR. This bit may be cleared by writing the Control Register (US_CR) with the bit RSTSTA at 1. An end of receive break is detected by a high level for at least 2/16 of a bit period in asynchronous operating mode or one sample at high level in synchronous operating mode. The end of break detection also asserts the RXBRK bit.

If the driver is able to handle break receiving in any way it needs to look at the RXBRK bit in US_CSR. Does it do so ?

-Michael

Reply to
Michael Schnell

A colleague of mine has isolated the problem: There's simply nothing in the at91_serial driver that puts that special byte sequence 0xff 0x00

0x00 into the receiving buffer when it sees a break, PARMRK or not. This seems to be the case for the majority of non-PC serial drivers in the current kernel.

He's now working on an implementation.

--
Linards Ticmanis
Reply to
Linards Ticmanis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.