Teensy-LC Beta Testing

AFAIK, Arduino 1.6.1 was just released today (March 10th). Since Paul has to reverse-engineer the Arduino files and code layout to install his Teensyduino patches to it, I don't think that happens on the same day or anything even close; I think he's been a little busy with 1.6.0 and Teensy LC just recently :)

However it seems there is some good news with 1.6.1...
https://github.com/arduino/Arduino/blob/master/build/shared/revisions.txt

* Fixed: status board was not changing when using custom menu @PaulStoffregen
* Improved library name matching @PaulStoffregen. Avoids conflicts with libraries that bundle files equally named
 
Last edited:
Well, I didn't see that coming! They just released 1.6.1 just within the last few hours.

I had asked several times only recently what their schedule was, and they refused to say.

I'll get another beta put together with 1.6.1 support today.
 
Recent Teensyduino installs have a boards.txt file with, I think, this typo:

teensyLC.build.flags.c=
nothing to the right of the =
This makes GCC error out as the curly-braces don't get string-replaced and wind up on the command line.

And these typos?

teensyLC.menu.speed.48opt.build.flags.ldspecs=
C.menu.speed.48opt.build.flags.optimize=-O
teensyLC.menu.speed.24opt.build.flags.optimize=-O
teensyLC.menu.speed.24opt.build.flags.ldspecs=


Also, it makes more sense for the optimizer level to be a project property, not a board property.
 
Last edited:
Fresh install of Arduino 1.61 (zipfile) and Teensyduino 1.21-beta10 on Windows 7 Pro 64bit without issue.

Secondary menus are still resetting to the first menu item rather than the previous value. For example choose LC, set USB type to usbMIDI and keyboard to UK English. Now select Teensy 3.1 and usbType gets set to Serial, keyboard to US English as these are the first ones.

In the Port menu besiges the usual "COMn" there is also a "Serial ports" entry which I don't recall seeing before. (Its not in Arduino 1.60+TD1.21-beta9).
 
stevech said:
teensyLC.build.flags.c=
nothing to the right of the =
This makes GCC error out as the curly-braces don't get string-replaced and wind up on the command line.
Click to expand...

Are you seeing an error in Arduino, or in Visual Micro?

I tested this with Arduino 1.6.0 and 1.6.1 on Linux, Mac and Windows. I never saw any errors.

And these typos?
Click to expand...

Not a typo. When normal (speed optimized) newlib is needed, the optional specs parameter needs to be omitted.

An empty parameter is allowed by Arduino. It's only empty in some cases, but populated in others. Without the empty cases, Arduino will pass "{build.flags.ldspecs}" to the compiler, rather than replacing it with the empty string.

My guess is you're seeing the error in Visual Micro, which might not handle the empty case (or custom menus) the same way as Arduino?
 
Nantonos said:
Secondary menus are still resetting to the first menu item rather than the previous value.
Click to expand...

Yeah, that's a "feature" of 1.6.x.

The custom menus are one of the oldest and largest Arduino contributions I tried to make back in the days of David Mellis as Arduino's technical lead. As Arduino 1.0.x kept developing, separately maintaining that huge patch set became quite a chore. I'm really glad Cristian merged it into the newer code base. So far, I've been reluctant to go fiddling with it much, partly because Teensy-LC has kept me busy, partly because they built a lot of abstraction classes around stuff, and partly because I'm not eager to return to the days of reworking such a large patch set for each new Arduino version.

But yeah, losing the setting is annoying. Eventually I'll look into this, but it involves possible breakage of other stuff they've done, so it has to be carefully considered. I'm also hoping to keep my patch set smaller....
 
PaulStoffregen said:
Are you seeing an error in Arduino, or in Visual Micro?

I tested this with Arduino 1.6.0 and 1.6.1 on Linux, Mac and Windows. I never saw any errors.



Not a typo. When normal (speed optimized) newlib is needed, the optional specs parameter needs to be omitted.

An empty parameter is allowed by Arduino. It's only empty in some cases, but populated in others. Without the empty cases, Arduino will pass "{build.flags.ldspecs}" to the compiler, rather than replacing it with the empty string.

My guess is you're seeing the error in Visual Micro, which might not handle the empty case (or custom menus) the same way as Arduino?
Click to expand...
Errors only with Visual Micro + Visual Studio 2013 Community (free).
No errors with Arduino 1.6.1
 
Teensy-LC will start shipping this afternoon.

