PDA

View Full Version : Teensyduino 1.24 Beta #3 Available



Paul
06-18-2015, 11:48 AM
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!

Pensive
06-18-2015, 10:19 PM
You'll be pleased to know my project now compiles without a hitch - so it was a 1.6.4 bug.

Thanks!

Jon

PaulStoffregen
06-18-2015, 10:31 PM
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. ;)

defragster
06-18-2015, 11:17 PM
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.

PaulStoffregen
06-18-2015, 11:20 PM
I've added a message to the download page (http://www.pjrc.com/teensy/td_download.html), to discourage use of Arduino 1.6.4.

Paul
06-19-2015, 12:20 AM
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 (https://github.com/PaulStoffregen/Arduino-1.6.5-Teensyduino/blob/master/app/src/processing/app/TeensyMonitor.java).

However, the switch to a dedicated TeensyMonitor object required this tiny edit in MonitorFactory.java (https://github.com/PaulStoffregen/Arduino-1.6.5-Teensyduino/blob/master/app/src/cc/arduino/packages/MonitorFactory.java#L43). 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 (https://github.com/PaulStoffregen/Arduino-1.6.5r2-Teensyduino/commit/6941c70d54488cf8ffe2f62609bdedfad605720e#diff-645bfbf7671e038bafc2340179e93e7eR248) applied to all.

defragster
06-19-2015, 01:32 AM
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:4510

I'll kill them ALL and then reinstall drivers with TD1.24b3.

defragster
06-19-2015, 02:04 AM
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

sumotoy
06-20-2015, 10:47 PM
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.

defragster
06-20-2015, 11:34 PM
@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.

defragster
06-20-2015, 11:54 PM
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!


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?

4524

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
==

PaulStoffregen
06-21-2015, 08:20 AM
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.


Maybe related to this?

https://github.com/arduino/Arduino/issues/3379

Frank B
06-21-2015, 09:07 AM
while ( inWhile < inWhileMaxMan ) {
inWhile++;
// qBlink();
}




I think the compiler detects this "pointless" loop and removes (optimize away) it. GCC is good at this :-)
You could try to declare inWhile volatile.

defragster
06-21-2015, 10:05 AM
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.

sumotoy
06-21-2015, 01:47 PM
Maybe related to this?

https://github.com/arduino/Arduino/issues/3379

Definetively yes!

PaulStoffregen
06-21-2015, 01:57 PM
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?

linuxgeek
06-21-2015, 04:22 PM
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

defragster
06-21-2015, 04:31 PM
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 (https://forum.pjrc.com/threads/28939-Teensyduino-1-24-Beta-3-Available?p=75884&viewfull=1#post75884) 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.

sumotoy
06-21-2015, 04:51 PM
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.

defragster
06-21-2015, 05:36 PM
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? (https://forum.pjrc.com/threads/28939-Teensyduino-1-24-Beta-3-Available?p=76093&viewfull=1#post76093) - 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}

Frank B
06-21-2015, 06:00 PM
- 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
:-)

defragster
06-21-2015, 06:47 PM
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.

Frank B
06-21-2015, 07:01 PM
If you want to "play" a bit:
-O3 enables more optimizations
-O0 disables all optimizations

Frank B
06-21-2015, 07:04 PM
..but you should install the newest launchpad-gcc in this case, it's a bit better with -O3

esapode688
06-22-2015, 02:01 PM
On OS-X There is still the firewall request everytime I open Arduino

4536

PaulStoffregen
06-23-2015, 01:48 PM
I've released version 1.24. No major surprises. The recently Teensy-LC optimizations and another minor fix went in, but otherwise it's the same as beta3.


..but you should install the newest launchpad-gcc in this case, it's a bit better with -O3

This will have to wait. There's no way I'm going to do a toolchain upgrade without a lengthy beta period.


On OS-X There is still the firewall request everytime I open Arduino

Try Ardiuno > Preferences and turn off the version check.

Frank B
06-23-2015, 02:31 PM
no way I'm going to do a toolchain upgrade without a lengthy beta period.
No problem.
My mention of a newer gcc was an answer to @defragster..

jakorten
06-23-2015, 08:08 PM
I had an issue with Time.h that might have been caused by Teensyduino. It appears there was a folder under documents "Time" that included DS1307RTC, TimeAlarms and original Time. That is why the compiler could not find it. I did not manually change anything afaik, so I suspect either Arduino or Teensyduino to have moved it?

esapode688
06-26-2015, 06:46 AM
Try Ardiuno > Preferences and turn off the version check.

Doesn't Work :(

But i can confirm that the message pops up only with teensyduino installed. Without: it doesn't

Frank B
06-27-2015, 10:15 PM
I noticed, that "optimized" is now "O", not "O2"
Is that a mistake or intentional ?

DrDarin
07-05-2015, 04:47 AM
Mine also auto-pushes on verify.

xxxajk
07-27-2015, 04:02 AM
Paul: Did a quick check here. All seems good on 1.6.5. Great work!

Read passed, Read 2048 sectors (1024K) in 1786ms
Even properly runs in host mode, no compile or run problems.

defragster
08-07-2015, 05:58 AM
Just back home first Win 8 desktop now running Windows 10.

It runs what I was running before as far as I've gotten - not far.

Arduino 1.6.5 and Teensy Loader 1.24 working fine.

Runs TYQT and NOTEPAD++

SEARCH in Explorer seems faster - may just be this machine, but it worked. EDGE is Stupid, still like IE11.

You can get the ISO file to burn an upgrade DVD (https://www.microsoft.com/en-us/software-download/windows10) to do multiple updates without multiple downloads or waiting for an invitation.

defragster
08-07-2015, 06:25 AM
Not sure if this is new from Win10 or IDE 1.6.5:

Running this code (https://forum.pjrc.com/threads/29314-Teensy-3-1-serial-stops-responding-after-a-minute?p=79297#post79297)

Unplug T_3.1 and replug it powers blinking - but the IDE Serial Mon loses the Handle/Link to the USB, clicking the 'SerMon' icon opens a new window on the same port working? The same happens if I push the Program button - I now have FOUR IDE SerMon windows open on COM3 and only the LAST one is active.

I opened TyQt and perform the same tests (replug or Upload) and it maintains the port and keeps working.

NOTE: I have DevMgr open and COM3 is always the port, only a single active Teensy, It goes and quickly returns, even if I jump to a new cable end/USB port. Good sign for Win10 USB.

I think this shows the weirdness that I thought I didn't see before IDE_1.6.5 earlier in this thread - on this same machine that was Win8, good thing is Win10 seems to be better at the Device part, but the IDE is failing where TyQt is tracking fine.

defragster
08-07-2015, 08:57 AM
On Win7 with IDE 1.6.3 and Teensy Loader 1.24b3 I don't see the Win10 behavior from the IDE.

Took IDE to 1.6.5r2 and released 1.24 TLoader: It works [re-power or re-upload ] on Win7x64

Is the Revision.txt the only way to ID the r2 build of 1.6.5? It shows on both. The Anomaly I saw may have been Win8 only and morphed for Win10? I'll have Win10 here soon enough.

Can TeensyLoader ID the IDE version in use? If that was in verbose and/or About it might help

defragster
08-20-2015, 04:58 AM
Just pushed my Win7 Laptop to WIN10 - IDE 1.56.5r2 was there as was TeensyL 1.24.
<NOTE: No general issues on compile or upload>

I see the same p#34 Win10 behavior - an open IDE_SerMon goes offline on unplug.
> Replug T3.1 powers up running, but USB IDE_SerMon not re-stablished!
> Click IDE_SerMon button and a second window opens live on the sketch in progress.
:: Close IDE and both SerMon's close

This machine has IDE 1.6.3 and it shows the same NET behavior - the SerMon goes offline and orphaned.
> Click the SerMon icon and the same window is then used to re-attach to sketch in progress.

In BOTH IDE cases the SerMon comes back to same USB COM25, but doesn't get routed to the datastream in progress with Windows 10.

TYQT works fine to reconnect on T_3.1 repowering and UI ICON to trigger bootloader upload.