Arduino 1.6.0 - any plans to support it?

Status
Not open for further replies.
D

davidhaile

Member
Moderator Edit: Arduino 1.6.0 and 1.6.1 are now officially supported by Teensyduino 1.21.


I'll be backing out the upgrade I just did to move the IDE from 1.0.6 to 1.6.0. The Teensyduino that I have does not support 1.6.0. I'm avoiding responsibility by not digging into the problem. Maybe someone else can back me up or tell me I'm wrong?
 
Search the forum... lots of discussions for many months on waiting for post-beta Arduino then other issues related to 1.6.
 
Yeah, I'll get on 1.6.0 within the next week or two.

They "refactored" a lot of stuff, which mostly involved moving code around. I've been looking at 1.5.x more recently, but it's still going to take me some work to find where they put some stuff....

Fortunately, the Teensy-LC beta testing is going pretty well now, so the timing isn't as bad as it could have been.
 
Thanks Paul for the good news. I am sure I can live for a while with two Arduino IDEs on my hard disk ;)

Ah well, the joy of figuring out the Forum's search engine. I can't even find the thread I just started when I search for "1.6".
So I am sorry for my duplicate question!
 
I'm working with 1.6.0 now. It's going to take me a while to get this supported. Some of the new stuff, like the menus in Tools is stuff I wrote and contributed years ago, and the new platform.txt means I don't need a variety of (fairly simple) hacks in the java code. Long term, I think 1.6.0 is going to be easier...

It also seems to have startup issues on my machine, where it just seems to hang forever without displaying anything. Is anyone else seeing that? I'm using Ubuntu 12.04, 64 bit.
 
Hi Paul,

Saw your posting on the email list on the hang. I have just installed it on my Intel NUC running Ubuntu 14.04. I also had to install openjdk-7-jre, as I recently had problems on this machine and did a complete clean install of linux.

I have started the IDE with ./arduino 20 times now with no hang. Personally I think your name should be included in the supported by list as well as the Teensy show up under their hardware page, but I know I am a little off topic. But thanks for your contributions!

Kurt
 
PaulStoffregen said:
It also seems to have startup issues on my machine, where it just seems to hang forever without displaying anything. Is anyone else seeing that? I'm using Ubuntu 12.04, 64 bit.
Click to expand...

I'm getting that on the Teensy-LC beta, on windows 7 Pro 64 bit. Possibly unrelated. Possibly also resolved by updating my java. I'm pretty up to date though! I use tridium for work which is java based so I'm rarely far behind the curve.
I don't use arduino IDE for my projects, only for the beta testing so i assumed this was par for the course?
 
I fiddled with boards.txt and platform.txt today. It's now able to compile and almost work with Teensy Loader.... almost.

A lot of the java patches I've maintained over the last few years have found their way into 1.6.0, but others haven't. It'll probably take me a couple days to get the java side going, since they moved pretty much all the code around.

I hope to have something for initial Teensy-on-1.6.0 testing by this weekend.
 
Good news: I'm making progress with 1.6.0. I've got it building sketches for Teensy 3.1 and 2.0, with default settings (USB Serial, fastest clock speed, US keyboard layout). From here, the other settings should be fairly easy.

Two large tasks remaining to be done are porting the serial monitor changes, so Serial.print() works in Teensy's non-serial modes, and changes in the installer to cope with 1.6.0's different structure, and dual java personality on Macintosh.

For anyone eager to try Teensy on 1.6.0, please subscribe to this thread. I hope to have an initial test version within the next couple days.
 
