Teensyduino 1.21 Released

Status
Not open for further replies.

Paul

Administrator
Staff member
Teensyduino 1.21 has been officially released.

http://www.pjrc.com/teensy/td_download.html

Here are the changes since version 1.20:


  • Support for Teensy-LC
  • Support Arduino 1.6.0 and 1.6.1
  • Keep Arduino Serial Monitor window open during Upload (Arduino 1.0.6, 1.6.0, 1.6.1)
  • Improve Arduino Serial Monitor efficiency & memory usage (Arduino 1.0.6)
  • Wire.setClock()
  • Tools > CPU Speed menu supports speed vs size optimized (Teensy 3.1 & LC)
  • Update sample Makefile for non-Arduino usage
  • Simplify usb_desc.h for creating custom USB devices
  • Libraries added: Adafruit_VS1053, FastCRC, openGLCD, Snooze, TFT_ILI9163C
  • Libraries updated: Adafruit_CC3000, Adafruit_NeoPixel, Adafruit_SSD1306, Adafruit_ST7735, FastLED, FreqCount, FreqMeasure, ILI9341_t3, IRremote, MsTimer2, OctoWS2811, OneWire, PS2Keyboard, PulsePosition, Time, TimerOne, TimerThree, TinyGPS
  • Upgrade ARM Toolchain from 4.7.2 to 4.8.4.
  • Various minor bug fixes


Special thanks to everyone who helped beta test and everyone who contributed ideas, feedback, patches and libraries.
 
Small suggestion. It's unclear what "optimized" means without reading the version changes here. Could be interpreted as optimized for speed or size. You probably rather not clutter the menu a lot. This might work?:
48 MHz >speed
24 MHz >speed
48 MHz <size
24 MHz <size
 
