• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 2884 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

USB CDC serial speed on MSP430

Sven Kautlenbach
Intellectual 470 points


Hi!

I am modifying the Chronos USB access point. I have successfully raised the radio link speed to 250 kbps. Now the bottleneck seems to be the communication between the AP and PC, since the CDC device serial speed seems to be 115200. I browsed the code where it is being set. There is a function called Handler_SetLineCoding () which in turn calls USBCDC_handleSetLineCoding(). The latter seems to do nothing, just returns false. Since I am not familiar with all of the USB stuff, I wonder through what mechanisms the virtual COM port speed is set and controlled? In my PC application I set the speed to 256000 and it still delivered data with the same speed as it was on the 115200 baud. Can the speed be modified at all? If not, then probably the solution would be to use pure UART on the AP and use some converter?

Thanks in advance!

  • 0
    Guru 34483 points

    Sven Kautlenbach said:

    Since I am not familiar with all of the USB stuff, I wonder through what mechanisms the virtual COM port speed is set and controlled? In my PC application I set the speed to 256000 and it still delivered data with the same speed as it was on the 115200 baud. Can the speed be modified at all? If not, then probably the solution would be to use pure UART on the AP and use some converter?

    Changing BR on CDC is not related to speed and it is not used (except in USB-UART bridges or something like this). I done some benchmarks for CDC on MSP430...


    http://forum.43oh.com/topic/2775-msp430-usb-benchmark

  • 0 in reply to zrno soli
    Intellectual 470 points

    Hi! 

    Thanks for the reply, I have already read the benchmarking and those threads... So as I can conclude the baudrate is static and not configurable through any mechanism? By changing the baud rate of the serial reader tool, it just communicates with the windows buffers with that speed? Thus, I should send the data capsuled into the buffers as large as possible, because of the usb polling and controlling data overhead?

  • 0 in reply to Sven Kautlenbach
    Guru 227245 points

    Sven Kautlenbach said:
    So as I can conclude the baudrate is static and not configurable through any mechanism?

    It isn’t static, it is void. The AP sends data through USB. But since most applications do not know how to fetch data from a plain USB connection, the driver simulates a COM port. You can think of it as an UART with a large FIFO and immense baudrate. Every now and then, a data packet arrives and suddenly, the FIFO is full with data in no time.
    However, the first byte of data can only be read when the last bit of the USB package has arrived. You don’t have a ‘stream’ of incoming data at a fixed baudrate, as you’d have with a real serial connection.

    When the virtual COM port belongs to an USB/serial bridge, then the baudrate you can configure does define the baudrate, the UART at the other end of the USB cable operates on.
    Still the USB connection is based on packets: the UART receives something and after some time or when some bytes have been received, the USB controller sends an USB package to the PC, where all data appears at once. It would be an immense overhead if every byte of data would be sent separately. But this introduces delays and increased latency. An USB/ser converter behaves therefore differently than a real local UART chip. Data comes in and goes out in chunks.

     

    Sven Kautlenbach said:
    Thus, I should send the data capsuled into the buffers as large as possible, because of the usb polling and controlling data overhead?

    Indeed, it is a good idea to assemble the data in a local buffer first and then send it to the serial port as a block. Especially, if assembling the data takes some time (in which case the driver could trigger a timeout and send a smaller USB package with all the USB overhead).
    But I guess, on today’s PCs, this is not a problem – the code assembling the data will likely be faster than any timeout. But this depends of course on the virtual COM port driver too.

  • 0 in reply to Jens-Michael Gross
    Intellectual 470 points

    Continuing the discussion...
    What is the maximum length of data I can submit to USBCDC_sendData() then? 

  • 0 in reply to Sven Kautlenbach
    Guru 227245 points

    Sven Kautlenbach said:
    What is the maximum length of data I can submit to USBCDC_sendData() then? 

    I don’t have experience with the MSP USB controller, but my best guess is, that it is less than the 2k USB ram (minus all the other organizational data and structure overhead that has to reside in USB ram too).

**Attention** This is a public forum