Detecting Breaks on Atmel AT91 SIO

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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


Re: Detecting Breaks on Atmel AT91 SIO
The 9200 Manual says:

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

Re: Detecting Breaks on Atmel AT91 SIO

Quoted text here. Click to load it

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


Site Timeline