Arduino 1.6.0 - any plans to support it?

[PaulStoffregen]

Down in the status window I received the message:
WARNING: Spurious .git folder in 'Bridge' library.

Oh, yeah, I saw that too. I'll fix it on the next build. It's a harmless warning, so just ignore it.

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?

Just try anything you might think of trying. I've already done quite a lot of testing, so it's best if I don't influence what you try. Best if you just use it like you'd normally use Arduino (not necessarily the same way I use it) and watch for anything that seems wrong.

Would be great if you did something about those robot libraries!

I did. They're still present and still might cause trouble. I only tested with IRremote, which now works with the Robot libs present.

If you know of other libraries getting messed up by the robot stuff, please give them a try.

 

[Jantje]

I tried to compile teensy3.1 sketch on my system (red hat enterprise 6.4). Compiled fine. I have no hardware at hand right now so no further tests.
In my setup i can not select a servo example in the arduino IDE.
I also tried to compile in my plugin a servo example and I found build.core.path to be a unknow environment variable. Which made the linker to fail.
Adding the definition below to the boards.txt fixed it

teensy31.build.core.path={runtime.platform.path}/cores/teensy3/

Did you add this to the arduino IDE or it this a default but yet unused env var?
Best regards
jantje

 

[PaulStoffregen]

In my setup i can not select a servo example in the arduino IDE.

Opps, several of the libraries were incomplete. I'm fixing that and other issues right now.....

 

[PaulStoffregen]

Here's an updated copy, with complete libraries & the Teensy-LC linker problem fixed.

Edit: link removed. Please use the newer copy on message #35.

In Help > About, you should see "exerimental2" in the version, when running this copy.

 

[PaulStoffregen]

I also tried to compile in my plugin a servo example and I found build.core.path to be a unknow environment variable.

Arduino 1.6.0 defines "build.core.path" automatically. The code is in arduino-core/src/processing/app/debug/Compiler.java at line 475:

https://github.com/arduino/Arduino/...e/src/processing/app/debug/Compiler.java#L475

They don't really document this stuff anywhere, other than the IDE's source code.

For your Eclipse plugin to be compatible with any platform.txt files, you'll probably need to automatically create these:

build.path
build.project_name
build.arch
build.core
build.core.path
build.system.path
build.variant.path

Yeah, it'd be nice if they could document this stuff well....

 

[PaulStoffregen]

Jantje, if those undocumented automatically generated prefs aren't already frustrating enough.... I'm going to add one more in my next update. I know this stuff creates even more work for you on your plugin. Hopefully a little advance notice from me at least helps a little?

In Arduino 1.0.6, I had this in my boards.txt:

teensy31.build.time_t=true

This triggers some code I added in the IDE which defines a TIME_T variable with the time the compiler was actually run. My startup code uses it to automatically initialize the RTC. Here's the actual code:

https://github.com/PaulStoffregen/cores/blob/master/teensy3/mk20dx128.c#L698

The idea is to make the RTC "just work". When someone adds the 32 kHz crystal to a Teensy 3.1, it gets automatically set to the time when they last uploaded code. The idea is for the RTC to automatically come up with the correct time.

Even this isn't quite right, because it doesn't detect the difference between a cold boot and reboot due to reprogramming. The time tends to be off by minutes or even hours, since it gets set to the time they last compiled code, which as before they turned off the power to solder on the crystal. That's on my long-term, low-priority list of stuff to improve someday, to detect prior unconfigured RTC after a warm reboot.

Arduino 1.6.0 has more compile speedup, to avoid rebuilding core.a. That's a really nice feature. So for 1.6.0, I'm going to change how I do this stuff. Instead of passing it as a -DTIME_T=#### when compiling code, and a hack to always recompile mk20dx128.c, for 1.6.0 I'm going to pass it as an extra parameter to the linker. That will allow core.a to remain untouched, so the recompile is faster.

But it does mean my next change to platform.txt is going to add something like --defsym=RTC_TIME_T={$build.time_t} into the linker flags. Of course this is totally non-standard, and adding on top of a big pile of already-undocumented features. I can totally understand if you don't want to support this with your plugin. Hopefully at least this explanation helps?

 

[Wraithan]

