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.
10 years, 5 months ago.
Serial communication is missing a few bytes now and then
I'm using the Mbed serial port driver v16466 from http://mbed.org/handbook/Windows-serial-configuration to dump the contents of a connected EEPROM to my PC. Problem is that I'm missing some data now and then.
I tried communications at different baud rates down to 115k2 but this doesn't seem to improve things. Data is pure text without control characters. Windows 7. LPC2368, internal Flash is too small for file storage and no SD card option.
Do you people have any idea about what the possible problem could be?
I'm using simple print calls to dump the data to the PC. Should I add some delay period? Do I need to flush the USB data now and then?
3 Answers
10 years, 5 months ago.
Ceri, I'm sending my text in a similar way as to what you suggest and that is how I noticed the faults.
10 94 73 59 22 69 8D 78 88 84 21 31 08 87 30 C2
I'm sending 16 bytes of data in a line, formatted as hex data with a space in between, i.e. 3 * 16 = 48 characters per line.
Guenter, Yes, I need some kind of flow control, but how to enable that for both USB devices, i.e. the mbed on one side and the PC on the other? I enabled RTS/CTS in my terminal emulator program, but that didn't help. I guess this flow control is only talking to the PC's internal USB driver but isn't leaving the PC.
Does the mbed USB driver have flow control? And when yes, how to use it?
I did some more investigations. The schematics for the LPC2368 board seem incomplete: http://mbed.org/media/uploads/mbedofficial/mbed-002.1.pdf In this schematic there is only one microprocessor, the other LPC2148 is not in these sheets. Now my educated guess is that this LPC2148 is the USB device that programs the raw data into the LPC2368, this device is also known as the 'MBED interface'.
From another thread I learned there is no flow control between the two CPUs: http://mbed.org/forum/bugs-suggestions/topic/454/ [quote]That is exactly the case - it is a standard 2 wire UART connection between the target (LPC1768) and the USB interface (mbed interface), so there is no flow control.
If one is sending the other just needs to keep up, as with any 2-wire UART connection (it is the same as if the UART was connected to a standard FTDI 2-wire interface, instead of the mbed interface).
We have looked at providing a virtual serial port via JTAG, but the reality is the basic UART covers the common case very well so it'd be a lot of work for little gain right now.
Simon[/quote]
So, WRITEABLE seems like the only method to test for the MBED Interface to have space available. Too bad this function only returns 0 or 1. This means that before every byte sent you have to test for space being available. This is a shame as it means printf is not usable and a custom function has to be designed.
posted by 03 Jan 2014
10 years, 5 months ago.
What kind of flow control are you using on the PC side. XON/XOFF or RTS/CTS hardware flow control? I assume, that the PC is loosing some bytes on input. Programming Port Input on Windows is quite tricky. Try a very slow rate, down to 4800 baud or even less and see what happens. Guenter.
10 years, 5 months ago.
Have you tried sending a 'large' block of formatted text, such that when you view in terminal (with mono spaced font)
the text will be very noticeable if there is a fault.
Something like this ...
int k;
for (k=0;k<1000;k++)
{
pc.printf ("[%04x] ABCD EFGH IJKL MNOP QRST UVWX YX12 3456 7890 ##@<>??\r\n", K);
wait_us (27);
}
You can then make this much bigger / smaller, with or without delays etc
Hope this was usefull.
Ceri
if you look at : WRITEABLE
then this might solve your problems,
I personally have not noticed this, but generally, I do not send out 'continuous' data.
Cheers
Ceri
posted by 02 Dec 2013