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

Thread: Teensy4.0 does not receive data longer than 62 characters

  1. #1

    Teensy4.0 does not receive data longer than 62 characters

    Hello everybody. I'm writing a simple communication program with Teensy 4.0.

    Please give me a hint as data reception from the terminal does not go well.

    In the attached program, if I send characters over 62 bytes to Teensy4.0, it will no longer respond.

    Where is my mistake?

    Code:
    String    hostString = "";
    
    void setup() {
      // put your setup code here, to run once:
      Serial.begin(38400);
      hostString = "";
    }
    
    void    serialEvent() {
      while (Serial.available()) {
        char inChar = (char)Serial.read();
        hostString += inChar;
      }
    }
    
    void loop() {
      // put your main code here, to run repeatedly:
      if (hostString.length()){
        Serial.print(hostString);
        hostString = "";
      }
    }
    Last edited by defragster; 10-10-2019 at 10:07 AM. Reason: added # CODE attribute

  2. #2
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,948
    Tried that code here and it works - given "1234567890a1234567890b1234567890c1234567890d12345 67890e1234567890f1234567890g1234567890h"

    That is 8 sets of 10 digits and 8 letters - for 88 character total.

    Works for MOST any length String EXCEPT exactly this string of "1234567890123456789012345678901234567890123456789 01234567890abc" 63 chars plus NewLine :: Total 64.

    ANY set of 64 chars as such are Perfectly HIDDEN - until a longer or shorter string are send and then those buffered strings are released in order received.

    @Paul - this seems to be a USB receive bug.

  3. #3
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,948
    WITH A TWIST??? - written as a NULL term c string and not a STRING:
    Code:
    char szH[400];
    uint32_t ii=0;
    void setup() {
      Serial.begin(38400);
    }
    
    void serialEvent() {
      while (Serial.available()) {
        szH[ii++] = (char)Serial.read();
      }
    }
    
    void loop() {
      // put your main code here, to run repeatedly:
      if (ii) {
        Serial.print(szH);
        Serial.print("| #=");
        Serial.println(ii);
        for ( ii=0; ii<400; ii++) szH[ii]=0;
        ii=0;
      }
    }
    This works as in this SerMon output?
    12345678901234567890123456789012345678901234567890 1234567890
    | #=61
    12345678901234567890123456789012345678901234567890 1234567890a
    | #=62
    12345678901234567890123456789012345678901234567890 1234567890ab
    | #=63
    12345678901234567890123456789012345678901234567890 1234567890abc
    | #=64
    12345678901234567890123456789012345678901234567890 1234567890abcd| #=64

    | #=1
    12345678901234567890123456789012345678901234567890 1234567890abcd| #=64
    e
    | #=2

  4. #4
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    398
    I’m pretty sure this makes sense since the default serial buffer size is 64, I believe the number can be easily edited in one of the Teensy core files. So anything over 64 would be read in multiples instead of one long stream.

  5. #5
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    9,948
    Post #3 shows expected sensible results - NO PROBLEM after all ? - the lines and '|' separator show the newline placement and where 64 byte expected buffer shows up.

    >> post #1 && #2 with the STRING code is having an issue where the string isn't empty but somehow 'if (hostString.length()){' isn't triggering until it is a non 64 multiple?

  6. #6
    Senior Member vjmuzik's Avatar
    Join Date
    Apr 2017
    Location
    Florida
    Posts
    398
    Maybe the string isn’t be null terminated properly if the there’s an exact amount in the buffer?

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    20,683
    Just want to confirm this is on my high priority list of bugs to investigate & fix.

    There's a similar report on github, like the same issue.

    https://github.com/PaulStoffregen/cores/issues/401

    Even though this is high priority, I probably won't be able to really work on it until Nov 25th.

Posting Permissions

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