Any chance for an OSX build of the beta? Would love to give it a shot.

 

[PaulStoffregen]

Mac, Windows and Linux 32 bit will be here within a couple days.

 

[PaulStoffregen]

Here's another updated copy, with USB Type error messages and Teensy 2.0 Disk(internal) fixed.

EDIT: link remove - please use the newer code on message #46.

In Help > About, you should see "exerimental3" in the version, when running this copy.

Unless anyone discovers a horrible bug, this will probably be the last Linux-only experimental copy. I believe all the IDE stuff is from 1.21-test4 is now ported over and working, so I'm now going to turn my attention to the installer and supporting Mac and Windows.

 

[KurtE]

Side question: Not sure if this a linux thing or a Arduino 1.0.6 to Arduino 1.6 difference. But hit me when trying out 1.6 with Teensyduino on Linux

Before (currently) my code (.ino file) has the include statement:
#include <avr\pgmspace.h>

Which has compiled fine on windows machines for a long time: I thought I had compiled these before on linux as well... But now on linux does not.
Luckily it appears like:
#include <avr/pgmspace.h> compiles in either case on windows and linux...

Was I just lucky before?

 

[Jantje]

Hi Paul
I have an issue with the latest version. It works fine in the Arduino IDE but in my eclipse plugin with the fix to the boards.txt I get the following output

19:08:05 **** Incremental Build of configuration Release for project test1 ****
make all
Building file: ../.ino.cpp
Starting C++ compile
"/home/jan/programs/teensy/arduino-1.6.0/hardware/tools/arm/bin/arm-none-eabi-g++" -c -g -Os -Wall -ffunction-sections -fdata-sections -MMD -nostdlib -fno-exceptions -felide-constructors -std=gnu++0x -fno-rtti -mthumb -mcpu=cortex-m4 -D__MK20DX256__ -DTEENSYDUINO=121 -DARDUINO=160 -DF_CPU=48000000 -DARDUINO_ARCH_AVR -DUSB_DISABLED -DLAYOUT_GERMAN -I"/home/jan/programs/teensy/arduino-1.6.0/hardware/teensy/avr/cores/teensy3" -I"/home/jan/programs/teensy/arduino-1.6.0/hardware/teensy/avr/libraries/Servo" -MMD -MP -MF".ino.cpp.d" -MT".ino.cpp.o" -D__IN_ECLIPSE__=1 -x c++ "../.ino.cpp" -o ".ino.cpp.o" -Wall
Finished building: ../.ino.cpp

Starting combiner
"/home/jan/programs/teensy/arduino-1.6.0/hardware/tools/arm/bin/arm-none-eabi-gcc" -Os -Wl,--gc-sections,--relax,--defsym=__rtc_localtime= --specs=nano.specs -T/home/jan/programs/teensy/arduino-1.6.0/hardware/teensy/avr/cores/teensy3/mk20dx256.ld -mthumb -mcpu=cortex-m4 -o "/home/jan/workspaces/arduino/teensytest/test1/Release/test1.elf" ./.ino.cpp.o ./Libraries/Servo/Servo.cpp.o /home/jan/workspaces/arduino/teensytest/test1/Release/arduino.ar "/home/jan/workspaces/arduino/teensytest/test1/Release/arduino.ar" "-L/home/jan/workspaces/arduino/teensytest/test1/Release" -larm_cortexM4l_math -lm
/home/jan/programs/teensy/arduino-1.6.0/hardware/tools/arm/bin/../lib/gcc/arm-none-eabi/4.8.4/../../../../arm-none-eabi/bin/ld:--defsym:1: syntax error
collect2: error: ld returned 1 exit status
make: *** [test1.elf] Error 1

19:08:05 Build Finished (took 281ms)

I noticed the archive is in the command twice. Not sure why it is twice there. I tried on the command line with only one archive file but it resulted in the same problem.
The output is not really verbose and google didn't enlighten me.

I hope you have a clue what is up.
Jantje

 

[PaulStoffregen]

Yup, I know what's wrong. You're not going to like this.....

