Properly report break conditions

[jannic]

A break condition is also a framing error. As it is the more specific code, return the break error.

[jannic]

I wonder what error should be returned if both FE and PE are set. Is one of them more specific and should be preferred?

[jannic]

embassy-rp uses this order of precedence, which looks sensible:

            if dr.oe() {
                Err(nb::Error::Other(Error::Overrun))
            } else if dr.be() {
                Err(nb::Error::Other(Error::Break))
            } else if dr.pe() {
                Err(nb::Error::Other(Error::Parity))
            } else if dr.fe() {
                Err(nb::Error::Other(Error::Framing))
            } else {
                Ok(dr.data())
            }

[9names]

I wonder what error should be returned if both FE and PE are set. Is one of them more specific and should be preferred?

FWIW I would have frame error as a higher priority.
Sure, your data is corrupt either way but a parity error only tells you that an odd number of bits are wrong, a framing error tells you why the sum of bits is wrong.

[jannic]

I don't agree that the framing error tells you why the parity was wrong. Both flags can be set because of a single bit-error. (If one, or an odd number of, data/parity bits are wrong, you get a parity error. If the stop bit is wrong, you get a framing error.)
But I agree that the framing error should probably have priority: It's more specific. You exactly know which bit was wrong. So it tells you slightly more than the parity error.
Now the difference between the two choices is so small that consistency with other implementations seems to be more important to me. I'll check what the C SDK does.