Paul,
I did a fresh install of Arduino 1.6.1 with teensyduino 1.21 on top of it.
I can't get any of my teensy++ 2.0 code to compile or any of your teensy example code. (I tried 5 or 6)
I get errors like this
C:\arduino-1.6.1\hardware\teensy\avr\cores\teensy\../usb_flightsim/usb.c:76:24: error: variable 'rawhid_hid_report_desc' must be const in order to be put into read-only section by means of '__attribute__((progmem))'
static uint8_t PROGMEM rawhid_hid_report_desc[] = {
when I fix the const issue, I get lots of other compile errors.

If I change the board to teensy 3.1, everything compiles fine.

-Jeff
 
With those files, I now get several warnings in other files. (you can reproduce it by making an empty project, set to teensy++ 2 and Flight sim)

I also tried a 3.1 / Serial project with #include <SD.h> and it says it can't find #include <SPI.h>, and I installed all the teensy libraries.

C:\arduino-1.6.1\hardware\teensy\avr\libraries\SD\utility\Sd2Card.cpp:21:17: fatal error: SPI.h: No such file or directory
#include <SPI.h>

FYI: I tried 1.21 on Arduino 1.0.6 and the teensy++ compiles work.
The #include <SD.h> issues works on teensy++, but I get the same error with teensy 3.1.
 
Last edited:
Yes, there are currently many harmless warnings. That's common after upgrading the toolchain, as recently happened on both AVR and ARM. It's still the same code we've been using for years, but the compiler become more picky over time.

You might think I and other software authors ought to have a zero tolerance policy for compiler warnings. I certainly do over the very long run.

But in the short term, meaning the next few months until another release, I'd much rather endure warnings that I'm confident are harmless (and user comments about them) than warning-free code based on hastily rewritten and poorly tested changes. Some warnings are quick and easy to fix with very low risk. Many of those got fixed already, or will be addressed soon. But some are much more involved.
 
C:\arduino-1.6.1\hardware\teensy\avr\libraries\SD\utility\Sd2Card.cpp:21:17: fatal error: SPI.h: No such file or directory
#include <SPI.h>

Regarding this problem (and all specific problems), you must post the code. See the "forum rule". If it's just one of the examples without any changes, just clearly mentioning which example is fine.

However, you should be aware the Arduino SD library changed from 1.0.x to 1.6.x, to require the SPI library. The new version requires #include <SPI.h> in your sketch. If you're compiling an old program that was written for 1.0.x, you'll need to add that. This isn't specific to Teensy. It's a change in the SD library, which applies to all Arduino boards.
 
I understand the heartache of upgrading a compiler.
I didn't know if you were aware of the warnings because of the other errors I was seeing in the flight sim code.

Adding #include <SPI.h> in my sketch fixed the SD.h error.
(although I'm still a little confused why adding it to the sketch eliminates the dependency problem for spi.h in the .cpp files)

Thanks
Jeff
 
Jeff: The Change in the library to rely on SPI as you note made a dependency on having access to that code base that was not required before. When you added '#include <SPI.h>' the needed reference to that specific code was provided giving the compiler a specification to the needed code to resolve this new dependency.
 
(although I'm still a little confused why adding it to the sketch eliminates the dependency problem for spi.h in the .cpp files)

The Arduino IDE parses the #include lines in your sketch to configure which libraries are built. The SD library can't tell the Arduino IDE that it needs the SPI library.

This is a silly limitation that's always existed in Arduino. Years ago, I came up with a fix, but David Mellis (then Arduino's technical lead in charge of accepting contributions) changed his mind at the last minute. So it never got accepted. Later, when he realized that to be a mistake, I had started working heavily on Teensy 3.0 and couldn't devote time to the IDE. Since then, the issue has come up many times, usually with nobody willing to do the work. In recent years, the issue has been further clouded by Arduino's move to a new library format with metadata. It's a terrible shame so much indecision over the years on Arduino's part has kept such a simple thing as automatically detecting library dependencies to be added. But that's the situation, if you use a library like SD which uses SPI internally, you have to #include the SPI header in your sketch in the Arduino editor, even if you never use the SPI library directly.
 
I think it's a real problem, cause it makes libraries seem like they don't work. I think there's an expectation that a library is self-contained, and when there's compile errors, it makes the libraries seem broken. And that's bad for the user and the library contributors. I'm surprised that the core Arduino IDE team hasn't addressed it.
 
The Arduino IDE parses the #include lines in your sketch to configure which libraries are built. The SD library can't tell the Arduino IDE that it needs the SPI library.

This is a silly limitation that's always existed in Arduino. Years ago, I came up with a fix, but David Mellis (then Arduino's technical lead in charge of accepting contributions) changed his mind at the last minute. So it never got accepted.

It seems that there are different people in charge of accepting contributions now; also perhaps a slightly more accepting attitude? May be worth a pull request at some point to try again (probably presented as a brand-new pull rather than bringing up old history).

If that results in more delay or rejection, as a fallback strategy, just make it a Teensy-only change?
 
Yes Nantonos, that's pretty much my plan.

I also posted a message about it on their mail list. Predictably, that conversation has already wandered off-topic. Arduino is so filled with controversial design choices and trade-offs that even very obviously needed features like this can't possibly be discussed without wandering off topic to all that other junk people want changed.

They have become much more accepting of contributions since Cristian Maglie took over as their lead developer.

But if they don't accept this, or if it gets delayed, I'll just put it into Teensyduino and maintain it along with all the other patches.
 
Yes Nantonos, that's pretty much my plan.

Thanks Paul! I also agree that this is a way overdue feature for Arduino!

Another feature I always think is missing is some ability to for a project to have parameters to pass to the compiler. Things like, maybe in this project I want SoftwareSerial to only use PortX... Or maybe a way to set buffer sizes... I like some others have sort of solved this in some of my libraries, by putting all of the source code in header files, but I really don't like that approach.

I try to read through stuff that is posted on the Arduino Developers list, but often lose interest as many of the subjects and/or solutions. Example the print enhancements. Why not just include printf like you did, instead of adding some new cryptic syntax specific to Arduino... But I am getting off topic ;)

So again thank you! I think your idea to use the pre-processor sounds promising.
 
The problem with printf is that it is so general, it tends to lead to code bloat. On a teensy 3.1 with 128K of flash, that is not as much of an issue, but on a Lilypad with only 16K it might be more of an issue (let alone the ATtiny85's with 8K, but they usually don't have serial/usb support so it is not as much of an issue).
 
