Simple suggestion for easier debugging with Teensyduino

Theremingenieur

Senior Member+
We all agree on the fact that the serial.println debug method isn't optimal. But it works and is often used. There is just one thing which bothers me when I need to use it:
1) I write/edit my code for the Teensy 3.1 in Teensyduino.
2) I compile the code in Teensyduino and start the upload
3) The upload/reboot waits or hangs sometimes until I use cmd-TAB (on the Mac) to bring the teensy loader in the foreground (that's annoying, but not the big problem)
4) In order to see the serial output, I have to switch back to Teensyduino (another cmd-TAB) before I can press Shift-cmd-M to open the serial monitor

I can naturally insert a delay(5000) in my code to have enough time to open the serial monitor, but...

Wouldn't it be a good idea to implement a permanent listener (on the selected serial port) in Teensyduino which automatically opens the serial monitor (and/or brings it to the foreground) as soon as serial data arrives? With that, there would be no more need for a delay() in the setup part of the sketch and many keystrokes to catch the debug output, but as soon as there was some output, the serial monitor would automatically pop up. And, if everything goes well, it would remain closed.

Am I the only one who would like that feature?
 
Free Atmel Visual Studio + Visual Micro plugin.. Excellent IDE. Built in Serial Monitor that auto-reconnects after a download, a power-cycle, etc. 2+ Serial monitor windows can be running if you have multiple boards in use (as I often do, in communications work). Serial monitor windows can be placed where desired in the IDE, or as paned, say, 3 of them stacked vertically on the right side of and within the IDE window. There is an optional semi-debugger in Visual Studio. You set conditional breakpoints as usual, like break if condition-true, or print and continue, then build,download,run. You don't alter your source code; the VS debugger inserts code to achieve the breakpoint in a cloned source file. It's an odd debugger, but good for many uses. Odd, because it's hardware independent and is a compromise since there's no JTAC/SWD hardware or CPU traps used. The IDE is free; the debugger has a free trial and a low cost.

If you've never used a real IDE like the above or Eclipse, with the editor helping you every step - function prototype pop-ups, goto-where-defined-any-file, etc., it's like moving from a model-T to a Lexus.
I've used Eclipse. Its the choice for Linux based developers. But VIsual Studio+VisualMicro is, for its AVR/Teensy/ARM targets, much better, and installs in 2 minutes without struggles.
 
Last edited:
Thank you for the hint. I'll give it definitively a try if there is a version for the Mac. Is there perhaps somewhere a step by step tutorial for setting up the IDE so that it will communicate with the Teensy 3.1 in the same comfortable manner as Teensyduino (write code, compile, upload)?
 
Back
Top