Teensyduino 1.24 Beta #3 Available

Status
Not open for further replies.

Paul

Administrator
Staff member
Here is another beta test for Teensyduino 1.24:


Edit: old beta test linkes removed. Full non-beta release is here:
http://www.pjrc.com/teensy/td_download.html


The main change in support for Arduino 1.6.5r2 (Windows). A few minor bugs were also fixed since beta2.

Please give this a try and report any bugs. Try to include a sample program that reproduces the problem!
 
You'll be pleased to know my project now compiles without a hitch - so it was a 1.6.4 bug.

Thanks!

Jon
 
If the Arduino bugs keep up like this, maybe they'll gain a reputation like the old Star Trek movies, except it'll be the even numbers to avoid. ;)
 
Win8.1x64 >> arduino-1.6.5-r2-windows.zip >> Teensy Loader 1.24-beta3

It seems VERIFY is AUTO pushing HEX to Teensy?

I have an LC and a 3.1 online and twice got the 'bad device' dialog after VERIFY before any button?

Trying to use TyQt and they both aren't showing up right either - like something is stealing the come port before it can?

May be time to reboot - but something is odd - and must run just now.

Paul: Might this relate to what you saw as changed in the IDE on Serial?
I closed the IDE and now TyQt can see both ports. The IDE saw two but never received input on the one. THe LC keeps going away - so this may just be the computer - will update later.
 
Last edited:
Paul: Might this relate to what you saw as changed in the IDE on Serial?

No, or at least not directly related.

The serial monitor problem on Windows that delayed 1.24-beta3 for nearly a whole day turned out to be entirely a mistake on my part.

Back in the simpler times of Arduino 1.0.x, all of Arduino's Java source was contained in only 17 directories, with only 3 levels of hierarchy under app/src/processing/app. Oh how I long for those simpler days....

Now with Arduino 1.6.5, there are 4 locations. app/src/processing/app still is used, with 10 directories in 3 levels. But the pde.jar file is now also build with code from app/src/cc/arduino, which contains 16 more directories in another 3 levels of hierarchy. They're also now building a arduino-core.jar for the non-GUI stuff, with it's source in arduino-core/src/processing/app with many subdirs, though the java code is contained in only a dozen of them mostly contained in only 2 levels. There's also quite a lot of code now in arduino-core/src/cc/arduino, contained in 17 more directories on 3 levels of hierarchy.

Until 1.6.5, I've only needed to make edits to java source in app/src/processing/app and arduino-core/src/processing/app and a few of their subdirs. I manage my patching and JDK version checking with a number of small scripts. My patching process uses recursive "diff" and "patch" on those 2 directories.

With 1.6.5, Arduino's addition of a conceptually similar but very differently implemented feature to keep the serial monitor open caused massive merge conflicts. Most of the blame rests squarely on me, since I had gradually added lots of little and not-so-little patches into SerialMonitor.java over the years. On 1.0.x, that was really the only viable option. With 1.6.x, they added an AbstractMonitor.java file (thankfully containing a good amount of serial monitor speedups I'd previously contributed), meant to be inherited by different serial monitor implementations. I had meant to create a TeensyMonitor class to cleanly inherit from AbstractMonitor... but the path of least resistance was to bring in the work from 1.0.x as-is, and then as I kept working on it, more and more patches when into both SerialMonitor.java and AbstractMonitor.java. Earlier this week, I finally took the time to consolidate all of Teensy's very different stuff into TeensyMonitor.java.

However, the switch to a dedicated TeensyMonitor object required this tiny edit in MonitorFactory.java. Long term, I believe this is the right approach. It's working within the framework Arduino has created, at least to the best of my understanding of how they probably intended it to be used (of course, there's absolutely no documentation for any of this stuff... you have to learn & infer everything by reading the source code).

The 1.6.5 to 1.6.5r2 trouble came into play because I hadn't updated my scripts to deal with the fact I now had patches in 3 of the 4 locations, rather than just the 2 I've always patched before. I should probably adapt my scripts to treat the source as just 2 locations with much more heirarchy... but that's a bridge to cross when I need to patch 1.6.6.

This problem tripped me up for the better part of a day, mostly because there were no obvious errors. The unpatched MonitorFactory happily created instances of SerialMonitor, rather than TeensyMonitor. Fiddling with Windows always slows me down. I probably would have found and fixed this within minutes if it'd been on Linux... but 1.6.5r2 was only for Windows, so I didn't do any of my usual testing first on Linux and Mac.

So, ultimately, the problem turned out to be only a simple mistake on my part, failing to bring over one tiny but critically important part of my patch set from 1.6.5 to 1.6.5r2.

