Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
8 years, 1 month ago.
Using the UART on DISCO-L476VG board
I am trying to use the "Serial4" UART on the ST DISCO-L476VG board to talk to a GPS module, this is shown as using pins PA_0 and PA_1 in this diagram: https://developer.mbed.org/platforms/ST-Discovery-L476VG/ After looking at the schematic I removed R54 and C43 to isolate it from the on-board joystick switch. In my code I added the UART device using: Serial gps(PA_0, PA_1); gps.baud(9600); When I write to this using gps.putc() I can see characters coming out on an oscilloscope but I never get any characters read from the UART (other than a zero the very first time). If I look at the input pin status within the processor I can see it is being toggled, I looked at the input pin status using this sort of idea: DigitalIn uart_rx(PA_1); DigitalOut red_led(LED2); red_led = !uart_rx; Any idea as to why the UART is not seeing any incoming data?
1 Answer
8 years, 1 month ago.
Consider to remove also R55 to isolate the PA_0 line and test again.
Paul - the removal of R55 should help but may not be the root cause of your issue. What are the details of your GPS module ? Baud rate correct for your module ? The GPS operates from 3v3 CMOS levels ? If RS232 then you must insert the required RS232 transceiver to interface with the module. Share more details if the R55 fix does not work. Many are using 115200 as the baud rate in their code.
Also, your code:
red_led = !uart_rx;
will not work to allow you to visualize the data flow on the RX pin. That is due to the very brief time period, even at 9600 baud to enable / disable the RED LED. Us humans just cannot see data flashes this quickly. While the LED will flash as the data is toggled on the RX line, we just cannot view the flashes due to the very brief ON time. Consider to test with a simple LED flasher mbed code to get a feel for the amount of delays required to view the LED on / off cycle. Otherwise, will need a bionic eye from Steve Austin - astronaut...
Dear Sanjiv, thanks for getting back to me quickly. It turns out there are two problems I had not realised:
1) The first of these, and the underlying reason, is the "Serial" library is utter rubbish! If your application is unable to keep up with the incoming data then the class' readable() member and the getc() function both act as if there is no new data. Yes, you read that correctly - instead of just dropping the character(s) you failed to read on time and allowing you to read future data, the library LOCKS UP AND NEVER READS ANY MORE!
That to me is insufferably dumb behaviour, and there is nothing documented to warn a user that it behaves in such a stupid manner in the event of overrun. The solution to reading rapid data reliably seems (so far at least) to be using the buffered serial library here:
https://developer.mbed.org/users/sam_grove/code/BufferedSerial/
2) The attempt to debug via the LED was flawed for a different reason. While I could see it flash dimly with each test character sent when typing from a keyboard, it has the (again undocumented) side effect of preventing the UART from also using that I/O pin. While I would expect that trying to write to an I/O pin would obviously prevent it being a usable input to another peripheral such as the UART, I could see no reason why reading its status would impact on the availability of signals to shared I/O.
Basically, trying to check the I/O to see if I was using the correct pin and it was receiving any messages delayed finding the real reason for the problem, which was the fundamentally stupid behaviour of the "Serial" class when buffer overrun is possible.
Regards, Paul
posted by 01 Nov 2016