Fixed documentation for 8 bit parameters in stm32/f0 usart routines. #651
Conversation
|
I'd actually rather see these simply dropped. The type information is already available from the functon signature, adding it in the comments in this cases provides no additional value, and only serves to be out of date. Further, commits headlines should be something like, "module: summary" so a good rewording of this commit would be "stm32f0: usart: drop incorrect/confusing documentation" |
|
Ah, good point, I just stumbled across the conflicting doc for the usart and thought I make a quick fix. Thanks for the feedback and the commit msg style heads up! |
|
Problem : the F0 USART can use 9 bits of the USARTx_RDR and _TDR registers ( the extra bit being parity), I assume this is why the other API functions use uint16_t arguments... there are two conflicting declarations of the usart_send(), usart_recv, (+ blocking variants) functions, one in "usart_common_all.h" having uint16_t, , and one for v2 usarts with uint8_t ... |
|
This caught my eye yesterday as well. |
|
Going to fix both issues. Dropping all the redundant type info from doxygen, and also fixing all the definitions for the f0 usarts. |
Make them 16bit regs, like on other periphs. This allows proper access to the "8th" bit. (0..8 is 9 bits, not 8) Found and reported in libopencm3#651
Make them 16bit regs, like on other periphs. This allows proper access to the "8th" bit. (0..8 is 9 bits, not 8) Found and reported in libopencm3#651
Make them 16bit regs, like on other periphs. This allows proper access to the "8th" bit. (0..8 is 9 bits, not 8) Found and reported in libopencm3#651
Make them 16bit regs, like on other periphs. This allows proper access to the "8th" bit. (0..8 is 9 bits, not 8) Found and reported in #651
Make them 16bit regs, like on other periphs. This allows proper access to the "8th" bit. (0..8 is 9 bits, not 8) Found and reported in libopencm3#651
No description provided.