It might have a high priority but there are too many tasks with the same priority :-D A joke aside, that picture would be polluted in my opinion for some platforms. A user should always refer to a code or reference manual.

Just my 5 cents

A large part of the advantage of mbed should be that you don't need to go through the reference manual everytime you want to use a PWM output. Or through the source code of mbed.

A single picture would have it polluted yes. But with flash/html5/javascript you could create a dynamic picture. With a button which allows you to show only all serial ports for example. Or all serial and all spi ports so you can select two which do not require the same pins.

But lets face it, that is never going to happen.

@Erik: Sadly, the platform page does not help at all - it gives no indication of which pins are supported by the Serial library.

Thanks for the source code link, The online compiler was completely unhelpful in getting to this: it has not "go to definition" facility, and just says "too many files" for the libraries.

But that's just a pin list - there's nothing to say that whether those pins are or are not supported by the Serial library.

:-(

I agree that the whole point of something like mbed should be to make this easy - rather than being an exercise in reverse engineering!

Every pin listed on the platform page *should* be supported.

Every pin in the source code *is* supported. The Serial library uses those pinlists 1 on 1. If the pin is in it, the Serial library can use it.

Of course it is possible there is a bug, which could for example cause the pin function to be set incorrectly, but in principle the code does support it when it is in that list.

OK - so I modified the Nucleo "Hello World" example:

#include "mbed.h"

//------------------------------------
// Hyperterminal configuration
// 9600 bauds, 8-bit data, no parity
//------------------------------------

Serial pc(SERIAL_TX, SERIAL_RX);

//Serial uart1( PA_9,  PA_10 );
Serial uart1( PB_6,  PB_7  );

Serial uart3( PB_10, PB_11 );
Serial uart4( PC_10, PC_11 );
Serial uart5( PC_12, PD_2  );
 
DigitalOut myled(LED1);
 
int main() {
  int i = 1;
  pc.printf("\r\n\nHello World !");
  while(1) { 
      wait(1);
      pc   .printf("\r\nSERIAL_TX: %d.", i);
      uart1.printf("\r\nUART1: %d.", i);
      uart3.printf("\r\nUART3: %d.", i);
      //uart4.printf("\r\nUART4: %d.", i);
      //uart5.printf("\r\nUART5: %d.", i);
      i++;
      myled = !myled;
  }
}

It works fine as shown, printing to the PC, UART1, and UART3.

But, if I uncomment either the UART4 print, or the UART5 print, or both, then I get just the first message out on the other UARTs, and the LED does not blink.

So it seems that the code hangs in printf() to either UART4 or UART5

It doesn't help if I comment-out the prints to UART 1 & 3 - ie, it's not just a case of "too many UARTs" - it is specifically UARTs 4 & 5.

@Erik: Yes, it looks like there is some bug in the handling of UART4 and UART5.

So how do I go about debugging that?

The online compiler doesn't seem to allow this.

Exporting the Nucleo_printf example does not give source code for the mbed "board support" stuff - including 'Serial'

https://developer.mbed.org/teams/ST/code/Nucleo_printf/

So how do I get hold of the complete, buildable source?

Here it is: https://developer.mbed.org/users/mbed_official/code/mbed-src/

If you find a bug you can submit the actual fix on github. But if you just want to fix it for yourself (first), it is easiest to delete your mbed lib, and import the mbed-src lib. The pinout code I posted above, serial code is somewhere at targets/hal/stm/l1/serial_api.c