Just another 'me too' post. I foolishly installed 1.6, which happily uninstalled my already-working installation. ;( I look forward to the beta for 1.6.

Thanks for all the hard work, Paul.
 
Hi paul
One of the things I found I could not handle in the boards.txt is that teensy 3.1 does not use an archive. I'm not sure how you worked around this but I fixed it by adding a keyword.
teensy31.build.use_archiver=false
by setting build.use_archiver default on true there is no impact on other arduino boards.
I'm willing to test and help out as I want this to work in my eclipse plugin :)
I guess you started from the boards.txt and platfor.txt from headroom.
Jantje
 
Here's another quick update on 1.6.0 support:

Over the last couple days I've managed to port most of Teensyduino's java edits. It's been slow-going, since I haven't worked much with the new code base until now. They restructured all the platforms/core/board stuff, from Java Maps to many Java objects, which are just thin wrappers around Maps. Some much new "abstraction" stuff adds a lot of questions like: "WTF is a TargetPlatform object.... better go find its file and read its API". It's mostly the same old code as 1.0.x, but pretty much everything has moved around. Or I guess it's called "refactored".

Today I got the serial monitor working with Teensy's non-serial modes, which is by far the largest and most complex of Teensyduino's mods to the IDE's java code. About half of the small stuff is ported. I'm pretty sure I'll finish the java stuff in another day or two.

If the installer doesn't go quickly, I'll post a test copy that's the entire IDE with Teensyduino already added. Dealing with the fact that java stuff is now in 2 JAR archives will take a little work. I also need to look more carefully at what they really did for the 2 different mac versions. It looks like the same stuff in a different bundle layout, but maybe there's other fine details?


@Jantje - Actually, I just started from scratch on platform.txt on Monday. By the time I remembered you had worked on this, it was already pretty much done. Since then, the toolchain has been upgraded, so the problems preventing using archive usage have long been fixed. Teensyduino hasn't used linking of all .o files for quite some time.

As I worked on platform.txt on Monday, I decided to do it somewhat differently than the Arduino devs envisioned. I'm putting all Teensy stuff under a single architecture directory, for 3 reasons:

  • All the Teensy boards group together in the Tools > Boards menu
  • The Teensyduino installer and all my library stuff is designed to install to one location
  • I believe many people will publish libraries only for the "avr" platform, even if they're generic

Fortunately, this is pretty easy to do. Instead of defining the compiler commands and flags in platform.txt, I just created entries in boards.txt. I rewrote all the platform.txt recipes to get commands, flags and other details from boards.txt. Then I only need 1 directory, 1 boards.txt and 1 platform.txt file for all Teensy stuff.

Later today, I'm going to take a little break from the 1.6.0 stuff, to catch up on answering forum threads. I've fallen behind the last few days while working with 1.6.0....
 
@ paul
As I worked on platform.txt on Monday, I decided to do it somewhat differently than the Arduino devs envisioned. I'm putting all Teensy stuff under a single architecture directory, for 3 reasons:
Click to expand...
That is as you had stated a long time ago and as we did. So unfortunately you are redoing what we did :-(
Looks like it will be quick though :-D so nothing bad happened. And it will help your understanding :)
Keep us posted
Jantje
 
Och now I think of it. The servo library has caused me some pain.
I ended up making a teensy folder and copying the servo folder of teensyduino in the teensy folder.
Then I extended the existing #ifdef structure in the servo.h file of arduino IDE to point to servo.h of teensyduino(but that should have a different name to avoid having 2 servo.h files) and excluding all other code in servo.h if it is a teensy compile.
Not the nicest solution but it worked.

PS don't forget to change your ifdef header include guards from
#ifndef Servo_h
#define Servo_h
Click to expand...
to something like
#ifndef teensy_Servo_h
#define teensy_Servo_h
Click to expand...
as Servo_h is already defined in the Servo.h file delivered by arduino IDE
 
Last edited:
Paul,
I ported the 1284 code and libraries over to the 1.5x IDE quite a while back and figured out quite a few things in the process.
I'm curious. Where are you placing your core? (The 1.x teensy cores IMHO were installed in slightly the wrong place)
Looking forward, I think things can be easier with 1.5x/1.6x if you place the cores down under
the users {sketchbook}/hardware/(vendor)/(arch-core-name) directory.

I know you said you were doing things differently with respect to architectures but consider this:

You can have a "libraries" sub directory under the arch-core directory that can be populated with libraries that can be used to override any IDE supplied libraries.
This insures that the libraries supplied with a core only have to work with that core and don't have don't have to work with all cores or any other core.
For a core supplier I would think that this would be easier than going down the path of the funky "new library" spec of having all these crazy sub directories
for each core architecture in a common "libraries" directory.
Or trying to make a single library that has tons of conditionals to support many different cores.
With a core specific library you can write it for your core and include it with the core and since it only gets used
with that core, it only has support that core and you don't have to worry about all the maintenance nightmares of a common library
or any of the "new library" spec stuff.

For example, you could have a servo or SoftSerial library down under the libraries directory of your core that overrides any
IDE supplied library that only gets used with your core.

I found that the 1.5x hardware/core structure did make things easier for the 1284 core and its modified IDE supplied libraries since
the modified libraries could part of the core install vs having to be individually installed in the users sketchbook libraries area.

I would think being able to do this might be of benefit to your teensyduino package since you can simply create
your own libraries (when necessary) and not have to integrate them with the IDE supplied code.


--- bill
 
Currently, I'm working in hardware/teensy/avr/cores. At some point in the future, I might transition to installing into the sketchbook folder. But today, my installer isn't able to reliably detect the sketchbook folder location. Whether it exists is also an unresolved issue. That's never a problem for installing into the copy of Arduino (or if it is, they can't get the "Next" button to enable because that copy of Arduino fails the validity checks).

I have no plans to ever divide all the files into 2 architecture locations, like hardware/teensy/avr/cores and hardware/teensy/arm/cores.

I am planning to make my installer put all the libraries it installs into hardware/teensy/avr/libraries. This is the one part of the 1.6's new scheme I really like. I've always worried about breaking libraries for normal Arduino boards.
 
Hi paul
About
I am planning to make my installer put all the libraries it installs into hardware/teensy/avr/libraries
Click to expand...
Can you point me to the spec that explains how it should work when Arduino delivers a servo library in .../arduino-1.6.0/libraries/Servo and you in arduino-1.6.0/hardware/teensy/avr/libraries/Servo.
Have you tested it actually works in 1.6?

