2015-08-12 04:14 PM
I have already asked this question on the mbed site:
https://developer.mbed.org/questions/59656/Serial-What-are-the-Supported-pins/
It isn't clear from the Handbook whether this is even supposed to be supported. I tried instantiating as:Serial uart4( PC_10, PC_11 );
But is seems that can't be sufficient, as USART3 can also use PC10 & PC11 - so how could it know?!
#fail #nucleo #nucleo #uart #mbed #possibly-worst-forum-software #serial #keil #mbed
2015-08-12 05:27 PM
Well the ST-LINK VCP is definitely USART2 via PA2/PA3 on the
https://developer.mbed.org/platforms/ST-Nucleo-L152RE/
But somewhat irritatingly that conflicts with the D0/D1 of the header.I'd have to wade through the manuals for USART3/UART4, but I could swear you'd have to manually modify the board to get those to the VCP TX/RX pins.2015-08-12 05:38 PM
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/user_manual/DM001058pdf
2015-08-12 05:46 PM
http://www.st.com/st-web-ui/static/active/en/resource/technical/document/datasheet/DM00098321.pdf
UART4 would also be viable on these pins, if you really needed to use USART3 somewhere else and in synchronous mode. With 64-pins I find that a tad improbable.Not into mbed myself, but would suspect calling out the U(S)ART and specifying the pins to select as AF, should be enough for the magic inside the board/chip support code to get the chip set up properly, provided you'd dealt with the wiring externally.2015-08-12 11:39 PM
Sorry - I'm not talking about the
ST-LINK VCP here at all.
I have serial comms with the PC over theST-LINK VCP working fine.
What I'm looking to do is to also have UART (or USART) comms on the header pins.The UART4 pins seemed initially convenient - but any other pins would do.I'm also not much into mbed (yet) - but the documentation on this does seem very skimpy (being kind).:(2015-08-13 10:06 AM
I've use PA9/PA10 USART1 before.
PA10 (D2) USART1-RX is usable for GPS shield.The Morpho header has more opportunities.2015-08-14 02:47 PM
Experimenting further, I can successfully printf() to UARTs 1 & 3; but printf() to UART 4 or 5 hangs.
#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(''
Hello World !'');
while(1) {
wait(1);
pc .printf(''
SERIAL_TX: %d.'', i);
//uart1.printf(''
UART1: %d.'', i);
//uart3.printf(''
UART3: %d.'', i);
uart4.printf(''
UART4: %d.'', i);
//uart5.printf(''
UART5: %d.'', i);
i++;
myled = !myled;
}
}
2015-08-14 03:57 PM
Yeah, I'd take a look at the board support code, and make sure it's enabling the right APB clocks for the USARTs
2015-08-15 04:03 AM
Yes.
The online compiler seems pretty useless in getting to see that, and exporting seems to be broken at the moment.2015-08-19 04:43 AM
Thoroughly cheesed-off with mbed, Keil, and Nucleo at the moment!
:(As noted, the debugging and browsing in the online compiler is pretty useless; so I thought I'd export to Keil.But the mbed Export function is not working - everything is just stuck in the cloud.:(I eventually found a way to export something, but the Project does not build - and Keil's error message is unhelpfulhttp://www.keil.com/forum/60126:(I did finally get the project to build, only to find that it doesn't have theboard support as source code anyhow - so useless for debugging this issue!!
:(