Teensyduino 1.13 Released

Status
Not open for further replies.

Paul

Administrator
Staff member
Teensyduino 1.13 has been released.

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

For use without Arduino, see the sample makefile in hardware/teensy/cores/teensy3 after installing.

These are the changes since Teensyduino 1.12:


  • Support for Arduino 1.0.4
  • Fix Serial.write(0)
  • Turkish keyboard layout (Teensy 3.0)
  • Fix while(!Serial)
  • Fixes for ST7565 library (Teensy 3.0)
  • Add OctoWS2811 library
  • Update libraries: Keypad, Metro, OneWire, Ping, ST7565

I am currently working to test and document all the Arduino libraries with Teensy 3.0. The library list now has a Teensy 3.0 compatibility column, so you can see which have been tested and their status:

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

I currently have about 20-some libraries to and add to that page... over the next couple months. If you know of any Arduino libraries that should be added to the list of tested and documented for Teensy, please comment below.

As always, please report any bugs. Try to include a sample program that reproduces the problem!
 
Congrats on the new release (including the amazing OctoWS2811 lib) :)

The only library I can think of mentioning is the SdFat, of which I can verify it works on a Teensy 3.0 'straight out of the box' up to (and including) the latest beta 'SdFatBeta20130207'.
I do not own a T2.0 (++) so I cannot verify functionality there, sorry.

As always, thanks for your hard work and dedication, words cannot describe my appreciation!
 
And I can confirm that SdFatBeta20130207 works on Teensy++ 2 with Teensyduino 1.13 and Arduino 1.0.4
A OneWire DS18B20 also works.

Pete
 
And from the Arduino 1.0.4 release notes
ARDUINO 1.0.4 - 2013.03.11 [core]

* Fixed malloc bug (Paul Stoffregen)
...

Yay.

As was mentioned in another thread, the current version of the Arduino DIN-MIDI library is 3.2 while the Teensy library page links to 3.1.1; 3.2 compiles on Teensy 2.0 without change, and compiles on Teensy 3.0 if an (unused) duplicate definition of 'word' is commented out in MIDI.h.

There is an entry in the libraries table for MCP4728, with no links. I suspect the library described here is meant; this is the source download link. I haven't found an MCP4728 breakout board yet, and its a SMD (10pin MSOP). Its the quad version of MCP4725, for which breakout boards do exist. May be worth trying the library with those.

Adafruit also have a MCP 4725 library which should be separately listed. It compiles for Teensy 2.0 and does not compile for Teensy 3.0 (Arduino 1..3 + Teensyduino 1.12 used for testing):
Code:
F:\Arduino\sketches\libraries\Adafruit_MCP4725\Adafruit_MCP4725.cpp: In member function 'void Adafruit_MCP4725::setVoltage(uint16_t, bool)':
F:\Arduino\sketches\libraries\Adafruit_MCP4725\Adafruit_MCP4725.cpp:67:22: error: 'TWBR' was not declared in this scope

And the problem is access to AVR registers to control I2C speed.
 
Last edited:
Teensy has been using the fixed malloc/realloc/free since December 2010 (to give credit where credit is due, it was fixed in a later version of avr-libc, so I just pulled that code and made a stand-alone version). I submitted it to Arduino's issue tracker on Jan 28, 2011. Nice to see it's finally getting used. ;)

I'm planning to update to MIDI 3.2, with that 1 line removed. It's on my to-do list, right after Encoder and PS2Keyboard (both need tiny patches). The library list is getting more of the blank spots filled in.

The libraries with all 3 blank are ones I'm planning to test, and I have purchased the hardware, but haven't built it yet. Actually, I have many others with hardware purchased, but not built, tested & documented. There's only so many hours in each day.....

I've been considering adding TWBR to avr_emulation.h. One unresolved issue with TWBR is how to interpret the numbers? For example, Adafruit_MCP4725 just sets it to 12 (a hard-coded constant). The TWBR entry on my to-do list references one other library: Adafruit-PCD8544. Right now, the github page isn't responding, so I can't peek at that code. Anyway, my concern is that some libraries might try to do a compile-time calculation with F_CPU. That's what I'd probably do. FreeIMU (prior to accepting a Teensy 3.0 patch) had this "TWBR = ((F_CPU / 400000L) - 16) / 2". On Teensy 3.0, F_CPU will be 24e6, 48e6 or 96e6, resulting in 22, 52 and 112. So perhaps the code should recognize either 12 or 22/52/112 to mean 400 kbit/sec is desired? That raises the other obvious question: do any existing libraries write to TWBR for some other purpose than switching from 100 kbit/sec to 400 kbit/sec after Wire is already running? The Freescale hardware uses a table of constants without a nice formula, so supporting any arbitrary speed would involve quite a lot of code.

