stupid problem with Serial.printxx in setup loop (teensy3 b10)

Status
Not open for further replies.

sumotoy

Well-known member
I have a stupid but annoying problem with Serial.print or Serial.println that it's never displayed in setup.

OS win7(32bit)
IDE beta12

Take as example this simple code:
Code:
void setup() {
  Serial.begin(38400);
  Serial.println("started");
}


void loop() {
  Serial.println("bip\n");
  delay(5000);
}

There's no way to show up in serial monitor the text printed in the setup (in this case "started"). I try to a delay of 3600 to 8000 before the first println but I can show it only when I open the serial monitor window and just sometimes works.
Tried to change teensy3 freq to 24,48,96Mhz but no changes.
Any other text outside setup will always work. Cannot figure out how to solve this, any ideas?

edit.
sorry,I'm using b12!
 
Last edited:
Yup, that's a known problem. This will help:
Code:
void setup() {
  Serial.begin(38400);
  while(!Serial);
  Serial.println("started");
}
Another option I have used occasionally is to make the code loop until I hit a button.

Pete
 
Thanks pete, I come at this workaround just some min ago! I can live with that, spent hours to figure out if was my notebook or whatever!
 
I did a little more investigation into this problem. Of course, in the long term I'm planning to implement Teensy 2.0's Arduino Uno reset emulation on Teensy 3.0. More on that in a moment.

However, it looks like the while(!Serial) wait is failing in some cases, when it really should work. Looking at the packets with a USB protocol analyzer, it seems like Arduino (or something else) is opening the port briefly at 57600 baud, then closing it and reopening again. The timing is very quick, but Teensy 3.0 is able to respond and leave the while(!Serial) loop. For the ASCIITable example, all 4237 bytes get sent very quickly, even though whatever is opening the port only takes 5 ms from the control line state message that sets DTR+RTS to the control line state that clears them. When the serial monitor opens the port several milliseconds later, it's too late. ASCIITable already transmitted everything to whatever this mystery process is that's opening the port.

Right now, my best guess is there's something going on within the Arduino IDE. Something on the PC is opening the port unnecessarily. What, I still don't know. I'm going to keep investigating.....

Regarding the long-term solution, here's an explanation I wrote some time ago for one of the Kickstarter updates.

Traditionally, Arduino has used a 2 chip design, where the USB to serial converter is a dedicated chip. When you open the Arduino Serial Monitor, the change on the DTR signal resets the AVR chip, causing your program to restart a fraction of a second after the serial monitor window appears. It's a very convenient feature (though some people might prefer their board never automatically reset). Lots of Arduino sketches and library example depend upon this automatic reset behavior.

For years, Teensy 2.0 has emulated this 2-chip reset behavior, using only a single chip. It's tricky. Interrupt-based code parses a restart request, which is sent as the serial monitor window is opening (Teensy doesn't use DTR, so it the auto-reset isn't easily happen by accident while using non-Arduino software).

Microsoft's driver has terrible bugs which are triggered if the device instantly resets before the request is acknowledged, or before a couple more followup requests also complete successfully, so a software-based timer is started. When the timer elapses, a reset is simulated by shutting down all the on-chip peripherals and jumping back to location 0. But the USB port is left operating, as if nothing happened. Then the USB initialization code checks to see if the USB is already running. If it is, an alternate initialization is done. If not, the USB is initialized. All the critical USB state variables are located in a special "noinit" memory section, so the C runtime startup code doesn't overwrite them. When actual cold USB startup is done, they all have to be written, even if they're zeros.

If that sounds like an overly complex implementation for a minor feature, perhaps it is? But years of experience with Teensy 2.0 shown it really makes a big difference in usability. It's also really convenient. I'm going to implement it in Teensy 3.0 soon.

Of course, "soon" hasn't turned out to be as fast as I'd hoped. So many other things have happened since then. I do plan on implementing the 2-chip reset emulation. It's tricky to get right, and I have at least a few other higher priority tasks to do first (including better documentation on the website).

Anyway, for the moment I just want to share what I've found... this strange problem where Arduino (or something) seems to be opening the port very briefly before the Arduino Serial Monitor actually opens it, causing while(!Serial) to exit prematurely.
 
So get rid of serial monitor of arduino can be a valid solution?

I have try to use another terminal (Xshell 4) and get rid of arduino just to understand what Paul said and I have the same problems, this doesn't free completely Arduino from being suspected but there must be something else.
Unfortunately Paul is right, while(!Serial); it's almost useless and at the moment there's no sure solution for print something on screen prior loop cycle. The only workaround I find it's print all I need from setup in the first loop cycle... It's not elegant but it's the only valid solution I found.
 
Status
Not open for further replies.
Back
Top