0

I'll be teaching a year 10 class on the Intel Galileo gen2 and there'll be a wide (but high-level) programming curriculum, which includes introduction to console printing, using Serial.

I'd like the students to be able to write their printing code in setup() so that it's only printed once and easily readable by them. However, it's impossible to be fast enough to upload a sketch and open the Serial Monitor (which flat out refuses to open before the sketch has started), and the Serial Monitor closes itself upon re-uploading code.

Without unnecessary (and potentially for the students, confusing) use of the delay function in setup(), it's impossible to read any output originating from setup(); only things printed in loop() (which are constantly re-printed) are ever discoverable.

So; is there a way to somehow keep the Serial Monitor open, or make it capture output from before it's opened, or delay the entire running of the sketch (rather than chucking in delays)?

We'll be using the standard Arduino IDE.

EDIT

This script was run in one of two conditions...

void setup() {
  Serial.begin(9600);

  // ensure Serial is ready
  delay(1000);

  for (int i=0; i < 10000; i++) {
    Serial.println(i);
  }
}

void loop() {      
}

When the Serial Monitor was opened immediately after upload, all numbers from and including 0 to 9999 were recorded in the monitor.

When the Serial Monitor was opened around 5s after upload, only numbers upward of 2243 were observed. This suggests the sketch WAS being re-run (else no numbers would have been captured; the sketch runs in significantly less time than 5s) but that all numbers between 0 and 2243 were not captured by the monitor; as if opening the Serial Monitor late enough to cause a re-run causes some monitor overhead.
This strange loss of numbers is NOT time dependent: increasing the initial delay from 1s to 4s (and waiting longer after upload before opening the Serial) did not at all vary the soonest number recorded, suggesting it is some 'line' based overhead (but of course, how could anything fail for 2243 lines?!)

With that mystery aside, this negates the automatic re-running of the sketch upon Serial Monitor opening from being actually useful.

  • 1
    Opening the serial monitor normally resets the Arduino anyway. I have no problem outputting stuff from setup on a Uno. Is this different with the Galileo? – Roger Rowland Feb 8 '15 at 4:33
  • Serial Monitor is only a convenience (although the need to close and reopen it is APITA). There is nothing stopping you from using any other serial program; e.g. I have used Minicom, but most often use a dedicated serial program for logging. – Milliways Feb 8 '15 at 5:25
  • @RogerRowland On the Galileo, the sketch 'appears' to restart, but actually a lot of early Serial is not captured. See my edit. – Anti Earth Feb 8 '15 at 11:48
  • @Milliways The objective outcome of this question is to avoid confusion in highschool students, something that wouldn't be worsoned by only the most absolutely intuitive, minimal, usable serial program. – Anti Earth Feb 8 '15 at 11:59
1

Have you tried hitting the reset button while the serial monitor is open? I have done this on other Arduino boards to capture stuff in the setup loop that was occurring too fast. Otherwise using Serial1 for output connected via a FTDI cable may be the way to go.

  • Of course! Pressing reset does not require a re-upload, keeping the Serial Monitor open to capture all printing (no buffer filling). Perf – Anti Earth Feb 10 '15 at 0:46
2

I assume you are uploading the code over USB - the same USB that you want to monitor for output from the sketch? If so, the serial monitor has to release the port for the uploader to be able to use it, and vice-versa, as your computer's OS will only assign a USB port to one application at a time.

It may seem like the IDE is one application containing an uploader and a serial monitor, but the IDE is not much more than a "pretty face" that runs separate compiler and uploader applications on your behalf.

Several work-arounds are possible (although I think a delay() statement in setup() is the clearest of the choices):

  • Add a delay statement in the setup function. If you must this, you can put it in main() just before the setup() call, but you'd take away a learning opportunity.
  • Use a separate hardware or software serial channel for the monitor which you could leave connected and wouldn't interfere with uploading;
  • Use the loop() function instead, and put a forever loop at the bottom to prevent it returning, thus making it a runs-once function.
  • Does this really explain that strange 'missing lines' anomaly described in my edit? I can give the computer 10s of delay to switch back to the monitor after uploading, but it still misses information. – Anti Earth Feb 9 '15 at 0:25
  • Also, there's nothing special about the setup function, right? If I made loop a runs-once with no delay in setup, I'd have the same symptoms wouldn't I? – Anti Earth Feb 9 '15 at 0:26
  • 1
    The only reason to put the printing code in loop() is that it is conventional to use setup() for initializing stuff, and loop() for doing work. Otherwise, you're right - no difference. As to the missing lines, I suspect it's something to do with the serial buffer filling before you connect to let it empty, but I'm not sure, without some testing, what the interaaction is. But in my projects I typically print the revision # at start-up. Without a brief delay, my terminal usually displays a bunch of garbage at connect, before it gets synchronized. – JRobert Feb 9 '15 at 22:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.