The most helpful input for TWBR emulation would be adding to my list known TWBR-using libraries, so I can take a look at what they're doing and make up my mind about how to implement such an ugly compatibility hack.
 
Last edited:
Adding support for an emulated TWBR is one approach. If the number of libraries using it is small and/or they use it in varied ways, annother approach would be to add a clean way to switch between 100 and 400 for the Freescale processors, then get the libraries to wrap their TWBR in an ifdef and add your clean way in another ifdef?
 
One unresolved issue with TWBR is how to interpret the numbers? For example, Adafruit_MCP4725 just sets it to 12 (a hard-coded constant). The TWBR entry on my to-do list references one other library: Adafruit-PCD8544. Right now, the github page isn't responding, so I can't peek at that code. Anyway, my concern is that some libraries might try to do a compile-time calculation with F_CPU.

I found the formula for converting TWBR into frequency (source):

freq = clock / (16 + (2 * TWBR * prescaler))

followed by a table of values.
 
Last edited:
Shoot, I won't be able to criticize Massimo and Co. anymore for ignoring Pauls careful work to eradicate the malloc.c code? Say it ain't so!
 
TinyGPS works with Teensy 3.0. You can also get better precision in the floating point methods by replacing all floats in the library with doubles.

SoftEasyTransfer library works with Teensy 3.0 if you comment out the several instances of SoftwareSerial and uncomment the HardwareSerial instances in the .cpp and .h.
 
my favorite gripe of the AVR compiler being stuck at 4.3.2

Be careful what you wish for!

The 4.4 series added many bugs to the AVR C++ compiler. The really bad ones seem to be fixed in 4.5.x. Just a couple weeks ago someone posted on the Arduino developer mail list about a compiler bug in Atmel's version... which I could not reproduce on 4.3.2.

This topic has come up many times on that mail list. Atmel's own "open source" guy has commented about the C-only toolchain being very solid. Apparently very few of Atmel's customers use the C++ side, so it doesn't get debugged.

If Arduino upgrades, of course Teensy 2.0 will support whatever Arduino ships. But so far, there seems to be very little reason to upgrade, and plenty of reasons to avoid it.
 
Hey Paul, is there any word yet on when we will get serial number support for the Teensy 3.0? I know that I can manually specify the iSerialNumber value by modifying usb_desc.c, but that would require me to compile individualized firmware updates for future purchasers of my product that utilizes the Teensy.
 
Be careful what you wish for!

The 4.4 series added many bugs to the AVR C++ compiler. The really bad ones seem to be fixed in 4.5.x. Just a couple weeks ago someone posted on the Arduino developer mail list about a compiler bug in Atmel's version... which I could not reproduce on 4.3.2.

Bear in mind that I come to this as a GCC guy, and want GCC to be improved for all targets. I imagine a big problem is very few of the bug reports from the various microprocessor groups ever seem to filter back to the FSF bug reports. It is hard to fix problems you don't know about. Like most development groups, we only have 2-3 version trees open at a time, and the GCC 4.3 branch has been frozen for a long time.

I must admit to a personal reason as well, in that the AVR people picked up some major changes I did when I was working on the Cell backend in the 4.5 time period. AVR uses it for PROGMEM support. With Cell becoming less important, it is nice to see stuff I worked on for 6 months or so still being used.
 
Last edited:
I think eventually new features like named address spaces and link time optimization will make a gcc upgrade very compelling.

My general plan for Teensy 2.0 is to follow Arduino's lead, when or if they ever upgrade the toolchain for official AVR-based Arduino boards. They did recently purse all the very old SIGNAL() macros for compatibility with newer toolchains, so who knows, maybe they'll upgrade?

For Teensy 3.0, I'm planning to upgrade to 4.8 in a few months, and try enabling link time optimization at some point....
 
Install trouble. When trying to install TeensyDuino 1.13, and it asked me to navigate to the location where arduino 1.0.3 is installed, I went to that folder (in my case on F:) but the Next button stayed greyed out. Does this work when arduino is installed on drive other than C:?

thanks in advance,

Charlie
 
Yes, it should work on any drive letter. But the copy of Arduino must be either an original copy or one that's been modified by this version. The installer makes many checks, including a CRC check on the java object which contains the version number.

If it had any of the Teensyduino betas installed, it won't be recognized, because during the beta tests a number of different patches were tried within that java object.

Please download and extract a fresh copy of Arduino 1.0.3 or 1.0.4.
 
Status
Not open for further replies.
Back
Top