Sorry, I know that print stuff is completely off topic... And I understand about code size... But I don't think I would ever use things like:
Code:
          Serial.print(3.141592, PRECISION(4) & FIELDSIZE(3));   
          Serial.print(22, RADIX(5) & FIELDSIZE(8) & ALIGNLEFT);
          Serial.print(34, OCT & FIELDSIZE(8) & FORCESIGN & FILLZEROS);
But maybe it's just me.
 
KurtE at times I would use printf to get things aligned to the right number of columns. At the moment, I tend to do things like:

Code:
  if (x >= 0 && x < 10)
    Serial.print ("  ");
  else if (x >= -9 && x < 100)
    Serial.print (" ");
  Serial.print (x);

In general with the current Serial<x>.print functions, you don't pay the code cost for all of the types you don't use, as these functions are typically deleted by the linker since there are no references to them. With *printf however, you get everything, since it has to parse the string at runtime, though whether float/double support is in *printf depends on the installation. With 1.21 of Teensydunio, you have to use an asm to pull in the FP specific version of *printf. With Ardunio, you can't use float/double in *printf in the first place.
 
Awesome work, as usual!

I hope they include it. I've helped many people (for educational youth maker movement stuff) who have run into the dependency problem. Stalls people for weeks, not knowing how to proceed.
 
Thank you Paul,
Support for the Arduino 1.6.1 certainly pushed me to finally order the Teensy 3.1. Been loving my Teensy 3.0 for almost 2 years now. I Thank you for your dedication for the project! Can't wait for some new hardcore Teensies.

EDIT: Is there a good guide for taking advantage of the 2,4, 8 & 16 MHz modes the Teensy 3.1 is capable of running on? Thinking of some low power applications there.
 
Last edited:
mini54-->KL02

Awesome, purchased 4 boards when released, and just got my TeensyLCs working from scratch.
New Arduino install on Windows8.1 - I did a quick test of the Analog read with Led Flash (pin 13) and it worked - printing text to the serial monitor and flash the led.
Its always so amazing to see the ease of getting started with a Teensy board - and that takes a lot of work to make it easy.
I'm using the TeensyLC on a new board and put it out through OshPark - and should be getting that back in the next couple of days.
I was wondering is the boot/(Update:Mini54-->KL02 I read somewhere) a low power boot, and anybody done any low power testing yet on the TeensyLC. I know there was some beta testing earlier on, but can't find any follow on for that. thanks.
 
Last edited:
I am unable to use any version of Teensyduino past v1.2 until you are able to figure out why it made multi sound effect playback on the audio library worse. I mentioned it in the testing thread for v.121 and you said it was because I have 500+ sound files on the SD card, and it could be because of how the SD card library works. It also has a slight squeak noise as it opens certain files, but goes away when I reduce the number of files on the card. It performs even worse when you try to open files in rapid succession (100-200ms between open) and is totally unable to be used in the most recent version. This is in a product that we use as well, so I can't update our upcoming product until then.

Thanks,
-zsdicker@gmail.com
 
I am unable to use any version of Teensyduino past v1.2 until you are able to figure out why it made multi sound effect playback on the audio library worse.

As I recall, when you brought this up before and it came time to actually provide files, the realization that the number of files on the card was most likely causing the problem came up. I removed this from my list of pending issues to investigate.

I can and will investigate, but I really need you to do your homework first. You must provide a test case which you've confirmed works with version 1.20 and fails with 1.21. If it requires 100 or 500 files, we'll find a way. Worst case, we can ship a couple micro SD cards back and forth.

But please do not ask me to pour engineering time into investigating a problem that you haven't carefully verified does not happen with 1.20 and does happen with 1.21 using the EXACT same code and same data. If you have different data you're using with the 1.20 version, please get your files and test in order and make absolutely sure this really is a problem with the change from 1.20 to 1.21 and not something else you've done that's not identical in how you're testing each.

Let me know when you have a solid, confirmed test case.
 
Status
Not open for further replies.
Back
Top