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.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
