Detailed description
- This is a small new feature.
- The existing problem is BMP platforms parroting back whatever baudrate you set it to. The discrepancy gets significant at high baudrates, close to Pclk DIV16, effectively ruining communications to other boards +-5% (especially TraceSWO Async which is tuned by an integer(!) divisor off TraceClk).
- This PR makes TI ICDI and STM32 platforms recompute real baudrate by reading back the programmed USART BRR divisors. It's a function missing from libopencm3 API, but to upstream this there OVER8 support would be required.
As I was compile-testing this, I also noticed some stray hardcoded 0x85 endpoints in ICDI and replaced them with new compile-time macros.
Runtime tested on blackpill-f411ce, swlink-bluepillplus, stlinkv3-minie (f723). I needed this for better TraceSWO Async UART diagnostics, to ensure TraceClk/SWO_PR is close enough to Pclk/BRR. I don't know how to visibly test how this positively affects aux_serial behaviour, I didn't see a difference in minicom, ckermit, tio. Only tio can reach non-standard baudrates because it uses a different API to set them (kinda like orbtrace serialFeeder), minicom can't (it uses B2000000 macros etc.)
Minor problem with this is I don't like that neither BMF nor libopencm3 has guardrails limiting BRR to 16 or more, so I could "set" and "read back" a baudrate equal to Pclk, which does not work.
Your checklist for this pull request
Closing issues
## Detailed description
* This is a small new feature.
* The existing problem is BMP platforms parroting back whatever baudrate you set it to. The discrepancy gets significant at high baudrates, close to Pclk DIV16, effectively ruining communications to other boards +-5% (especially TraceSWO Async which is tuned by an integer(!) divisor off TraceClk).
* This PR makes TI ICDI and STM32 platforms recompute real baudrate by reading back the programmed USART BRR divisors. It's a function missing from libopencm3 API, but to upstream this there OVER8 support would be required.
As I was compile-testing this, I also noticed some stray hardcoded 0x85 endpoints in ICDI and replaced them with new compile-time macros.
Runtime tested on `blackpill-f411ce`, `swlink`-bluepillplus, stlinkv3-minie (f723). I needed this for better TraceSWO Async UART diagnostics, to ensure TraceClk/SWO_PR is close enough to Pclk/BRR. I don't know how to visibly test how this positively affects aux_serial behaviour, I didn't see a difference in minicom, ckermit, tio. Only tio can reach non-standard baudrates because it uses a different API to set them (kinda like orbtrace serialFeeder), minicom can't (it uses B2000000 macros etc.)
Minor problem with this is I don't like that neither BMF nor libopencm3 has guardrails limiting BRR to 16 or more, so I could "set" and "read back" a baudrate equal to Pclk, which does not work.
## Your checklist for this pull request
* [x] I've read the [Code of Conduct](https://github.com/blackmagic-debug/blackmagic/blob/main/CODE_OF_CONDUCT.md)
* [x] I've read the [guidelines for contributing](https://github.com/blackmagic-debug/blackmagic/blob/main/CONTRIBUTING.md) to this repository
* [x] It builds for hardware native (see [Building the firmware](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-firmware))
* [x] It builds as BMDA (see [Building the BMDA](https://github.com/blackmagic-debug/blackmagic?tab=readme-ov-file#building-black-magic-debug-app)) *and should not affect it*
* [x] I've tested it to the best of my ability
* [x] My commit messages provide a useful short description of what the commits do
## Closing issues