This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430 Serial Port Delay

Other Parts Discussed in Thread: MSP-EXP430F5529LP, MSP430F5529

I am using an MSP-EXP430F5529LP.  I have written some firmware that communicates with a LabVIEW application running on a PC using the serial to USB communication on the development board. The LabVIEW application requests some data, and the microcontroller responds. Both request and response are about 5 to 6 bytes each. I am running the serial port at 115200 buad 8-N-1. Everything work OK, except there is a nearly 90 ms delay between receiving the request, and receiving the first byte of the response. After the first byte, all the other bytes come in in under 1 ms. I put a scope on the RX and TX lines on the development board, and the firmware is responding in less than 1 ms, so the firmware isn't the issue. The delay was 600ms, but then I realized I can make it a lot shorter be turning off the debugger, which makes sense.


I have a feeling this delay is caused by the USB to serial hardware, or, more like, the USB driver. I have noticed a few thing about the driver that make me think it is a bit flaky (like the com port changing when I unplug and re-plug).


Does anyone know what might be causing this delay?

Does anyone have any idea how I might be able to narrow down what is causing it?

  • Jo-Jo Smith said:

    I have a feeling this delay is caused by the USB to serial hardware, or, more like, the USB driver. I have noticed a few thing about the driver that make me think it is a bit flaky (like the com port changing when I unplug and re-plug).

    USB - UART bridge on MSP430F5529 LP is done in software, and if this is not enough (because of any reason) for you,  use some hardware USB - UART bridge chips. There is no problems with CDC driver, and it will go up to 1 MByte / s. Problem can be in small chunks of transferred data, because USB is not design for frequently transfer of few bytes.

  • Is the delay only at 115 or other speeds? Any correlation

    What USB API MSC example are you using?

     

     

     

  • I tired it at 9600, and there is still an 86ms delay.  My guess is that the delay is somehow related to the USB and VISA driver interaction.

    I think I'm going to try to write a small test application in C++ to avoid the VISA and LabVIEW stuff. If it is still delayed, then I can only assume it has to do with the USB driver, which, like I said above, isn't everything that it could be.

  • Did you write the test application?

    Did you store the USB traffic in any logs?

     

  • Even a hardware USB/ser bridge chip wouldn’t do better (actually these are too just MCUs with a serial and one USB port and some software between).
    The problem is USB.

    If you send a request, when the application ahs sent the last byte to the virtual serial port on the PC, the driver waits for more bytes coming in. And after some timeout, it sends all the previous data through USB in one block. When the USB package has completely arrived at the LP’s FET, it is unpacked and then sent to the MSP. So the first byte of the command arrives at the MSP long after the last byte has been sent by the application. And on the way back it is the very same. Serial communication over USB has an inherent latency. In fact, USB may be the easiest, but for sure is the worst way of communicating when latency is a problem. Guess why gamers for a long time refused to use USB mice and insisted on using real serial (on a real COM port) or PS/2 mice instead: noticeably lower delay between mouse movement and game reaction. Just because of the inherent USB latency.

**Attention** This is a public forum