But along the way, I did enounter another rare corner case. Actually, maybe 2 or 3. They're so very hard to reproduce. But all were due to a couple threads continuing to run after closing the serial monitor, so the same simple fix applied to all.
 
TL;wtf . . . what a pain . . . stupid computers - more trouble than they are worth ;-)

So my Win8.1 system rebooted - something still very wrong:
> TyQt sees LC and a flash of the 3.1, and TY pops up 'permission denied ... com3' as the 3.1 pops into TY then the 3.1 leaves but Com3 returns active on the LC.
> So I IDE open com6 SerMon and it shows 'nothing'.
> Pull LC and put 3.1 on that cable and then it shows on COM3 - com6 active but empty?

Opened IDE 1.6.3 - of course I pushed the LC button since I swapped it with the 3.1 - now both in program mode and neither doing anything as AUTO is off

Odd that both devices mapping to COM3 - over top of each other it seems? IDE 1.6.3 shows both #3 & #6 ports. Indeed that is what DevMan shows: twin_com3.png

I'll kill them ALL and then reinstall drivers with TD1.24b3.
 
Seems well - Windows did something weird . . . I used a new HUB - it may have done something odd . . .

I uninstalled those 3 ports - re-ran TD as admin - installed drivers - now I have Com3 and Com4 and all may be well - did not reboot this time. More later if not well.

TyQt back in business and button jumping LC&3.1 working well. I'll post this back in my LC speed bug - but this will be a big improvement there for ANY use of Micros! In fact some LC users may need a warning about this build - turbo charging their app!
Hello World! ... LC w/F_CPU == 48000000 inWhileMax==248
Hello World! ... LC w/F_CPU == 24000000 inWhileMax==163

Hello World! ... T_3.1 w/F_CPU == 96000000 inWhileMax==822
Hello World! ... T_3.1 w/F_CPU == 48000000 inWhileMax==411
 
Last edited:
The compiler freezes hopefully seems gone, but I'm coding a lot in these days and with this version I've got a new entry!
I'm disconnect and reconnect Teensy with terminal open many times and always works good but one time I've noticed that terminal was empty and doesn't react, I have clicked again on Serial Monitor menu and...another terminal opened (and working). So for the first time I have got 2 serial terminal windows opened (one not working btw). This happened just one time with a Win7/64.
Not a big deal, everithing works smootly and finally no more (until now) freezes during compile that was really annoing.
 
@sumotoy: can you open Device Manager [ Windows Key+PAUSE / Device Manager (left edge) ]

Open the USB/PORTS section and see what associations you have there. 2 days back my Win8 machine mapped two Teensy units to same port and only the one worked. I never saw this before - may be a Windows Anomoly with a hub I added - or may be IDE related.

In earlier 1.6.0'ish builds I thought multiple SerMon worked - but not since. TyQt is your friend.
 
BUG?: I found that a tight [nearly pointless] while loop when compiled Optimized WORKS - same code compiled LC and T_3.1 when NON-Optimized precludes timer updates and microseconds and elapsedMicros FREEZES for the duration!

Code:
      while ( inWhile < inWhileMaxMan ) {
        inWhile++;
        //        qBlink();
      }

With qBlink it works in either case, and compiled OPTIMIZED it works.

I'll attach code that shows above loop non-optimized runs the counter but records no time - is it behavior to be expected?

View attachment qBlinkElapsedMMhangX.ino

WHY?: I got BIT by this trying to measure how much time the call to check elapsedMicros (or micros) added to a loop - how many times a loop could run when it had a defined exit value not a time wait - in following up on my recent bug to speed up LC Micros. And this is the DEFAULT LC compile setting. <edit> my test was going great until the LC version failed to exit a time based loop, took a while to see time was standing still.

Output looks like this from two runs OPTIMIZED and not - same results on LC::
Hello World! ... T_3.1 w/F_CPU == 96000000
__EUwait = 79 inWhile = 500 tsDiff microseconds = 79
__
==EUwait = 22 inWhile = 500 tsDiff microseconds = 21
==


Hello World! ... T_3.1 w/F_CPU == 96000000
__EUwait = 108 inWhile = 500 tsDiff microseconds = 108
__
==EUwait = 1 inWhile = 500 tsDiff microseconds = 1
==
 
Last edited:
I wondered about ' volatile uint32_t inWhile;' but hadn't tried, can only grasp at so many straws in a day.

<edit>
- just empirically confirmed the compiler optimization it not stopping time for empty loop but rather: compiling 'ii=0;while(ii<1000)ii++' as ii=1000;