I added another property into the IDE. Actually, 4 of them, but only 1 is being used so far. If you want to support Teensy (with the platform.txt file I'm publishing), you're going to have to add this to your code, or at least a simple workaround to recognize it and fill in dummy data.

The 4 new properties are:

{extra.time.utc}
{extra.time.local}
{extra.time.zone}
{extra.time.dst}

Probably the simplest workaround would to be simply replace these with the number 0.

If you want to actually support these with proper time values, it's easy with Java. Here's the code:

    // Build Time
    Date d = new Date();
    GregorianCalendar cal = new GregorianCalendar();
    long current = d.getTime()/1000;
    long timezone = cal.get(cal.ZONE_OFFSET)/1000;
    long daylight = cal.get(cal.DST_OFFSET)/1000;
    p.put("extra.time.utc", Long.toString(current));
    p.put("extra.time.local", Long.toString(current + timezone + daylight));
    p.put("extra.time.zone", Long.toString(timezone));
    p.put("extra.time.dst", Long.toString(daylight));

 

[Jantje]

Hi Paul
I got it. If I put ,--defsym=__rtc_localtime=1423939866 it works.
So it must be related to the

teensy31.build.time_t=true

mentioned above.
I have been reading the RTC stuff a couple of times but i fail to understand some of it.
I don't quite understand why you set a value to true in the boards.txt to have special code to deliver a define ....
Wouldn't it be lots easier to have a menu to select between autoRTC initialization on or off? and have the rest of it fixed in the command line like the verbose stuff?
the only hard part i can think of is to have the same date format generated on all OS'es from command line
But for that we could have the IDE create an environment variable (eclipse has current_date in yyyyMMdd_HHmm format).
Tell me what you think.
Best regards
jantje

 

[PaulStoffregen]

These time numbers are needed to support a feature that tries to set the RTC automatically to the correct time. Currently that feature isn't working perfectly, but I will eventually find a way to make it work really well. Eventually PJRC will have at least another board with an RTC crystal, and I really want this to work nicely, so this is an important feature.

In Arduino 1.0.x, I did this with a terrible kludge. I had code which added -DTIME_T=#### in the flags when compiling .c files. This also required adding a kludge to always recompile mk20dx128.c, which is the file using that symbol.

Arduino 1.6.0 has an additional speedup, to avoid rebuilding core.a. It's really nice, and honestly, it's the only noticeable thing 1.6.0 offers for people using Teensy (other than the convenience of using the same IDE if also using Arduino's newer products). Because of this really nice speedup, I decided to abandon my old kludgey way.

Instead, I'm passing the build time directly into the linker, using the linker's --defsym option. This allows the code actually using the compile time number to not need to be recompiled. Then core.a remains the same, so Arduino 1.6.0's speedup works as intended.

 

[PaulStoffregen]

I don't quite understand why you set a value to true in the boards.txt to have special code to deliver a define ....

Opps, that's just leftover kruft from 1.0.6. I'll delete it before the next beta.

Wouldn't it be lots easier to have a menu to select between autoRTC initialization on or off?

I suppose that depends on your opinion of "easier".

My goal is almost always to make things work as automatically as possible. I believe the hallmark of quality infrastructure is people don't even know it's there, making things "just work" automatically for them. I often fall far short of that goal, but still, that's my design goal.

The last thing I want to do is add GUI elements for a feature that can "just work" automatically.

the only hard part i can think of is to have the same date format generated on all OS'es from command line

The format is a simple number, a long integer that is the number of seconds elapsed since 1970. In Java, you can use Date getTime(). See the code I put in msg #38. In C & C++, the standard library time() function gives you this number. In Python, it's time.time(). Virtually every widely used programming language has this feature.

 

[Jantje]

EDIT post crossed. answered above

Hi Paul
I get all that. But I do not understand why

teensy31.build.time_t=true

Is necessary. If you want a switch to turn it on or off a menu is far easier and does not need special code.

I do not have a problem creating the extra environment variables. I'm actually very interested in this because I use __DATE__ and __TIME__ preprocessors and I have the same "rebuild" issue.

Best regards
jantje

 

[Jantje]

Hi Paul
Added the extra environment variables and it seems to work like a charm. I'll check it in so its available from tomorrow onwards.
the time is board selection time for now. I need a think on a better place.
I still need a fix for the 2 servo libs. Now I have them 2 times in my list and the "good" on is below the "bad" one. the user must be "smart enough" to select the good one but has no hints as to which one that is.
Best regards
jantje

 

[PaulStoffregen]

Here's the code to actually access the time number, if you want to try using it in a sketch.

extern "C" void *__rtc_localtime;

void loop() {
  Serial.print((int)&__rtc_localtime);
  delay(150);
}

 

[jakorten]

Any chance for an OSX build of the beta? Would love to give it a shot.

Me too, so beta testers available

 

[PaulStoffregen]

Here is the first beta test to support Arduino 1.6.0.


EDIT: Links removed. Please use the newer version on message #73.


On Macintosh, these installers almost certainly interfere with Arduino's app signing. Please let me know which version of MacOS you're using, which of the 2 copies of Arduino 1.6.0 you have, and what type of warnings or errors you get when trying to launch Arduino after running the installer.

EDIT:
On Windows, 1.21-beta5 has a bug where the serial port becomes unresponsive after uploading with the serial monitor window still open. See msg #51 for details.

The pde.jar file above has a patch to work around this issue. After installing Teensyduino, replace the pde.jar inside the "lib" directory. It should fix this problem.

EDIT Again:
If you get an error that "mk20dx256.ld" or "mk20dx128.ld" or "mkl26dx64.ld" could not be found, please try this boards.txt fix.


Please let me know if you discover any other bugs?!

 

[defragster]

Me too - ready for Windows, Got 3 Teensy 3.1 units last fall and just unwrapped one and it blinks. Some time with IDE on AVR. Ready to start my real project. (announce went up during my post - downloading now)

Win8_32: Downloaded & installed 1.6 and TinyDuino, edited and uploaded blink, uploaded SerialMonitor : No issues, defaulted to 96MHz OC
ATOM Tablet - performance usable like on 1.0 and 1.5.8 before
Comment in blink could read: // Teensy 3.x has the LED on pin 13

 

[mischnic]

MacOS: 10.10.2
If I open the Arduino.app once and then install Teensyduino, it doens't give any message.
If I install Teensyduino first and then open the Arduino.app, I get an error: "Arduino.app is damaged and can't be opened. You should move it to the Trash."
This applies to both Arduino version (java 6 & 7).
Otherwise, both versions work (upload Blink).

It isn't caused by you, but the java7 version doesn't do antialiasing on the UI & console/log, only on the editor!

 

[jakorten]

My OS X version seems to have to problems at al. 10.10.3 / Arduino 1.6.0. I don't like the new Arduino 1.6.0 on Mac though, it overrides the normal OS X open/save Windows with a crappy Java version. I didn't get any errors on OS X but have changed the security options in the past of course to be able to install non-signed applications.

 

[defragster]

Win7_64: installed 1.6 and TinyDuino, edited and uploaded blink, uploaded SerialMonitor : No issues, defaulted to 96MHz OC
--> Had to remember to 'Run as Admin' on TeensyDuino for install to work.
Win7&8:: The TeensyDuino 'Press Button To Activate' splash is confusing. It is in Auto and I never need to touch the button.

IDE has awful treatment of Windows 'Alt' menu shortcuts - no change. Mostly learned to stop typing 'fs' in my code when the 'Alt' is ignored, of course Ctrl+S does a save but it has been nearly 30 years now.

 

[PaulStoffregen]

I'm working on the Windows serial monitor problem, where uploading while the serial monitor is still open causes serial to not work after Teensy reboots.

Looks like my code that tries to reopen the serial port is running too soon and too fast. It was never an issue on Arduino 1.0.6, but 1.6.0 does some things faster, and I rewrote the code in the process of porting, which probably also changed the speed.

Now it's so fast that it manages to reopen the serial device right before Teensy reboots into bootloader mode. The USB disconnects with the serial device open. It works fine on Linux and Mac, because those systems have high quality drivers. But it fails on Windows, due to this Windows driver bug: https://www.youtube.com/watch?v=DRmvUsa2xuU

In an ideal case, I'd redesign teensy_post_compile to communicate more with Teensy Loader, and get that status back into Arduino, so the IDE could wait until the reprogramming is complete. I probably will do that someday... but it's going on the long-term, low-priority list.

For now, it seems just adding a delay before the serial monitor begins trying to automatically reopen the port should work ok.