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

Thread: Bug in Serial.println() ?

  1. #1
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,354

    Bug in Serial.println() ?

    This sketch behaves rather oddly using beta12 on Teensy3.
    Code:
    void setup(void)
    {
      Serial.begin(9600);
      while(!Serial);
    }
    
    int count = 0;
    void loop(void)
    {
      if((count/5) == 0) {
        Serial.println("RMC A 2013/01/25 18:43:18.000 52 05.5686N - 106 35.7915W  9 A");
      } else {
        Serial.println("RMC A 2013/01/25 18:43:18.000 52 05.5686N - 106 35.7915W  10 A");
      }
      count++;
      if(count > 9)count = 0;
      delay(1000);
    }
    It should just repeatedly write the first string 5 times, then the second string 5 times etc.
    The first string is 61 chars long and each one is printed as soon as it is generated. The other string is 62 chars long and five of them are written but none of them will appear on the Serial Monitor until the next 61 char string is printed which flushes the buffer.
    Adding Serial.flush() doesn't help.
    I don't think this is in the Serial Monitor itself because this doesn't happen when run on a Nano (also using 1.0.3).
    When the 62 char string is written, println() adds CR/LF on the end which makes it 64 chars long.
    If you change the second string from 62 chars to 126 chars, the same thing happens so it appears that writing a string that is an exact multiple of 64 chars is the problem.
    Also, if you write the 62 char line 64 times, that will cause a flush of the whole lot, presumably because it has filled an internal 4096 char buffer.


    Pete
    Last edited by el_supremo; 01-25-2013 at 07:24 PM.

  2. #2
    Senior Member
    Join Date
    Nov 2012
    Posts
    412
    Adding Serial.flush() doesn't help.
    You have to use Serialx.clear();

    http://forum.pjrc.com/threads/13017-...appear-to-work

  3. #3
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,354
    But why would I need to do that anyway? If I output lines that are not a multiple of 64 chars in length (including the CR/LF) then they are shown immediately on the Serial monitor. Lines that are a multiple of 64 chars are buffered.

    Does the code I posted work as I describe?

    Pete

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,079
    Which operating system are you using?

  5. #5
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,354
    Windows 7 64-bit

    Pete

  6. #6
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,354
    I wrote a Windows command line program to read the 62 char+CR/LF output of my GPS sketch. The windows program also soaks up 64 lines before displaying them all in one go but lines shorter or longer than that are displayed as they are sent.
    So, it is a weirdness in Windows and not a bug in println, nor is it a bug in the Serial Monitor.

    Sorry Paul.

    Pete

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,079
    I was able to reproduce the problem, at least partially, using Linux. My workbench is currently consumed a big pile of stuff for the WS2811 library.

    You are probably right, this is likely a bug in my USB code. In fact, I think I know what it is.... but it's going to take me a few days to investigate. I need to change my setup to use a Widows test machine and the USB protocol analyzer.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,079
    Just a quick followup, I'm working on this today. It's complicated to fix.....

  9. #9
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    22,079
    Here is a fix. Replace hardware/teensy/cores/teensy3/usb_serial.c with this file.

    Please confirm if this fully resolves the problem?
    Attached Files Attached Files

  10. #10
    Senior Member
    Join Date
    Nov 2012
    Posts
    1,354
    I've tested it with strings with lengths of from one to 79 chars and it works with all of them.
    Thanks Paul.

    Pete

Posting Permissions

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