Nice Towel Frank! I assumed it was a compiler issue - very pernicious. The good thing in my case is the problem became obvious, bad thing is how long it took to see it - really hard to debug when the first sign was USB output quits - even then working code before it blanked out.

When 'volatile' added it does stop the 'default' LC compile [non-optimized] from blowing up when time stops.

It also cuts in half the free running count in the Optimized compile with active qBlink.

And I just confirmed it stops these interrupts too: Timer1.initialize(MicrosVal);

Bottom Line: the Default LC compile can halt interrupts 'unexpectedly' in at least one case, the 'optimized' compile does not, it runs faster, but nearly doubles RAM and CODE space used. Not the 3.1 default but running out of room could be a shocker going non-optimized.
 
Last edited:
I tried those those steps from #3379 with a Teensy-LC on Linux. It didn't reproduce the problem. On the last step, the previously open serial monitor reconnects to the Teensy before I can move my hand over to the mouse to click the serial monitor button again.

Will try later today on Windows. Maybe it's slow enough on Win 7 to allow opening the window again?
 
I just downloaded arduino 1.6.5 now, and tried this teensyduino beta, it does not recognize arduino 1.6.5 directory (does recognize 1.6.4 directory) . Ubuntu 14.04 linux 64-bit.

http://www.arduino.cc/download.php?f=/arduino-nightly-linux64.tar.xz
http://www.pjrc.com/teensy/td_124-beta3/teensyduino.64bit


Edit: Ahh, nevermind, I thought the 2 links on the page were the same. I see it's 1.6.6.

I see this in revisions.txt
ARDUINO 1.6.6

[ide]
* Switched to Java 8, which is now both bundled and needed for compiling the IDE
* Added link to unofficial boards support list in preferences
* Limit of possible new sketches in a day raised to 676. Thanks @Chris--A

ARDUINO 1.6.5-r2 - 2015.06.17

[ide]
* Windows: fixed a problem that prevented opening the IDE when double clicking a
.ino file

ARDUINO 1.6.5 - 2015.06.15
 
Last edited:
This may be the root of 'orphaned' USB ports under windows and they may have parked a truck in the hole. Nothing good comes from Windows from fast/repeated USB plugging.

I may have done this as the new HUB I noted has a power switch on each port. I got some odd result and started flipping switches - and I may have 'followed' the recipe for #3379. I was mixing TyQt and SerMon - so didn't see '2 SerMon' - and it may relate to Windows[8] handling - and not show on other OS.

@sumotoy: can you open Device Manager [ Windows Key+PAUSE / Device Manager (left edge) ]
Would've been interesting knowing if this showed like mine did - though that was one device not two, it would maybe have indicated the 'orphan' COM#, which I've been seeing on occasion - this time it just remapped over same.
 
Would've been interesting knowing if this showed like mine did - though that was one device not two, it would maybe have indicated the 'orphan' COM#, which I've been seeing on occasion - this time it just remapped over same.

I have tried but just see one Teensy port, I'm on win7/64. The double Terminal win doesn't happen all the time I follow instruction for reproduce problem but only once/10, I noticed that device manager showed 2 Teensy port that time but after some secs the ghost port disappeared from device manager (and leaved the orphan terminal window inactive still open). In this way it's not such a big deal, but definetively a bug (from IDE and Macroshit).
The same thing happen with other board like UNO.
 
In this way it's not such a big deal, but definetively a bug (from IDE and Macroshit).
I assume you meant mIcroshit? [don't want to give them 'macro' credit] :) [or worse yet disparage MAC/Kraapentosh legacy]

I was trying to look at my dumb BUG? - all my COM's went offline - they would show as HID w/program {*TyQt shows the HID info} - but DevMan had no 'Ports (COM' with two powered teensy units.

- and just empirically confirmed the compiler optimization it not stopping time for empty loop but rather: compiling 'ii=0;while(ii<1000)ii++' as ii=1000;

*TyQt: Teensy.exe closed, press button: \\.\HID#VID_16C0&PID_0478#9&2F453361&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
 
Last edited:
- and just empirically confirmed the compiler optimization it not stopping time for empty loop but rather: compiling 'ii=0;while(ii<1000)ii++' as ii=1000;
Even worse : If ii is not needed, it becomes:
Code:
[/ code]

Correct: Nothing
:-)
 
Last edited:
Such efficiency! In this case I was misdirected seeing print(ii) value - maybe that was feked as: print(1000). Rather than set ii=0, I did some math to zero it - the compiler seems to pre-compute that and go for ii=1000.
 
Status
Not open for further replies.
Back
Top