Can two devices with different Serial communication Settings work?

[Alpha Mr]

Posted on May 31, 2018 at 14:02

I am working on STM32F030Xc MCU. Which I set UART settings as: 7- bit, None parity, 2 stop bits, And its connected with PC terminal with settings 7-bit, Even parity, One stop bit. So both MCU and PC should not communicate isn't it? But they are! And not only communicating but data is also correct sent and received!  How? Please guide me.

#learning-stm32 #stm32f-uart

[Tesla DeLorean]

Posted on May 31, 2018 at 14:38

>>Please guide me

To do what?

The data is sent least significant bit first, the parity and stop bits trailing. The form remains pretty consistent despite the settings.

On the ST side the width includes parity, so 7E would bit 8-bit mode, 7N 7-bit mode, and 8O 9-bit mode, for example.

On the PC the receiver will show you data with parity that is valid, and hide the data that is not. You might want to try some different terminal software to see if that behaves differently, or send character values in the 32 to 126 range and confirm you can see at both ends. Things like RealTerm can also display data bytes in hex form.

[Alpha Mr]

Posted on June 01, 2018 at 06:01

So how do I prevent this communication on ST side? How do I make sure that ST should reply only to the data that is according to UART settings set in ST and not to reply if its not?    

[Tesla DeLorean]

Posted on June 01, 2018 at 07:08

Run the ST side in 8-bit mode and check the parity, or in 9-bit mode and check for both parity and the stop bit? If you run in 7-bit mode you'll likely have any usable info in the high order bits masked, and perhaps get a framing error if the UART dislikes the pattern is sees. If you want to see the additional data on the wire use 9-bit mode.

What constitutes valid data, and how would you reply to it, or indicate is it invalid?

Perhaps you can provide data to support your observations? And the data/response you want/expect?

[T J]

Posted on June 01, 2018 at 02:25

I guess your PC software is ignoring the parity error.

of course it works, if you ignore parity, only 7 bits at a time, perfect for ascii, but slower than using HEX