UART driver character size

[awygle]

Hi all,

I'm sure this question has a simple answer but I can't find it anywhere.

Why do the UART driver interfaces use a 16-bit character?

Specifically, I'm looking at the type for the character received callback and the comments on all of the Start functions.

I've seen 8-bit UARTs and 7-bit UARTs, but I've never seen a 16-bit UART. As far as I can tell, even the STM32s (which I have never used) don't have a 16-bit UART data register. Can you explain?

Thanks!

[steved]

The USART supports 9-bit data; I've come across it in the context of the 9th bit as a command/data selector bit. And (at least for 7-bit data) the UART gives you the parity bit as well, if parity is enabled - so I imagine its consistent across all word sizes.

So you can't have 16-bit data; but you can have 9-bit (and possibly 10-bit).

[awygle]

That's weird - you have to do your own parity checking? I am familiar with "address-bit multiprocessor" formats using 9 bits, and if you want to add start parity and stop bits I could stretch it to 12 bits, but I'd expect the hardware to handle everything but the main data payload.

If this is caused by some quirk of the STM32 hardware, I'd like to suggest a typedef for data size so that other ports can deal with whatever the most comfortable size for them is.

[Giovanni]

Hi,

The typedef is not going to work under all situations, you may want to work with 9 bits with USART1 and 8 bits with USART2.

Giovanni

[awygle]

I see what you mean, but I'm talking about across architectures (STM32 vs AVR vs, in my case, MSP430). While USART1 may be 9 bit and USART2 may be 8 bit, USART2 isn't going to actually turn out to be an eUSCI_A.

So the STM32 LLD would just have

Code: Select all

typedef uint16_t uartchar_t

and the typedef for the RX character callback would be changed to use the new type. We can leave the main interfaces to be void*s to the buffers and no other code needs to change. Then in the MSP or AVR code we just change the typedef to uint8_t.

[steved]

That's weird - you have to do your own parity checking? I am familiar with "address-bit multiprocessor" formats using 9 bits, and if you want to add start parity and stop bits I could stretch it to 12 bits, but I'd expect the hardware to handle everything but the main data payload

No; if enabled the USART does parity checking.
However, at least with 7 bit + parity data, it gives you the parity bit in bit 7 (which is somewhat irritating!)