The Teensy++ 2.0 from ADAfruit

February 10, 2013

I took the plunge, spent my $27, and ordered a teensy++ 2.0 from ADAfruit. The low price is one big plus, along with on-chip USB, and a footprint that will let me plug it into a standard breadboard.

Not only that, the descriptions encourage the use of AVR-gcc along with the LUFA library rather than the Arduino environment, which is exactly the direction I have already been moving in!

Teensy variants

Note that it is crucial to specify the version number 2.0, or it will be completely ambiguous what you are talking about. Is a Teensy an AVR controller or an ARM? It all depends on the model number.

Now I think that this naming scheme is almost guaranteed to cause endless confusion (in particular switching from an AVR device to an ARM device when a version number changes!!??). Bad move. I also worry that the Teensy++ 2.0 that I am so enamored with may be on the path to being abandoned, but we shall see.

So the device I have - The Teensy++ 2.0 (and what this page is all about) is based on the ATmega AT90USB1286 chip, and in fact is little more than this chip, a reset button, and a mini-USB connector. (Note: a reasonably sturdy mini-USB, not the impossibly delicate micro-USB). It has more of everything than the defacto ATmega328P chip, the only demerit being that it runs at 16 rather than 20 Mhz. The module provides 46 IO pins on 0.1 inch centers!!

Now that I have played a bit withe the 90usb1286 based "teensy", here are some thoughts:

The Boot Loader

The boot loader brings some surprises for someone accustomed to the totally open Arduino culture. The Teensy uses the "Half Kay" bootloader. The code is closed and proprietary. It was written in assembly language and fits into 0.5 kilobytes of flash, hence the name. If you do something that blows up the loader, you are out of luck as far as finding a halfkay image to put back into your device. Not only that, the fuses are typically burned so that you cannot read out the image resident in the device you purchase.

That is the bad news. The good news is that it works pretty well and you are unlikely to have problems. If the proprietary business bugs you and/or you blow up your loader, you can switch to the TeensyHID bootloader from the LUFA project. It will take up 1K of flash (which on a 128K device, does not concern me at all). The other good news is that the protocol is simple and documented.

Schematic

I am breathing a sigh of relief! The schematic is not a proprietary secret. The schematics for the entire Teensy series are available at this link

My copy has none of the optional components on the bottom of the board.

First efforts

When I plug my device in, the LED begins to flash at 1 Hz, but there is no recognition of a USB device by the host computer. However when I push the reboot button, the devices switches from running what is apparently a "blink" application to the halfkay loader and I see the following USB device appear on my linux system: 
Feb  9 18:58:14 trona kernel: [1037882.601017] usb 2-6: new full-speed USB device number 6 using ohci_hcd
Feb  9 18:58:14 trona kernel: [1037882.780075] usb 2-6: New USB device found, idVendor=16c0, idProduct=0478
Feb  9 18:58:14 trona kernel: [1037882.780080] usb 2-6: New USB device strings: Mfr=0, Product=0, SerialNumber=0
Feb  9 18:58:14 trona kernel: [1037882.789319] hid-generic 0003:16C0:0478.0005: hidraw1: USB HID v1.11 Device [HID 16c0:0478] on usb-0000:00:02.0-6/input0
Feb  9 18:58:14 trona mtp-probe: checking bus 2, device 6: "/sys/devices/pci0000:00/0000:00:02.0/usb2/2-6"
Feb  9 18:58:14 trona mtp-probe: bus: 2, device: 6 was not an MTP device
If I disconnect and reconnect the USB cable, I am back to running the blink application. All this seems very nice and sensible.

We don't need no stinkin' /dev/tty* file!

You can ignore this section if you like, it turns out I ran around chasing my tail expecting things I should not have expected. In particular I expected that once I connected the Teensy and pressed the button to get it to run the boot loader that a file like /dev/ttyACM0 or /dev/ttyUSB0 would appear. This is not the case, nor is it necessary. In particular I expected the udev rules file provided on the PJRC website to cause this to happen, which is also not the case. All that the udev file does is to change permissions on any files which may get set up.

It is certainly worlds better than the Arduino situation with endless Java hassles, screwy messages about rxtx versions and all that nonsense. In fact it was all simple and good, I just ran off on a tangent. The only thing that is not good is the closed source we encounter here and there.

The instructions say to place the file 49-teensy.rules in the directory /etc/udev/rules.d on your linux system. I did this at first, but then moved it to /lib/udev/rules.d (which seems to be where the bulk of the udev rules are these days on a Fedora system).

When I did not see any messages about ttyUSB or ttyACM getting setup, I got worried about the mtp-probe messages. MTP is "music transfer protocol", which apparently gets awakened whenever a new USB device gets plugged in.

If you get curious about some of the details involved with udev rules, I recommended studying this link which discusses how to write udev rules.

