Uart: problems after added check of err_wr_mask in config

[maxwen]

I have written an esp32 mbus scanner for reading the smartmeter of my energy provider. It uses an mbus scanner attached to uart (from MikroElektronika).

That worked fine before the following was added to uart.rs

... // Setting err_wr_mask stops uart from storing data when data is wrong according // to reference manual T::register_block() .conf0() .modify(|_, w| w.err_wr_mask().set_bit()); ...

And the subsequent check for events in read_async ... let mut events = .... | RxEvent::RxFrameError | RxEvent::RxGlitchDetected | RxEvent::RxParityError; ...

I can bring it back working as before when disabling setting err_wr_mask and disabling that those three events return an Err.

The read loop is based on rx_timeout to sync the packets which are sent periodically from the smartmeter. Its a very slow connection (2400 baud)

Now I am unsure why this creates those "errors". Is this just "normal" for those kind of connections? If yes - would it make sense to add some kind of config to disable those "forced" checks "on demand"?

So I guess it comes down to what exactly means "data is wrong according to reference manual"

[dignifiedquire]

having the same issue, would be great if this could be a config option

[MabezDev]

We'll get to this eventually, but a PR would be most welcome :).

[clabbenius]

Do you have an example code snippet where you use read_async uart? And what are you experiencing?

[dignifiedquire]

I don’t have a link right now, but what I am doing is implementing LIN over uart and need to read the initial break signal, which does not translate cleanly to a uart signal.

[zpg6]

I don’t have a link right now, but what I am doing is implementing LIN over uart and need to read the initial break signal, which does not translate cleanly to a uart signal.

+1, came here for the same reason

[bugadani]

I suspect the two parts of this issue are independent:

• err_wr_mask makes the peripheral essentially forget data that has partiy/framing/other errors, but otherise I think it should continue receiving data. I'm not exactly sure disabling this is useful, you'd have no information about the correctness of what you receive - but it's a hardware feature and we should expose it.
• The async API is indeed stopping at faults, and a somewhat arbitrary list of those (cc https://github.com/esp-rs/esp-hal/issues/2643). We'll have to provide some API where users can wait for bytes, while controlling which error conditions they are interested in.

[zpg6]

I suspect the two parts of this issue are independent:

• err_wr_mask makes the peripheral essentially forget data that has partiy/framing/other errors, but otherise I think it should continue receiving data. I'm not exactly sure disabling this is useful, you'd have no information about the correctness of what you receive - but it's a hardware feature and we should expose it.

• The async API is indeed stopping at faults, and a somewhat arbitrary list of those (cc https://github.com/esp-rs/esp-hal/issues/2643). We'll have to provide some API where users can wait for bytes, while controlling which error conditions they are interested in.

Ok, agreed. I'm most interested in a reasonable method to get my async reads to work. Best if such an error could be ignored on just one byte (like a break), and other bytes that follow can be read successfully.