Configure stdio baud rate

[kjbracey]

Magic is built in to initialise and bind stdio to a target-specified serial port. This is lovely.

But people still write code like this:

Serial output(USBTX, USBRX);
int main()
{
     output.baud(115200);
     output.printf("\r\n\r\nConnecting...\r\n");

They start with the Serial object because they need to set the baud rate. If they did use stdio, best they could do would be this slightly iffy mixed version:

Serial output(USBTX, USBRX);
int main()
{
     output.baud(115200);
     printf("\n\nConnecting...\n");

(assuming #1876 is merged). They can't drop the board pin knowledge.

Stdio serial baud rate should be configurable ("mbed.stdio-serial-baud") so the example app can just be:

int main()
{
     printf("\n\nConnecting...\n");

with baud set in the json. App is now board portable.

@geky

[bogdanm]

Agreed with this, with one exception: I believe that the default value for the baud rate should be defined by the target, not by a library. The main reason for this is that I've worked with a few MCU boards that had hardware limitations regarding the maximum serial baud rate (either because of the MCU itself or because of the clock source), which makes this a hardware-specific attribute. So it makes sense to be specified by the target. We can default it to 115200 in Target and override first in derived targets (if required by the hardware for whatever reason) and then in the application, if the application needs another baud rate.

[SeppoTakalo]

I agree with bogdanm. Default baudrate should be set by the target board/MCU.
Application may be allowed to change that, but it should not be required to specify that.

[kjbracey]

Yes, makes sense for default to be target-specified.

But would that then be an "all-serial-port" default? So if opened with Serial? Or specifically the default for a serial port if used for stdio? I think it should be the latter.

Really, the current state is that the system default is 9600 for all serial ports on all boards. And because we don't like that default, all(?) applications override terminal serial to 115200.

So the proposed change is that boards should have better defaults - ie 115200 if possible, so applications should be able to relax and not bother specifying. Assuming that they don't require a specific board rate - they might for talking to peripherals, but shouldn't for terminal output.

(I still think 115200 is only barely acceptable - I'd rather be using 460800 as we always used to. I guess there's merit in trying to go for a usually-possible common denominator across boards though).

[sg-]

The default baudrate by historic precedent is defined by the platform being mbed OS. An application could override this but all targets should use the default same baudrate which is platform defined, not target defined. Last thing we want is different targets with different baudrates. How would you ever know what to set the terminal at?

This should be fixed to use a common configuration value for the platform https://github.com/mbedmicro/mbed/search?utf8=%E2%9C%93&q=serial_baud%28obj%2C+9600&type=Code

[bogdanm]

Last thing we want is different targets with different baudrates.

I couldn't agree more, but what happens if for whatever reason the target is not able to provide the expected baud rate? Ultimately, the baud rate is hardware-dependent. So what about this:

• we start with defining the default baud rate in the platform configuration.
• if at some point we find some target(s) that are unable to sustain that baud rate, we move the configuration to the target system configuration instead of platform configuration.

How does that sound?

How would you ever know what to set the terminal at?

Displaying the project configuration will be enough, since that'll contain the default baud rate, no matter where it is defined.

[geky]

Are there any targets that are unable to support 9600?? It appears that 9600 is a requirement for serial support, and a reasonable one. I'm agreeing with sg- here, 9600 serves as a good baseline for both the targets and mbed (not to mention it's already the default for host PCs).

The issue I've observed is users are finding 9600 an insufficient default for stdio for applications. As noted by kjbracey-arm, the current workaround of declaring a Serial object on USBTX/RX is not platform portable (maybe we don't care about this), and more importantly, it invalidates the motivation behind a default baud rate, leaving the user still having to guess what to set the terminal to.

I don't understand the motivation behind changing the default baud rate across all serial objects.

[kjbracey]

I would be quite happy for stdio terminal to have a different default to the serial object itself. That seems perfectly natural - you are specifically configuring the console - "console=ttyS0,115200" in Linux-speak, not a generic serial port.

Raw serial port devices having default rate 9600 is conventional for backwards compatibility. Consoles less so.

But if the console does not have a fast/sensible default speed on platforms I'm going to be using, I just want an application or its config to be able to (attempt to) set 115200 baud ratio for stdio without knowing precisely what board it's running on. Doesn't seem like a lot to ask.

(Personally, this does not feel to me like an application setting though - it feels more natural to me that the target should choose an appropriately fast console output rate. But if the platform chooses 9600, I am going to need the application to override it).

Obviously the setting will be somewhat target-specific. Some targets may not have stdout going to a UART, and some targets might have a UART not capable of 115200. (Seriously?)

We just want to say "stdout, if going to a UART, please go fast". If it can't go fast, then it can't. But it can almost certainly go faster than 9600. Any "set baud" API should logically select the closest possible.

Maybe this could be done through API - get a file handle via fileno(stdout), map to serial device handle, and manipulate it? Not sure there's enough infrastructure there to support that though.

[bogdanm]

We need to progress this. At this point, I don't have a strong feeling anymore about the location of this setting (core vs target), I just want to move it forward. So, if you want to have it in the core, that's fine with me.

[ciarmcom]

ARM Internal Ref: IOTMORF-162

[sg-]

Seems to be resolved