#146 Unable to switch from odd to even parity

[Francesco Cusolito]

If the serial port is already setted to communicate with odd parity, stm32flash is not able to properly commutate to even parity.
Attached patch fixes the issue.

[Tormod Volden]

Hi, thanks for your patch. Just wondering, doesn't cfmakeraw() reset these bits? According to the man page it resets PARENB explicitly at least. What platform are you on?

I appreciate that you made a git-formatted patch that I can apply directly, but it has a few issues:
- your full name is wrong
- looks like whitespace errors in the introduced lines
- comments should use /* */

[Tormod Volden]

It looks like this could also solve coming from two stop bits also, independent of parity settings. This could be mentioned too.

[Tormod Volden]

Another question, did this manifest with "Failed to set terminal flags" or silently failing?

[Francesco Cusolito]

Sorry for the long delay, I moved to a new company and I don't use the tool anymore.
Anyway, I upload a new version of the patch, with better headings, based on 5ac0ffb0a33d88cd4dbb2ac1971720dcce7f2be1 commit.

I'll try to answer all the questions, but unfortunately I can not perform the needed tests anymore.

Hi, thanks for your patch. Just wondering, doesn't cfmakeraw() reset these bits? According to the man page it resets PARENB explicitly at least.

PARENB was correctly resetted, but PARODD was not.

What platform are you on?

I tested it on a Raspberry Pi 3A with a custom Yocto aarch64 build (target platform), and on my developing machine with Ubuntu 20.04 x86_64.

It looks like this could also solve coming from two stop bits also, independent of parity settings.

I thinks so, but that was not a problem I was having. I just followed a solution posted somewhere on StackOverflow about how to reset serial port on POSIX systems.

Another question, did this manifest with "Failed to set terminal flags" or silently failing?

The fail was silent, with a message like "Unable to initialize device" (or something like that).
I think this was reasonable, because actually there was no error in setting terminal flags, and all the system calls terminated correctly. It was just that the PARODD bit wasn't resetted, so the first read wouldn't receive anything.
I diagnosed the behavior with the help of strace, checking the arguments of the system calls
performed to setup the port.

Actually, the tool was still able to restore the previous port settings on exit.

[Tormod Volden]

Thanks for the new patch and the information! Pushed in commit 5f45624.