Final 1.21 release is planned for tomorrow. I might let it slip into the weekend, but I absolutely intend to finalize 1.21 no later than Sunday night!

Many of the minor libraries, and some stuff like Wire library slave mode, will have to wait until 1.22.

Right now, the only "show stopper" bug is failure to recognize the Arduino 1.6.1 Windows installer files (which are different from Arduino's ZIP version). Does anyone else know of anything that really *must* get fixed? We're in the final hours now....
 
Not a "must" but many of us use VisualMicro with Visual Studio - and there's a minor problem where GCC command line options don't process properly and stay as words in curly braces.
It used to be that VS/VM worked verbatim with the same files that Arduino uses. But now apparently some change in VS/VM is needed and Tim doesn't yet know what.
 
I exchanged a couple emails with Tim. He's aware of the issue. I can't speak for when he'll look into this, or what he'll do. But I'm pretty sure he's going to wait until after the final 1.21 release. I know that doesn't help you immediately, but at least it can help set your time-frame expectations reasonably.
 
stevech said:
Not a "must" but many of us use VisualMicro with Visual Studio - and there's a minor problem where GCC command line options don't process properly and stay as words in curly braces.
It used to be that VS/VM worked verbatim with the same files that Arduino uses. But now apparently some change in VS/VM is needed and Tim doesn't yet know what.
Click to expand...
Until the problem is fixed in Visual Micro you could hack around the problem by putting harmless flags in the empty variables in boards.txt, such as -Wall. If I understand the problem correctly.
 
Got LC Ship email from Robin 30 minutes ago!

Koromix - can you try for working boards.txt edits? I tried to install Visual Micro and it didn't work for t3.1 and I 'bug'ged Tim back then and bailed on it. I'll be looking to try it.
 
Hi defragster,

You should probably put this on another (maybe new) thread as this library currently does not even run on the Teensy-LC. These sounds like nice enhancements for maybe the next release of Teensyduino. My guess is at this late stage Paul will only be putting in show stopper like fixes into the current release (that is I believe planned for tomorrow).
 
Thanks Kurt - wrong thread indeed . . . . . . I thought ILI9341 LC was working - just not optimal ...

All is well Withdrew my posts - failure to blink was from fast drawChar() clip return causing no SPI I/O it seems. Was rewriting and my tests went "even to odd" so the blink pulsed ON not OFF.

Y does grow unbounded - but silently - until it wraps after 40,000 calls.
 
Last edited:
Yup, only a few major bug fixes are planned for the final release. Everything else will go into 1.22.

Historically, I've tried to release a new Teensyduino every 3 to 4 months. 1.20 to 1.21 was 5 months, mostly due to developing Teensy-LC.

It seems likely the Arduino developers are going to step up their release pace, probably in response to the Arduino cc vs org drama. They've already talked about 1.6.2 and 1.6.3 plans on a couple github issue conversations.

I have a LOT of stuff planned for future releases.....
 
Well if the drama prods them into a better / faster upgrade cycle, I'm all for it.

FWIW, I'm working on a pin out Eagle library for the Teensy LC as well as the chip itself. The new boot loader chip and connection requirements are still a bit of a mystery to me so nothing will get released until the schematic is published.

At first glance, it looks like a number of the pins on the MCU have gone unused and a new programming method is being used.
 
I'll work on the schematic after the final 1.21 is released. It should happen sometime next week.

A few pins are unused on the KL26 chip.

The programming method is basically the same as Teensy 3.1. Really, there aren't going to be any big surprises in the schematic.
 
Koromix said:
Until the problem is fixed in Visual Micro you could hack around the problem by putting harmless flags in the empty variables in boards.txt, such as -Wall. If I understand the problem correctly.
Click to expand...
the problem is that the name within the curly braces and the curly braces themselves get put into the GCC command line. Did you mean I should find that item and change it to something benign? Because an unexpected name causes the problem I describe? There are no errors like "invalid parameter" - just the GCC command line parser error.
 
Steve, you should wait until 1.21 is officially released. Maybe even a day or two after. Then bring this up on the Visual Micro forum again.

But until then, please give this a rest. Find some workaround, like temporarily editing those files, if you must. Bringing this up over and over again between now and then is going going to drain Tim's enthusiasm for supporting Teensyduino.

Tim does excellent work and I'm sure he'll fix this. Please don't keep pestering him needlessly. He's said clearly he intends to look into this after 1.21 is finalized.
 
You must log in or register to reply here.
Back
Top