Mbed config for STDIO_UART_TX not consistently implemented across targets

[sg-]

Issue request type

• Question
• Enhancement
• Bug

Description

OCD kicked in and now that that #6687 and #6688 are opened, the real issue is that we seem to have wrapped MBED_CONF_TARGET_STDIO_UART_RX around STDIO_UART_RX (same for TX) in PeripheralNames.h and newer targets (or not all targets) were updated with this capability. This seems like a change that should have been introduced in some common code a stub to connect the default pins from the port. The search link below should highlight the problem.

https://github.com/ARMmbed/mbed-os/search?l=C&q=STDIO_UART_RX&type=

Looking further at this, opening up config in targets not part of mbed_lib.json seems to be another part of the problem with compatibility across targets. https://github.com/ARMmbed/mbed-os/blob/master/targets/targets.json#L715-L718

So what we end up with is some targets with this capability and even then, some targets have tried to turn this on in targets.json but not wrapped the pins properly but that could be due to the lacking documentation around this define (or enum in some cases) and porting in general.

[0xc0170]

@bulislaw Please review
[Mirrored to Jira]

[marcuschangarm]

As a user, I would expect to find pin names in the file named PinNames.h and not in PeripheralNames.h.
[Mirrored to Jira]

[0Grit]

Just to confirm this is an issue.

This caused us some extra thinking in our initial efforts at creating a custom board support package. The way the STDIO_UART defines were wrapped up just seemed off, and lead to some uncertainty in how to implement our BSP.
[Mirrored to Jira]

[kjbracey]

That MBED_CONF_TARGET_STDIO_UART_RX is not standard - it is effectively board-specific for STM32, presumably done by the STM guys. No core code is looking at those.

Indeed until very recently we've not had any standard target JSON options. The first were added in #6603 a couple of weeks ago.

Following discussions on #6603, I think the console settings currently in platform/mbed_lib.json should migrate down to the base target alongside those flow control ones, so they can be overridden by target JSON.

I don't know whether it makes sense to also put all the console pin choices there - maybe totally eliminate them from PeripheralNames.h/PinNames.h. I don't immediately see why not.
[Mirrored to Jira]

[kjbracey]

Any clean-up will cause some compatibility glitches for custom out-of-tree targets. If we want to do it, my suggestion is:

• add target.console-uart-tx/rx/cts/rts options in the base target, alongside the console-uart-flow-control we've just put in
• make those options have "macro": "STDIO_UART_RX" etc so they're setting the standard names currently in the target header files and used by the platform code
• Remove all STDIO_UART_RX etc enum and definitions from the header files and transfer the same settings to the targets.json under each family. Inheritance should actually make this smaller than the C version

Making these things be defines rather than enum values would also be helpful for probing - not being able to do compile-time tests on pins being available is annoying. pin == NC has to be done at runtime.

Later step - move other platform.stdio-uart settings to target.console-uart to make them target overridable too. For backwards compatibility would still need them in the original platform location as null for the apps that expect to be able to control via that name.

[Mirrored to Jira]

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2131