5 years, 5 months ago.

Serial: What are the "Supported pins" ?

The Handbook for Serial says:

"The Serial Interface can be used on supported pins and USBTX/USBRX"

https://developer.mbed.org/handbook/Serial

So how do I find out what are the "supported pins" on a particular target platform?

Specifically, what are the "supported pins" on an ST Nucleo L152 ?

Specifying PC_10 and PC_11 (for Tx & Rx on UART4) does not seem to work.

I note that these pins are used by both UART4 and USART3 - so there must be more to it than just specifying the pin, surely?

Hence the opening question - how to find out which pins are (or should be) supported ...

Question relating to:

Cross-posted on ST forum: https://my.st.com/af43b47d

posted by Andrew Neil 12 Aug 2015

The online compiler doesn't seem to be much use for debugging this, and exporting seems to be broken at the moment:

https://developer.mbed.org/questions/60374/Where-does-the-export-go/

:-(

posted by Andrew Neil 15 Aug 2015

1 Answer

5 years, 5 months ago.

The platform page gives a bunch of them: https://developer.mbed.org/platforms/ST-Nucleo-L152RE/

Problem is that not all pin functions fit on the image, and that making it better accessible is not a high priority apparantly for the mbed devs... (Although in practise all possible pins should be supported)

You can find the supported pins in the source code here: https://developer.mbed.org/users/mbed_official/code/mbed-src/file/5afbce4ea2da/targets/hal/TARGET_STM/TARGET_STM32L1/TARGET_NUCLEO_L152RE/PeripheralPins.c

PC_10 and PC_11 are set there to use UART 4.

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

posted by Martin Kojtal 13 Aug 2015

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.

posted by Erik - 13 Aug 2015

@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!

posted by Andrew Neil 13 Aug 2015

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.

posted by Erik - 13 Aug 2015

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

posted by Andrew Neil 14 Aug 2015

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.

posted by Andrew Neil 14 Aug 2015

@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?

posted by Andrew Neil 19 Aug 2015

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

posted by Erik - 19 Aug 2015