RTEMS | arm/stm32f4: extend USART DR field to 9 bits (!1141)

Wed Mar 18 21:18:15 UTC 2026

Mohamed Ayman commented on a discussion on bsps/arm/stm32f4/include/bsp/stm32_usart.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1141#note_146132

 >  #define STM32F4_USART_SR_FE BSP_BIT32(1)
 >  #define STM32F4_USART_SR_PE BSP_BIT32(0)
 >  	uint32_t dr;
 > -#define STM32F4_USART_DR(val) BSP_FLD32(val, 0, 7)
 > -#define STM32F4_USART_DR_GET(reg) BSP_FLD32GET(reg, 0, 7)
 > -#define STM32F4_USART_DR_SET(reg, val) BSP_FLD32SET(reg, val, 0, 7)
 > +#define STM32F4_USART_DR(val) BSP_FLD32(val, 0, 8)
 > +#define STM32F4_USART_DR_GET(reg) BSP_FLD32GET(reg, 0, 8)
 > +#define STM32F4_USART_DR_SET(reg, val) BSP_FLD32SET(reg, val, 0, 8)

Quick question regarding my MR updating the macro to a 9-bit mask:

While this correctly matches the STM32F4 hardware maanual, I noticed console/usart.c is hardcoded strictly for 8-bit (casting to char and relying on Termios).

Since the driver initializes CR1 to 8-bit mode, my patch break existing console output, but true 9-bit communication won't actually work as is.

How would you prefer I handle this?

1. Keep it**:** Merely for hardware correctness (accepting the driver won't use the 9th bit).
2. Revert it: Change it back to 8-bit to match the driver's current limitations and avoid confusion.
3. Expand it: I can look into adding a custom raw to usart..c to actually support 9-bit mode.

Let me know which direction you'd prefer for the BSP

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1141#note_146132
You're receiving this email because of your account on gitlab.rtems.org.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260318/85beaf26/attachment.htm>