Baud rate generation is inexact

[bremoran]

When a baud rate is set in UART, SPI, or I2C, mbed-drivers does not provide feedback of the actual baud rate selected by hardware. Reporting of errors in this scenario requires one of three approaches:

• assert that baud rate is out of tolerance
• return an error code when baud rate is out of tolerance
• provide a query mechanism for baud rates.

cc @mjs-arm @niklas-arm @bogdanm @0xc0170

[bogdanm]

I'd make the baud function return the actual baud that was set and let the application deal with that on its own.
It's also worth looking at http://blog.xpcc.io/2015/06/08/computing-and-asserting-baudrate-settings-at-compile-time/ in the long run. We might be able to assert on out-of-tolerance baud rates even at compile time, which is extremely useful for >95% use cases out there.

[niklarm]

This needs support from mbed-hal in it's current implementation.
See also one of my first PRs:

• adds return of the generated frequency: this gives the user some idea of the error and hopefully leads to some better prescaler calculation algorithms in the future.

That blog post is amazing. We should hire the guy who wrote it. ;-P

[ciarmcom]

ARM Internal Ref: IOTSFW-2117

[bogdanm]

That blog post is amazing. We should hire the guy who wrote it. ;-P

[dudmuck]

If the user calls Serial.baud() before printing first character, wont get_stdio_serial() in retarget.cpp set baudrate back to 9600 because of stdio_uart_inited == false ?

[0xc0170]

If the user calls Serial.baud() before printing first character, wont get_stdio_serial() in retarget.cpp set baudrate back to 9600 because of stdio_uart_inited == false ?

If you use stdio Serial object, it would be initialized to the default one prior any use. If you got further questions, create a new issue for this please