I plugged in an Arduino Duemillanove that I have laying around, just to compare the messages. An important thing to notice in what follows is that the mtp-probe messages appear even in this case which works, so it would seem that mtp-probe looking things over is normal and a red herring. I will also note that I looked long and hard for udev rules that detect the FTDI device and sets up ttyUSB0. There are none, it just doesn't work that way. 

Feb  9 21:12:34 trona kernel: [1045943.024020] usb 2-5: new full-speed USB device number 9 using ohci_hcd
Feb  9 21:12:34 trona kernel: [1045943.228712] usb 2-5: New USB device found, idVendor=0403, idProduct=6001
Feb  9 21:12:34 trona kernel: [1045943.228717] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb  9 21:12:34 trona kernel: [1045943.228720] usb 2-5: Product: FT232R USB UART
Feb  9 21:12:34 trona kernel: [1045943.228722] usb 2-5: Manufacturer: FTDI
Feb  9 21:12:34 trona kernel: [1045943.228724] usb 2-5: SerialNumber: A6008bvC
Feb  9 21:12:34 trona mtp-probe: checking bus 2, device 9: "/sys/devices/pci0000:00/0000:00:02.0/usb2/2-5"
Feb  9 21:12:34 trona mtp-probe: bus: 2, device: 9 was not an MTP device
Feb  9 21:12:34 trona kernel: [1045943.276149] usbcore: registered new interface driver ftdi_sio
Feb  9 21:12:34 trona kernel: [1045943.277418] usbserial: USB Serial support registered for FTDI USB Serial Device
Feb  9 21:12:34 trona kernel: [1045943.278631] ftdi_sio 2-5:1.0: FTDI USB Serial Device converter detected
Feb  9 21:12:34 trona kernel: [1045943.278756] usb 2-5: Detected FT232RL
Feb  9 21:12:34 trona kernel: [1045943.278758] usb 2-5: Number of endpoints 2
Feb  9 21:12:34 trona kernel: [1045943.278761] usb 2-5: Endpoint 1 MaxPacketSize 64
Feb  9 21:12:34 trona kernel: [1045943.278763] usb 2-5: Endpoint 2 MaxPacketSize 64
Feb  9 21:12:34 trona kernel: [1045943.278765] usb 2-5: Setting MaxPacketSize 64
Feb  9 21:12:35 trona kernel: [1045943.283878] usb 2-5: FTDI USB Serial Device converter now attached to ttyUSB0
All of this worry was just wasted energy. It is not even clear that the udev file is really essential, but I am going to leave it in /lib/udev/rules.d anyway just to be sure permission are set up properly.

Using the Teensy Loader

On the PJRC website, you can download the Teensy GUI loader as a linux executable. (It does not seem that they are supplying source for this software.) This is a nice little GTK based GUI that accepts hex files and starts them running on the Teensy. Even without a ttyUSB* or ttyACM* special device being setup, this was able to detect my Teensy and download the fast and slow blink demo into it. Apparently it is standard practice to ship a new Teensy with the slow blink demo. The shocker for me was that it works without any kind of special file of the form /dev/tty*, but apparently it works with libusb, which I clearly need to learn more about.

There is also a command line loader which is supplied as source. I obtained this and typed "make" and was told that usb.h was missing. 

yum install libusb-devel
After this, it compiled just fine, and it works! 
./teensy_cli -mmcu=at90usb1286 -v -w blink_fast.hex

The source for the "blinky" demo

Now I find myself wondering, "where is the source for the blink demos?" and "where can I find a makefile to build the blink demo I cannot find source for?".

I rooted around on the PJRC site, and found blinky.zip which contains some kind of blink demo along with a horrible 614 line bloated makefile. Well I shouldn't complain I guess since I got what I asked for (I think). And every other AVR microcontroller Makefile I have seen is a giant ridiculous thing.

I already have avr-gcc set up from some earlier AVR controller work, so I don't need to yum install those packages. I will note that the avr header files (such as delay macros) are in /usr/avr/include.

After changing one line in the Makefile (to specify MCU = at90usb1286) I can type "make clean ; make" and rebuild the blinky demo. I move teensy_cli into my /home/user/bin area and add a couple of additional lines to the Makefile so I can type "make load" and in seconds have this demo running.

It is not clear how to get the teensy_cli to deal with the "eep" file, and in fact the Makefile is using avrdude to download both the hex and eep files, so maybe I should too? I am not clear yet on using avrdude though. The Makefile looks for "com1" when I type "make program", and as I belabored above, no kind of serial port gets set up on my linux system -- I think I would probably have to burn a different boot loader to work with avrdude (not that this would be a terrible idea). So I am just ignoring the "eep" file for now.

My own source and a simpler Makefile

I was able to whittle the blinky demo down to a 38 line source file that blinks a simple pattern, along with a 155 line Makefile that is still far too fancy.

I have used Makefiles for many years and like them very much. Gnu make has many features that I ignore, but would be worth the time to learn about. The document to read to learn more would be:

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org