Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 8 of 8

Thread: Maximum Data Rate still 12 Mbit/sec for the Teensy 4.0?

  1. #1
    Junior Member
    Join Date
    Apr 2020
    Posts
    5

    Maximum Data Rate still 12 Mbit/sec for the Teensy 4.0?

    What is the maximum data rate for communication over USB for the Teensy 4.0? Is it still 12 Mbit/sec?
    Do the 12 Mbit/sec use UART with 8 usable bits and 2 bits for starting and stopping communication, so that I am left with 1.2 Mbytes/sec?
    I heard that in practise one should only use 70% of the data rate to mitigate problems, which would leave 840 Bytes/sec or 6720 Bit/sec.
    I need to transfer two 14 bit sensor readings from the teensy to my PC and one 14 bit signal from the PC to the teensy.
    Does this mean I can only send and receive the data 6720/(14*3) times per second, which would result in a sampling time of 0.00625 samples/sec?
    If possible I would like to have a lower sampling time, because in my application it matters a lot.

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    13,910
    Teensy 4's with the 1062 MCU have DEVICE and HOST hardware that will connect at 480 MB/sec.

    All Teensys use NATIVE MCU hardware USB - they do not channel through a UART or any intermediate device - they connect at the maximum supported rate the Host machine can offer. So the FULL USB protocol is in use end to end - with all the design details that entails - as best as Paul can manage. That includes 512 bytes packets, and work done through DMA to minimize impact on time in loop() with multiple buffer available.

    On one benchmark where the T_3.6 at 12 Mbps from the 'Device' gets about 25K lines/sec to Windows SerMon - the T_4's are seeing at or over 500K lines/sec. The PC handling and display to SerMon is the slow part keeping it from maintaining 800K lps or more so far. Each line is about 32 bytes IIRC.

    So give it a try and see what the results are. The PC won't generally keep up with Teensy 4 at full speed and will in that case make the Teensy wait - especially if the receiving code isn't optimal.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,080
    Teensy 4.0 has 480 Mbit/sec USB. It is native USB, not hardware serial.

    The actual achievable speed depends on many factors, especially how efficient the software is on the PC side. This is the main benchmark we've been using to test Teensy's speed transmitting to a PC.

    https://github.com/PaulStoffregen/US...rint_speed.ino

    Initially at Teensy 4.0 release we were getting about 100K lines/sec sending to the Arduino serial monitor. Then I put a *lot* of work into optimizing the Arduino IDE's java code. Details here:

    https://www.pjrc.com/improving-ardui...r-performance/

    We can now run *much* faster, especially with Windows and Linux. Sadly, the MacOS drivers seem to consume a tremendous amount of CPU time when running at these speeds, so performance on Macintosh isn't as good.

    Hopefully you can see 2 things. Speeds much faster than 12 Mbit/sec are indeed possible, and the actual speed achieved depends heavily on the software receiving on the PC side.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    24,080
    Quote Originally Posted by defragster View Post
    The PC handling and display to SerMon is the slow part keeping it from maintaining 800K lps or more so far. Each line is about 32 bytes IIRC.
    Above about 600K lines/sec, I believe the CPU overhead on the Teensy side is also playing a strong factor. When using a powerful Linux desktop as the receiver, the speed does indeed scale up to over 800K lines/sec if you overclock Teensy to 900+ MHz. A couple months ago I did a little investigation in the CPU use and got the initial impression a good portion was in the USB code (especially checking the queue transfer descriptor status) and another pretty substantial part was in the Print class, probably converting those integers to ascii text.

    I didn't put much time into that, because we're already so fast that sustained transfer triggers buffering bugs on Windows anonymous pipes and excessive CPU usage by Apple's drivers. Instead I turned my attention to USB audio and other stuff, and of course new hardware.

  5. #5
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    4,031
    IIRC, there are USB hubs out there that if any USB 1.1 device (mouse, keyboard, older Teensy, etc.) is plugged into it, it slows the other connections down to USB 1.1 (12MB/s) speeds as well.

    In addition, you should also need to make sure the cables used are capable of handling USB 2.0 (480 MB/s) speeds.

  6. #6
    Junior Member
    Join Date
    Apr 2020
    Posts
    5
    Thank you all for your help I still have a few questions left:
    In the bechmark code there is a line
    Code:
    Serial.begin(1000000); // edit for highest baud your board can use
    . Can I ignore the comment, because I thought no matter which baud rate is given, the Teensy will always use maximum speed?
    Also, is there some kind of error checking during data transmission over USB or should I use something like a checksum?
    Because I need the data in realtime, is it still up to date that the USB host controllers of most PCs only read data every milisecond? In this case I would probably use
    Code:
    Serial.send_now()
    every milisecond to get the sensor readings with the best fixed sampling time possible.
    Just out of curiosity: I read that someone got a "baud rate" of 115200 out of a Teensy 3.6 over USB connection. Is that possible or is it limited to 12 Mbit/sec?

  7. #7
    Senior Member+ MichaelMeissner's Avatar
    Join Date
    Nov 2012
    Location
    Ayer Massachussetts
    Posts
    4,031
    Quote Originally Posted by Paolo1 View Post
    Thank you all for your help I still have a few questions left:
    In the bechmark code there is a line
    Code:
    Serial.begin(1000000); // edit for highest baud your board can use
    . Can I ignore the comment, because I thought no matter which baud rate is given, the Teensy will always use maximum speed?
    On ARM Teensys, the baud rate is ignored for USB connections. On the Arduino UNO and other processors using the AVR 328p chipset, the USB support was done with a separate chip that read the lines as serial UART lines, and there the baud rate was used.

    Quote Originally Posted by Paolo1 View Post
    Also, is there some kind of error checking during data transmission over USB or should I use something like a checksum?
    Because I need the data in realtime, is it still up to date that the USB host controllers of most PCs only read data every milisecond? In this case I would probably use
    Code:
    Serial.send_now()
    every milisecond to get the sensor readings with the best fixed sampling time possible.
    Just out of curiosity: I read that someone got a "baud rate" of 115200 out of a Teensy 3.6 over USB connection. Is that possible or is it limited to 12 Mbit/sec?
    The main connection on the Teensy 3.6 is limited to 12 Mbit/sec as a maximum speed (i.e. in practice, it may be lower). Note, the Teensy 3.6 (and 4.0/4.1) have a second USB host controller, and I believe using that secondary USB controller would give you USB 2.0 speeds. I've not used the USB host controller extensively. The Teensy 3.0, 3.1, 3.2, 3.5, and LC don't have the separate USB host support.

  8. #8
    Senior Member
    Join Date
    Feb 2018
    Location
    Corvallis, OR
    Posts
    334
    If you want data read, transmitted and received with low jitter, you should probably consider collecting your data with an IntervalTimer, accumulating a buffer with a number of time-stamped samples, and sending the buffered data at regular intervals. With that protocol, the time at which the data is received is no longer the key factor in determining when the sample was taken.

    I'm not sure you can depend on your receiving PC to get USB data at exactly 1mSec intervals, so it is best to have a time stamp in the data. Since the USB link has lots of bandwidth, the additional data needed for the time stamp should not be an obstacle. If you are collecting a lot of data, you can send packets which have one time stamp and a hundred or a thousand readings between time stamps.

    I don't think you need a checksum for data sent over USB. The USB link has internal validity checks. (That is my understanding from using FTDI USB interfaces which used bulk data transfer protocols that implement validation and retransmission as required).

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •