The serial format method takes three arguments: number of bits, parity options and number of stop bits
The interpretation of the first argument is some what ambiguous if a parity option other than no parity is selected
Is the value the number of data bits or the character bit length, which is one greater than the number of data bits when the parity option is not none.
Prior to patch #4189 the implementation of the Serial format method for the STM32 boards assume the first argument value was the character length.
The more common interpretation is the value is the number of data bits. As a result a number of developer filed bug reports when having though they where setting up a link with 8 data bits and parity by specifying 8, and parity other than none. They found the msb of their data was being over written by the parity values.
Patch #4189 reversed the interpretation of the first argument so after the patch specifying 8 and parity results in the transmission of a nine bit character.
After the patch one can not long specify an 8 bit character length consisting of 7 data bits and a parity bit, which is a format used by many of the older serial line protocol including the SDI-12 data logger interface standard.
The UARTS in the STM32XXXX microcontroller support either 8 or 9 bit character lengths with the length selection via a bit in one of the UARTS control registers.
The microcontrollers should therefore be able to support 4 character formats
data bits, parity , character length (bits)
- 1 9 No 9
- 2 8 Yes 9
- 3 8 No 8
- 4 7 Yes 8
For mbed-os releases after the patch was committed one can no longer specify the forth format for STM32 boards.
The problem comes from the way the fix was implemented
The implementer of the fix not only reversed the interpretation of the 1st argument in the method call but also collected the multiply copies of the Serial_Api.c file which had been distributed over many of the STM board level directories in the STM section of the targets directory tree and replaced them with a single Serial_Api.c file at the TARGET_STM level in the directory tree.
They somehow concluded that there are only three controllers in the STM product family which supported 7 bit characters and enclosed the 7 bit case for the switch statement, which converts the number of bits values in to a control register bit setting in a #ifdef block thereby preventing its inclusion unless one of these three controllers had been selected as the target.
Since there is no case 7 entry in the switch statement when a board other than one of these three is the target, control flow falls through to the default case which being unchanged from the pre patch implementation falls through into the 8 case. Since parity was also selected the hardware character length is then set for a 9 bit character and one ends up with 7 data bit a parity bit as the msb and a bit of undermined value between data bits and the parity bit. One is therefore unable to setup format 4
The 7 bit case for the three controller attempts to set a 8 bit character length when 7 bit with parity is selected and a 7 bit character length when no parity is selected.
I have not examined hardware specifications for the three board; however I find the idea of UART which support 7bit character length some what odd. I think this issue need further investigation. Do these controllers' UARTs really support 7 bit character lengths or is the seven referring to the number data bits in a 8 bit character
I am also filling a bug report on git hub and will be submitting a pull request to for a modification to Serial_Api.c which adds a #else clause to #ifdef allow 7 bits with parity to be specified for other board.
An additional question for discussion is what should be the proper behavior for the Serial format function when a user calls it with a length which is not supported by the target hardware.
I my pull request am setting it back to the pre patch behavior of setting an 8 bit character length independent of the parity selection
Steve Mylroie.
2
replies
The serial format method takes three arguments: number of bits, parity options and number of stop bits The interpretation of the first argument is some what ambiguous if a parity option other than no parity is selected Is the value the number of data bits or the character bit length, which is one greater than the number of data bits when the parity option is not none.
Prior to patch #4189 the implementation of the Serial format method for the STM32 boards assume the first argument value was the character length.
The more common interpretation is the value is the number of data bits. As a result a number of developer filed bug reports when having though they where setting up a link with 8 data bits and parity by specifying 8, and parity other than none. They found the msb of their data was being over written by the parity values.
Patch #4189 reversed the interpretation of the first argument so after the patch specifying 8 and parity results in the transmission of a nine bit character.
After the patch one can not long specify an 8 bit character length consisting of 7 data bits and a parity bit, which is a format used by many of the older serial line protocol including the SDI-12 data logger interface standard.
The UARTS in the STM32XXXX microcontroller support either 8 or 9 bit character lengths with the length selection via a bit in one of the UARTS control registers.
The microcontrollers should therefore be able to support 4 character formats
data bits, parity , character length (bits)
For mbed-os releases after the patch was committed one can no longer specify the forth format for STM32 boards.
The problem comes from the way the fix was implemented
The implementer of the fix not only reversed the interpretation of the 1st argument in the method call but also collected the multiply copies of the Serial_Api.c file which had been distributed over many of the STM board level directories in the STM section of the targets directory tree and replaced them with a single Serial_Api.c file at the TARGET_STM level in the directory tree.
They somehow concluded that there are only three controllers in the STM product family which supported 7 bit characters and enclosed the 7 bit case for the switch statement, which converts the number of bits values in to a control register bit setting in a #ifdef block thereby preventing its inclusion unless one of these three controllers had been selected as the target.
Since there is no case 7 entry in the switch statement when a board other than one of these three is the target, control flow falls through to the default case which being unchanged from the pre patch implementation falls through into the 8 case. Since parity was also selected the hardware character length is then set for a 9 bit character and one ends up with 7 data bit a parity bit as the msb and a bit of undermined value between data bits and the parity bit. One is therefore unable to setup format 4
The 7 bit case for the three controller attempts to set a 8 bit character length when 7 bit with parity is selected and a 7 bit character length when no parity is selected.
I have not examined hardware specifications for the three board; however I find the idea of UART which support 7bit character length some what odd. I think this issue need further investigation. Do these controllers' UARTs really support 7 bit character lengths or is the seven referring to the number data bits in a 8 bit character
I am also filling a bug report on git hub and will be submitting a pull request to for a modification to Serial_Api.c which adds a #else clause to #ifdef allow 7 bits with parity to be specified for other board.
An additional question for discussion is what should be the proper behavior for the Serial format function when a user calls it with a length which is not supported by the target hardware.
I my pull request am setting it back to the pre patch behavior of setting an 8 bit character length independent of the parity selection