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

Thread: Teensy 3.0 USB Serial speed

  1. #1
    Junior Member
    Join Date
    Nov 2012
    Location
    Utah
    Posts
    10

    Teensy 3.0 USB Serial speed

    So I have Teensy 3.0 code that is a simple serial echo:

    void loop()
    {
    uint16_t length = Serial.available();
    if (length > 0)
    {
    Serial.readBytes((char *)Buffer, length);
    Serial.write(Buffer, length);
    Serial.send_now();
    }
    }

    On the PC side I:
    track the time of:
    loop 100 times
    send a blob of data
    receive the echoed blob

    I'm getting strange results that are much slower than I would expect. I'm hoping someone can shed some light on what is going on.

    I was expecting to see it take about 200ms for any blob size up to 19 * 64 bytes (in theory anyway).

    Instead I see something that makes me think there is some kind of packet count limiting that I haven't seen before:

    (There are 100 transactions per test)

    Somehow these first all send 1 packet and receive one packet in just 1 ms per transaction. (How does that work?)
    16 byte payloads (1600 bytes sent, 1600 bytes received in 139 ms)
    32 byte payloads (3200 bytes sent, 3200 bytes received in 101 ms)
    48 byte payloads (4800 bytes sent, 4800 bytes received in 99 ms)
    64 byte payloads (6400 bytes sent, 6400 bytes received in 101 ms)

    Now it bumps to 2 ms per transaction
    80 byte payloads (8000 bytes sent, 8000 bytes received in 200 ms)
    96 byte payloads (9600 bytes sent, 9600 bytes received in 200 ms)
    256 byte payloads (25600 bytes sent, 25600 bytes received in 201 ms)

    Then works its way to 3 ms per transaction - I was expecting 2ms per up to about 1K bytes per transaction.
    272 byte payloads (27200 bytes sent, 27200 bytes received in 248 ms)
    288 byte payloads (28800 bytes sent, 28800 bytes received in 297 ms)
    304 byte payloads (30400 bytes sent, 30400 bytes received in 299 ms)
    640 byte payloads (64000 bytes sent, 64000 bytes received in 302 ms)

    Then it jumps to 4ms per transaction.
    656 byte payloads (65600 bytes sent, 65600 bytes received in 399 ms)
    672 byte payloads (67200 bytes sent, 67200 bytes received in 400 ms)

    and so on.

    Did I miss something here? Why is the time going up is discrete steps well below the packet limit? I thought I had done this sort of thing with other microcontrollers and it worked fine (SiLabs, MSP430 are two most recent, I was thinking both show about 1ms out 1ms back with 9-10 packets per transaction working fine before it bumps to more time).

    Any ideas?
    Attached Files Attached Files
    Last edited by DeweyOxberger; 02-24-2013 at 02:15 AM.

  2. #2
    Junior Member
    Join Date
    Nov 2012
    Location
    Utah
    Posts
    10
    The pc side in and out buffers are set large.

    I'm new to Teensy and Arduino - If I make changes to the usb stuff how do I recompile it?

  3. #3
    Junior Member
    Join Date
    Nov 2012
    Location
    Utah
    Posts
    10
    I see what is going on.

    Serial.readBytes gravitates toward reading in 64 byte chunks. That's cool. I just may not get all the data in one grab.

    My test application is too basic. If I send 80 bytes the Teesny 3.0 gets the first 64, sends them back, then gets the remaining 16 bytes and sends them back. That gets fairly complex. As the data size grows it can span multiple usb frames with all the this back and forth sending.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,176
    Quote Originally Posted by DeweyOxberger View Post
    My test application is too basic. If I send 80 bytes the Teesny 3.0 gets the first 64, sends them back, then gets the remaining 16 bytes and sends them back.
    Data that isn't exactly 64 byte multiples does not cause much performance loss. But wait for a reply before sending the next piece of data is the thing that really kills performance on USB. If you redesign for a protocol where you always transmit data the instant it's available, perhaps adding extra bytes so you can sort out the data when you receive it on the other side, you'll get dramatically better performance.

    The USB code on Teensy will automatically pack successive writes efficiently into full size packets, so USB bandwidth is used efficiently. It does require a tiny bit more CPU time to do so, but the impact is very small.

  5. #5
    I was wondering how I could increase the Teensy 3.0's RX Buffer Size as my HTML POST responses get cut off. I am using HardwareSerial2.

    My POST Response:
    HTTP/1.1 200 OK
    Cache-Control: private
    Content-Type: text/htm

    My Code:
    while (sGPRS.available() > 0)
    {
    incomingByte = sGPRS.read();
    Serial.write(incomingByte);
    delay(10);
    }

  6. #6
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,176
    Quote Originally Posted by wynandmurray View Post
    I am using HardwareSerial2.
    Sure. Just edit hardware/teensy/cores/teensy3/serial2.c

    Look for this code:

    Code:
    ////////////////////////////////////////////////////////////////
    // Tunable parameters (relatively safe to edit these numbers)
    ////////////////////////////////////////////////////////////////
    
    #define TX_BUFFER_SIZE 40
    #define RX_BUFFER_SIZE 64
    #define IRQ_PRIORITY  64  // 0 = highest priority, 255 = lowest

Tags for this Thread

Posting Permissions

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