Fix USART length setting for odd/even parity setups.

[cajt]

The prior code set the length to incorrectly if odd or even parity was used.
The fix works fine on the stm32f042. There is also an example that uses an USART with parity, I also checked the output on a scope.

The #ifdef is copied from "setWordLength", but i couldn't test it with a STM32 that doesn't have USART_CR1_M1.

[salkinium]

Even worse, setWordLength() (always available) was confused with setLastBitClockPulse (USART only for SPI mode).

[salkinium]

This isn't a good API, since technically you can have parity on 7-bit data (like ASCII) and then you get a 8-bit word. I would prefer to remove this line here. What do you think?

Update: and add the word length to the constructor?

[chris-durand]

Update: and add the word length to the constructor?

@salkinium Do you mean the initialize() method? The Hal class only has static members and no user-defined constructor. Then I would agree. setParity() is not even public, so we are free to change its behaviour.

I would also add documentation on setWordLength() to clarify whether the word length there includes the parity bit or not. If we add the parameter to the initialization function we should be consistent with that.

[salkinium]

Sorry to hijack this PR, however, the UART driver was triggering my OCD and I had to clean it up. I also made each buffer individually configurable, so that you don't need to generate the Receiver buffer if you only every transmit something (like 90% of the logger use cases).

I can test 9-bit transfers with parity for my AMNB network between a bunch of G071 and a F411.

[salkinium]

I'm closing this is favor of #564.

Thanks for reminding me to refactor this terrible code!

[thestumbler]

What was the final decision on the data length definition? My application requires even parity, and what would normally be called 8 data bits, which means as noted above, there are a total of 9 bits between the start and stop bits. It seems I have to put data bits of 9 to make it work, but that seems contrary to what I believe is the industry standard definition.

[salkinium]

Data length includes the parity bit because we followed the ST mechanism. Example usage

[thestumbler]

I was surprised by this, but looking at a few F1 and F4 family chips, I see how one can interpret it this way. They've blurred the distinction between data bit size as specified in the M-bit with parity enable PCE-bit. But if you look at the table 146 (I'm looking at the F405 manual, RM0090) they do note the true bit size in the text remarks.

In my experience, this is very unusual. I've never seen the parity bit included in the M-bit(s) data size field of line control registers before. I spot-checked a few other MCU data sheets, like RP2040, SAM-E53, ATmega328, and their underlying way of handling parity is in-line with my understanding of industry standards ... that is, the existence or not of a parity bit has no effect on the data character word size. Looking at data sheets of individual chips, this convention seems to go all the way back to the first UART chip, the 1971 Western Digital 1402A. Later, the 1981 National Semiconductor 8250 and successors like the 16450, etc., continued this convention.

Furthermore, the kind of information someone gets to describe the characteristics of an asynchronous serial link is usually expressed like 115200 8N1. I'd guess this convention is even less formally documented than the description of the M-bits field (maybe it comes from modems?). But in my experience, parity of N means there simply will not be a parity bit in the frame, and doesn't change the character size. Likewise, all the others, odd, even, mark, and space, while adding one extra bit to the frame, don't change the character size.

Regardless of how a particular UART implements this mechanism, I would suggest that presenting the traditional representation to the user in the API calls is a preferable approach. I realize, however, at this point, it could be a breaking change for MODM users, and I have no opinion on how to deal with that problem.

[salkinium]

I realize, however, at this point, it could be a breaking change for MODM users, and I have no opinion on how to deal with that problem.

Oh, that's easy: We have a detailed changelog for that purpose, were we simply make breaking changes every ones elses problem, bwarharharhar! (we try to be sensible though).

I'm happy to merge a change of it, I don't like the current way either.