I have no plans to ever divide all the files into 2 architecture locations, like hardware/teensy/avr/cores and hardware/teensy/arm/cores.
Click to expand...
I fully agree on this one. I think it is a bad decision on behalf of the arduino core team. I mean: "When an artist/beginner buys a due or uno board; does he know the board has an avr processor or a arm processor? Does he care about which processor is on the board? Doesn't it make 'finding the board' more complex?"
So yes, pleas stick to 1 "architecture folder name".

If you plan to call the folder avr; I would like you to reconsider. Think about the people who do know about avr/sam. For them it will be confusing to find a arm board under the avr section (be it in the gui or folder structure). I named the folder "all'. Not that I think it is "a very good name" but it is "the best I could come up with"

Best regards
Jantje
 
Last edited:
Jantje said:
Can you point me to the spec that explains how it should work when Arduino delivers a servo library in .../arduino-1.6.0/libraries/Servo and you in arduino-1.6.0/hardware/teensy/avr/libraries/Servo.
Click to expand...

No, I am not aware of any written spec, other than details buried deep within the IDE source code. The 1.5 library spec does mention the sketchbook, but doesn't seem to mention of alternate install locations and their prioritization.

Have you tested it actually works in 1.6?
Click to expand...

Yes, I have tested. It seems to work well, using the one from the "hardware/package/arch/libraries" folder in preference to the one from just "libraries".

I haven't tested scenarios where the same name is also present in "sketchbook/libraries" or "sketchbook/hardware/package/arch/libraries".

I also have not yet tested how well the name matching from headers to folder names works... but that's next on my list. If necessary, I'll patch the code. I'm never going back to having those robot libraries break stuff!

If you plan to call the folder avr; I would like you to reconsider.
Click to expand...

I am indeed going to do exactly that.

Think about the people who do know about avr/sam. For them it will be confusing to find a arm board under the avr section (be it in the gui or folder structure).
Click to expand...

If they go looking around inside the arduino folder (or app bundle on a Mac), they're just going to have to deal with it.

I provide an easy-to-use GUI based installer, so novices don't need to worry about where to unzip stuff or the internal structure inside the arduino folder. I put a lot of work in testing nearly every library, so everything "just works". That's what I do for people who don't want to dig into details.

I named the folder "all'. Not that I think it is "a very good name" but it is "the best I could come up with"
Click to expand...

Really, this depends on your criteria for "very good".

If your main goal is to choose a descriptive name for people looking at the directory tree in Windows Explorer or Macintosh Finder, then "all" is probably pretty good.

For Teensy, my main goal is to make as many sketches and libraries found on the internet "just work". Only 1 name will avoid the compatibility warnings when compiling with libraries that follow the new spec and copy the example properties file with "architectures=avr".
 
Yup, looks like Arduino 1.6.0 _still_ has the robot libraries mess up IRremote bug!

One more java patch I have to bring over from 1.0.6.....
 
Here is a first experimental copy of Arduino 1.6.0 with Teensyduino 1.21-test4 added.

EDIT: link removed, please get the fixed copy in msg #30.

There are a few known problems. The SD(internal) stuff for Teensy 2.0 will not work. Automatic setting of the Teensy 3.x RTC, if the 32 kHz crystal is present and the time was not previous set, will be wrong. Error messages about undefined names when the wrong USB Type will not have the extra text suggesting to use the Tools > USB Type menu.

Of course, it's quite possible other stuff is broken. I've done quite a bit of testing, but many cases are still untested.

I still have a lot of work to do on the installer. That's why this is a whole (huge) copy of Arduino 1.6.0 with everything set up. I plan to work on the installer over the next couple days. That will also lead to the other versions for Mac, Windows and Linux 32 bit.

If you give this a try, please let me know what you tested and what does and doesn't work for you?
 
Last edited:
Hi Paul, I downloaded to my Ubuntu 14.04 machine (Intel Nuc), I have not tried much, but the Teensy's are showing up in the board menu.

When I selected Teensy LC;
Down in the status window I received the message:
WARNING: Spurious .git folder in 'Bridge' library.

I will try out some more and see if my stuff compiles and run a few apps. Would you prefer us to try out TC more here or on normal 1.0.6 are split?

Would be great if you did something about those robot libraries! I know it even screws up Edison builds, but they are still on 1.5.3....

Again great stuff.
 
board type lc does not compile:

Arduino: 1.6.0 (Linux), TD: 1.21-experimental, Board: "Teensy LC, Serial, 48 MHz, US English"

Build options changed, rebuilding all
/home/kurt/Desktop/arduino-1.6.0/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/bin/ld: cannot open linker script file /home/kurt/Desktop/arduino-1.6.0/hardware/teensy/avr/cores/teensy3/mkl26x64.ld: No such file or directory
collect2: error: ld returned 1 exit status
Error compiling.

This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.

simple empty default sketch. builds for 31
 
Status
Not open for further replies.
Back
Top