Detecting Breaks on Atmel AT91 SIO - Embedded

This is a discussion on Detecting Breaks on Atmel AT91 SIO - Embedded ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Detecting Breaks on Atmel AT91 SIO

  1. 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


  2. 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

  3. Re: Detecting Breaks on Atmel AT91 SIO

    Michael Schnell wrote:

    > 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 ?


    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 Thread