Arduino 1.6.2 support

Status
Not open for further replies.
defragster said:
KurtE - odd - I don't see a difference in the boards.txt where the obvious changes I know of would have been. I wonder what you see on the 'non-optimized'?
Click to expand...

Note, my previous post update, I meant it to say if I compiled at 49mhz (not optimized), both versions generated the same size (52.832K)
 
Even odder that just the speed would do that - though each speed has a unique line in boards.txt - I keyed on Optimized . . .
 
The not optimized options use "-Os" which optimizes for smaller code size.

Are you sure the size difference wasn't due to one compile with "-O" and the other with "-Os"? It's easy to check by simply turning on verbose info while compiling in File > Preference. Then change options, click Verify, and scroll up and look through the sea of compiler commands for "-O" or "-Os".
 
Sorry, I think this was my error. I has 1.6.1 setup for visual micro and had -Os as part of command line.

On that release choosing optimized versions still gave different results than non optimized board type so I did not notice...

Sorry!

Note looks like 1.6.3 released today. Hopefully later today will be able to download but now net is down
 
Ugh, looks like the Arduino devs again changed the java compiler, back to Java 1.6 for Linux and Windows, and of course not the same minor version within 1.6. Mac is still being built with Java 1.8. I'm adapting my build system, again....
 
I've uploaded another beta version, with support for Arduino 1.6.3. Links are on the original post of this thread.

The EEPROM and FastCRC libraries are updated, and numerous tiny problems that caused harmless but annoying compiler warnings have been fixed.
 
@FrankB
Does FastCRC use the same initial value and polynomial as is used in the Ardino CRC function - so that they'd be interoperable?
 
Paul: Are you going to be able to repair the loss of 'Verify' passing the newly compiled .HEX to TeensyDuino 1.22 for Button Upload?

Downloaded 1.22b3 and installed - downloaded 1.6.3 but not yet installed, still 1.6.1. All seems normal.
( I just powered up an i2c OLED 1306 display and it compiles and works on 3.1 and LC )
 
defragster said:
Paul: Are you going to be able to repair the loss of 'Verify' passing the newly compiled .HEX to TeensyDuino 1.22 for Button Upload?
Click to expand...

Please give this file a try, with 1.6.2 or 1.6.3 and 1.22-beta3. It goes into hardware/teensy/avr.
 

Attachments

  • platform.txt
    3.4 KB · Views: 164
Last edited:
All is ok for me .


I try to compile this code https://github.com/cTn-dev/Phoenix-FlightController that return me this warning !!!
Code: 
In file included from controller.ino:19:0:
C:\Users\pierre\AppData\Local\Temp\build6107189559422887599.tmp\math.h: In function 'float invSqrt(float)':
C:\Users\pierre\AppData\Local\Temp\build6107189559422887599.tmp\math.h:10:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
i = * ( long * ) &y;
^
C:\Users\pierre\AppData\Local\Temp\build6107189559422887599.tmp\math.h:12:24: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
y = * ( float * ) &i;
 
Good Job! Arduino IDE 1.6.3 w/ "10:02:30: Teensy Loader 1.22-beta3, begin program"

Two open IDE's with unique code and Two T_3.1's active on USB (win7).

Perform a "Ctrl + R"/Verify and TeensyDuino 1.22 with the supplied 'platform.txt' replaced and TeensyDuino is updated with the .HEX as Verified. Pressing the Teensy Button then pulls that complied object to that Teensy!

Also worthy of note: If TeensyDuino is NOT active when Verify is selected - the IDE will open TeensyDuino in order to pass it the HEX path as desired. (i.e. IDE just started, or TeensyDuino manually closed)

Also: nothing else broke in testing this.
 
Update on Verify Load Msg #67: I plugged in an LC beside my two 3.1's

Now when I hit 'Verify' TeensyDuino popped up the warning about LC/3.1 conflict:
'11:14:48: Incompatible file, showing warning dialog'

Unplugged LC and then Verify worked, then allowed Button.

I did then open a third sketch and Verified for LC and it uploaded, then returned to 3.1 Verify and those uploaded no problem. At this point it did not repeat but properly switched to allow Verify and Button without problem when the right Teensy.

To that end: Once you push the wrong Button - TeensyDuino won't allow a return to programming the desired device. After LC Button with 3.1 code (oops) - I got the dialog and it FROZE my 3.1 (it halts the 3.1 before popping up the error dialog). Even unplugging the LC doesn't restore. Then unplugging the 3.1 boots the code, but pushing the Button just freezes the 3.1 with no upload and no error dialog until you do another Verify.

Just in case it helps - here is my verbose log: View attachment Verify1.22.txt
 
Yeah, when you've got more than 1 Teensy connected, the Upload from Arduino runs teensy_reboot, which searches for the first Teensy is can find. It don't have any way to know which model each connected device is when it's running an Arduino sketch. So it reboots the first one it can find. If it finds a 3.1 first, that'll get rebooted, even if you compiled for LC.

Teensy Loader does check if the code is compiled for the wrong chip (if it can access the .elf file), so if teensy_reboot found the wrong device, you'll get that dialog and the wrongly rebooted 3.1 will sit there in programming mode.

