SW-EK-TM4C123GXL: UART Rx API

Shai,
One possible reason alone would be because the standard word size on this hardware is 4 bytes. In such case, trying to use a smaller size can actually incur in less efficient code, depending on the compiler settings. Further, this API has also a ROM_ version, to which using a smaller (and maybe non-aligned) output address would be even less recommended. There is no gain trying to optimize a function that is so intrinsically related to hardware registers.
But as a matter of fact, the data returned is larger than one byte - it actually has 12 bits. The data itself is on bits 7-0, so a simple
char dataRecv = UARTCharGet(UART0_BASE) will copy the received byte into dataRecv. But if you look further into bits 11, 10, 9 and 8, there is additional information there regarding overrun, parity, break and frame.
Regards
Bruno

You are quite correct about this having a non 8 bit output and so a larger size is appropriate. Indeed I would argue it should either be int or int16_t typedefed as something like UART_CHAR.

Bruno Saraiva said:

Further, this API has also a ROM_ version, to which using a smaller (and maybe non-aligned) output address would be even less recommended.

In general a concern, but not with any ARM architecture.

Bruno Saraiva said:

There is no gain trying to optimize a function that is so intrinsically related to hardware registers.

Not true, although to be fair optimization of generated code will not improve. There is, however, very significant gain to be had in error detection and prevention and as a surprising side effect design improvements. Optimization of human resources and development. That is probably even more significant.

This comes about because once that return value is typed as different from a 32 bit int there can be type checking applied and misuse becomes quickly apparent. TI lost very significant quality improvement opportunities when they used int32_t and pointers to int32_t for almost every type.

Robert