Clicking Verify should never cause any Teensy to auto-reboot. But if you've already got a Teensy in programming mode, Teensy Loader will try to program it if it's in auto mode. There currently isn't any way for Arduino to inform Teensy Loader of a new file but ask it NOT to try programming. Maybe there should be?

Someday in the distant future, I'm going to make a much more sophisticated Teensy Loader that tracks multiple boards and remembers which ports on your computer (and all the connected USB hubs) have which type of Teensy connected. It will someday track when each reboots quickly... faster than a human can physically move cables, and remember which type of Teensy is running while its running your sketch. The searching currently done by teensy_reboot would be replaced by requests to the Teensy Loader to use its list of devices. But this will quite a lot of work. Each operating system has dramatically different APIs for lower level USB stuff like physical USB controller, hub & port, not to mention this scheme is a completely different approach than the way things are done today.

For now, the system isn't well designed to handle more than one Teensy. Neither is Arduino, really.
 
pierrotm777 said:
Code: 
C:\Users\pierre\AppData\Local\Temp\build6107189559422887599.tmp\math.h: In function 'float invSqrt(float)':
C:\Users\pierre\AppData\Local\Temp\build6107189559422887599.tmp\math.h:10:23: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
Click to expand...

Yup, that's because casting points that way isn't good programming practice. The compiler is right to show that warning for such code.

The proper technique involves using a "union". Here's the same code implemented with a proper union:

https://github.com/PaulStoffregen/FreeIMU/blob/master/libraries/FreeIMU/FreeIMU.cpp#L774

If you have contact info for the author, maybe forward this message? Now that new versions of Arduino show compiler warnings, this way to avoid the warning might help.
 
PaulStoffregen said:
... more than 1 Teensy connected, the Upload ...
Click to expand...
You are right Paul - I wasn't trying to bug bad Upload behavior as the Verify+Button the workaround for that.
You can parse the LOG file better than I - I didn't intend to Upload - just asked for Verify. However I may have previously hit Upload just before the time logged in #68 (but I don't see that)?

Maybe this relates: My past observations seemed to feel the TeensyD Queue's events or goes into a state it doesn't exit - and when then 'provoked' (in this case with a true Verify) it picks up where it left off, not starting fresh?

It would be a great feature for TeensyD to Stack up recent uploads across devices and allow one or more prior uploads to be re-programmed.
 
Last edited:
defragster said:
Maybe this relates: My past observations seemed to feel the TeensyD Queue's events or goes into a state it doesn't exit - and when then 'provoked' (in this case with a true Verify) it picks up where it left off, not starting fresh?
Click to expand...

I have no idea what you're talk about. There may indeed be a bug or confusing behavior, but this doesn't sound like anything it's designed to do.

Creating top-notch GUI software is incredibly difficult. Even when a program "works" perfectly, the better and easier and more intuitive it is to use, the less time and attention people have to give it. Getting the right on-screen indications, at the right moments and for the right lengths of time, turns out to be very tricky.

The honest reality is Teensy Loader is still the first generation GUI, which I made up 6 years ago. I've learned a thing or two since then. But I also made the jump from 8 to 32 bit microcontrollers and wrote some major libraries and did lots of other stuff, which has put a GUI redesign on the far back burner. And I'm starting some new work on an incredibly ambitious project, which I believe a lot of people will really love when it's released. So the original one-board-at-a-time Teensy Loader design is going to have to do for quite a while longer. It's just one of so many things I would do if there were a LOT more hours in every day!
 
IDE and multiple instances: This is probably not a solvable problem - Multiple open IDE's share all details (temp compile dir and PORT and BOARD) - it would be great if each open instance had a unique view of those thing so it wouldn't fight two boards or even recompile all on changing between two 3.1 with different code. The IDE is so interconnected if you have two open and compile in "A"and switch focus to "B" the output from "A" then streams onto "B".

Another limit to using multiple Teensy's is the IDE only allowing a single open Serial Monitor - as it Auto Closes an open PORT when a new one is chosen. This led me to liking TyQt as it can monitor multiple ports and generally works well. I need to try it again now that Verify is working. TyQt can also easily find and track prior HEX files as it has the stored upload feature already.
 
NIURobotics said:
Could there be a simple fix in the EEPROM.h that would allow us to run EEPROM.get on Teensy, or is there maybe a hardware restriction that's accounted for and preventing this?

Any help would be appreciated
Click to expand...

The latest beta (1.22-beta3) updated the EEPROM library.

Can you confirm if it's working for your application?
 
PaulStoffregen said:
I have no idea what you're talk about.
Click to expand...

That makes two of us - and if it doesn't trigger a bell then please go on being productive.

If it persists I'll try to be more clear. Just something that I 'felt' before when context switching the architectures - once TeensyD got off track, pushing even the right button didn't seem to clear it and multiple pushes seemed to queue in some fashion (maybe only in deserved confusion).

The TeensyD detection happening after the unit is Halted leaves the device in an odd state as noted above, repowering the device runs old code so the boot works, but then pushing the 'right' button seems to show TeensyD at a loss for what code it would proceed with.

I was wondering if this is why the 'too much too fast' error was added - assuming it was new - as I would see TeensyD say too many events in too short a time all of a sudden later in 1.21 beta when I got my LC.
 
Status
Not open for further replies.
Back
Top