New To The Store: Teensy 3.1

New today in the Hackaday Store is the Teensy 3.1. This development board blows away most others in its class. The board plays nicely with the Arduino IDE, but embedded developers who are hardcore enough have the option of bare metal programming for the Coretex-M4 chip.

Why would we say this blows most others away? In our minds, the 64k of RAM and 72 MHz clock speed place this far outside of what you would normally see hanging out in the Arduino ecosystem. That may be changing with new players like the Edison, but the Teensy 3.1 doesn’t require a host board and comes in just under $20 compared to the Edison’s $50 price tag.

[Paul Stoffregen], the developer of the Teensy, is a hacker’s hacker and is known to be found round these parts. All year [Paul] has been developing an Audio Library that takes advantage of the Teensy 3.1’s powerful processor (including its DMA features; we’ve been pestering him to write an article for us on that topic). We covered the library back in September and are stocking the audio add-on board in the store as well. Quite frankly, the quality of sound that this puts out is astonishing. If you’re working on a project that calls for playback of recorded sound this is one of the least-complicated ways to get there.

57 thoughts on “New To The Store: Teensy 3.1

    1. Was 640 KB originally a limitation of DOS or the computers that it ran on? IIRC the start of video memory on the CGA (the first color graphics adapter for the PC) was mapped to 0xA0000 and that address range has been reserved for video memory ever since (at least during bootup).

      1. It is a limitation of the specific IBM PC design with how they laid out the address map as you mentioned. The IBM PC design was already being worked on before Microsoft got involved. There are a load of really odd quirks in the PC because it was a lashed up skunkworks project by IBM. An example would be the first 32 interrupt vectors. Intel reserved them for internal exceptions for the CPU but the BIOS ignores that and reuses them.

        1. I’ve done some bare metal programming on PCs (ex. bootdisks) and I am quite convinced that there is no more cobbled together and technologically messy piece of equipment in such widespread use. There are chips on early PCs that didn’t work properly when they were first included, and as far as anyone knows still don’t on today’s machines (ex. ISA DMA controller).

      1. Top quotation expert Fred Shapiro, editor of the Yale Book of Quotations, located the earliest version of this sentiment credited to Gates [BGNN]:

        When we set the upper limit of PC-DOS at 640K, we thought nobody would ever need that much memory. — William Gates, chairman of Microsoft

        These words appeared at the beginning of an editorial written by James E. Fawcette published in the April 29, 1985 issue of InfoWorld. But no precise reference was given, and the words did not occur as part of an interview.

        So some debate still holds regarding that quote.

      1. You have a direct interface to an audio shield but you lose the direct interface to all the shields compatible with the Arduino headers, I would hardly call this a deal.
        And you don’t get to choose between many different M0, M3 and M4.
        And mbed is now backed by ARM itself.
        No, it still doesn’t look a “no brainer” to me.

    1. I quite like the Tiva C launchpad which also costs about 10 dollars. Cortex M4F at 80MHz, only 32kb of ram rather than 64 (I say only, how often do you need that much) but I’d say addition of floating point and still maintaining arduino compatibility (if indirectly, via Energia specifically) is still enough to disprove teensy blowing stuff away.

    2. The nice thing about the teensy is that it is (largely) compatible with the Arduino environment. It even integrates transparently into the standard Arduino IDE. So, compared to things like the Arduino mini, proMicro, etc, you get a lot more CPU and RAM for the same price and size without having to give up the tools and libraries you already know. If you are just looking for an embedded ARM cortex dev board, then it is still a nice board, but nothing special. It’s also important to note that the teensy 3.x was developed before the Arduino Due. So, when it first came out, it was really in a league of its own in the Arduino world.

    3. Pros:

      -Not manufacturer subsidized so you can use Teensy as a module
      -Relatively good bang/buck ratio
      -Arduino and bare metal dev environments
      -Amazing support from Paul
      -Bootloader is independent of the host CPU: no boot block / keep out zone in flash and no fear of smashing the bootloader (like the Atmel Teensys)
      -Decent datasheets from Freescale on the SoC


      -Proprietary bootstrap CPU (the mini54T) firmware. Moving the SoC to your own board means you’re on your own for ISP and DFU
      -Bootloader protocol is non-standard (i.e. not CMSIS-DAP or USB-MSD like the mbed boards) but the tools are available for all platforms
      -Teensy 3.1 CPU isn’t currently compatible with mbed, though the 3.0 is since it has the MK20DX128VLH5

      I think Teensy is a great option for people using Arduino who need more horsepower or USB capabilities, want to play with embedded ARM for little $, or just want a small board with some room to grow.

      1. I used Freescal K22 for my HaD project. I don’t think the Freescale reference manual is all that good. The reference manual is generic and confusing. They didn’t even bother to remove features that are not in a series. It took me a lot of reading outside of the datasheet and reference to figure the actual spec of the chip and that shows how bad the documentation is. They seem to imply that there are 5V tolerant pins in the datasheet, but it turns out there isn’t any in the entire series. How hard to have a table in the summary to list memory configuration (FLASH/RAM/Flex) vs orderable part#?

        Their i2c section was badly written. They talked about stuff from the actual i2c specs which is useless as everyone can read the actual specs. They don’t tell you what bits to set in registers in their chips to do that. e.g. restart nor tell you about the pipeline requirement for the setting for the stop. Took me a couple of days to fully understand on my own. I am very familiar with i2c specs, just not with their chip.

        The chips doesn’t come with a ROM bootloader, so Paul added an external processor as the bootloader. Would be nice if he upgrade it to CMSIS-DAP debugging at some point as the spec is available. BTW CMSIS-DAP isn’t that great performance-wise, but it is supported for OpenOCD and commercial IDE.

        The K22 I used has 16 flexible DMA channels that is routed to a cross point, so almost no restrictions to what peripherals they can be used! I am already using 4 DMA channels and probably 6+ when I am done. The older K20 on the teensy I believe only has 4 channels.

        There are now more Freedom boards available in the last few months for the Freescale in the $15 price range with onboard OpenSDA debugger. (OpenSDA is not open source) Freescale probably pay Segger, so now there is a “free”, unsupported and withlicense restrictions Segger jlink-lite firmware replacement for these boards.

        1. I’ve run across inconsistencies too, and trying to figure out the features and datasheet that goes to a particular part number is painful. And yes, it does lack a ROM bootloader (the SPI programmability thing doesn’t count) which a lot of new ARM SoCs have. But in the last few years I’ve come to expect worse from documentation.

          Ever try to set up GPMC timings on an AM335x from the documentation? Or get burned by the PIC I2C engine state machine differences tucked away in an appnote instead of the programmer’s guide? Or work with any documentation from companies that insist on NDAs to get anything but a whitepaper?

          I didn’t know there was a Segger firmware for the FRDM boards. I usually wipe the OpenSDA off first-thing since I have a hate-on for PEMicro. I know CMSIS-DAP is kind of slow, but for most of what I’ve needed it for it’s been fine. There seems to be a lot of restructuring going on in the CMSIS-DAP Github so I’m hoping for some improvements. For $13 (plus headers and cables) for a FRDM-KL25Z it’s a steal for a debugger even if you never use the target CPU.

        2. Segger license does not allow the use of the firmware outside of the eval board. (the custom hardware clause)

          The problem with CMSIS–DAP is because it uses HID class. So fixed size packets at fixed USB frame intervals even for the time you need a tiny 2 bytes packet. Wish they pack multiple packet into HID to speed things up. Until someone rewrites the .dll, there are only so much you can do when HID is the bottleneck.

          Lower expectation is not a good thing. If anything, I would expect the vendor *should* be more competitive in maintaining good documentations. Pretty sad to have to read the Processor Expert generated crap C code to understand the hardware settings.

  1. Phenomenal support. Great community. Small form factor. Very low power consumption. Relatively high performance. Good libraries. Beginner and expert friendly. Best in class by far.

  2. Why not the TI Launchpads? The Tiva C Connected at $20 has 256K RAM, 1MB Flash and 120MHz with Ethernet, and the CC3200 is a little slower at 80MHz but adds Wifi instead of Ethernet for $30. They’re mostly Arduino-compatible with the Energia project.

      1. We get it, you like that tiva C thing.
        But tell me: when does an arduino compatible MCU ever need floating point math? I have not seen anybody use an arduino to make a calculator so far, and that’s the only use I can imagine where decent integer won’t do. Just curious.

        1. You are right that most of the time you get away just dandy with integer maths. But the amount of arduino code I have seen floating about which needlessly uses floating point math is just shocking. I guess that is one of the disadvantages to an easy to access platform, everyone and their grandma is releasing code and some of it just isn’t that good, at least on an M4F there is that safety net to make its usage just slightly less awful.

          I can certainly be useful in certain DSP applications though.
          I’ve used it, mostly out of lazyness. Usually I use integer maths.

        2. Even a basic PID controller needs to perform division, and without a hardware divider the compiler will turn that into an endless sequence of integer operations. As a result, your division will take longer to complete and your controller loop will reach a lower maximum frequency. Just one off the top of my head.

          1. I was initially going to suggest such a reason myself, until I realized that float will have the same issues and then some, you just can’t avoid some things in human math.

            And there are ways around things with integer, plus float can be done with integer hardware, and in fact there is a long history and there are books full of ways to do things with integer units that you might not think of if you are spoiled and have always dealt wit stuff that can do float natively.

            Funny, all of this reminds me there was a time when people had the option to buy separate float math co-processors for desktop computers. And that sounds like something some HaD enthusiast might have fun with, finding an old float co-processor and tying it into some arduino board :) Think of all the effort, and with so little gain apart from learning a lot about hardware blending.

          2. FYI: (from wiki) Multiply and divide are very fast in Cortex M4: 1-cycle 32-bit hardware multiply, 2-12 cycle 32-bit hardware divide. So for most things in embedded system, using integers & fraction can get the job done. Not like your analog I/O are floating points.

            ARM Cortex ADC are very fast. They starts at 1Msps/12-bit. Some ARM chips have multiple ADC for faster conversion rates. Some chip comes with DAC. You also get PWM clocked at much higher speed, so for things like motor controls ARM is the better choice.

            What’s AVR ADC again? 10-bit at tens of ksps. :P

        3. I use FP for the joystick control on my CNC, it uses a pow() function for exponential response. I use it also to compensate the speed of diagonal step, they are either sqrt(2) or sqrt(3) longer than aligned steps. It’s simpler than fixed point. I’m learning Ada where fixed point is part of the language, so maybe I’ll give it a go one day.

  3. You know how some people can’t seem to resist from buying jewelries, shoes, eyeglasses/sunglasses, clothes, commemorative plates, Ming vases, antiques, etc.? I think I’m the same way with dev. boards. (c:

    1. There is a steep learning curve for the ARM parts. It is very fuzzy on exception, error and startup/clock stuff. For my first couple of weeks, I was pretty much lost. But then again I jumped in using a new ARM part on a new board that I designed, used one without an eval board, try to port a RTOS and using a new tool chain. What can possibly go wrong? :)

      SWD debiggers, huge memory, processing speed, powerful peripherals, better compiler for ARM arch is big win if you are willing to invest your effort in learning it. Once you pay for >=4k of RAM in a 8-bit processor, you are better off using ARM. BTW RAM can store code too and no more crappy work around for putting data in ROM with the AVR GCC kludges!

      1. Teensy’s main value proposition is a smooth and fairly easy AVR-to-ARM transition, especially if you’re used to Arduino. Most of the 400-some Arduino libraries are ported and/or “just work” (unlike Arduino Due where many fail to compile or run properly). In fact, a good number of library combinations that fail on many AVR boards work on Teensy, due to larger memory, more hardware timers, etc. A tremendous amount of work has gone into compatibility with actual Arduino code, not just the basic functions like digitalWrite. Even some of the most commonly AVR registers are software emulated, so good portion of the AVR-based code out there works.

        Your point is valid for most of the ARM dev boards out there… they do have a very steep learning curve. If you’re not familiar with Teensy, I can see how you’d assume the same must be true…. and indeed, if you don’t use Teensyduino and try to bring up your own toolchain from scratch, it will be an uphill battle. But if you’re familiar with Arduino, Teensy really is a pretty easy way to transition to 32 bit ARM without such a painful learning curve.

      2. My application requires full RTOS. Not interested in Arduino or training wheels.

        I have designed a PCB that pushed its limits on board density, using all parts that I have not used before, on using 0.5mm pitched part and 0402 and trying my new way of building my board with hand soldering. I wnet PCB fab without without prototyping or playing with development boards. I learnt to use a new tool chain, and ported ChibiOS 3.0 to K22. Right now working on DMA drivers and enjoying it. I tested and worked on the dma SPI, DMA PS/2, wrote my own i2c from scratch driver for K22 in ChibiOS.

        I specifically decided to push myself on finding out what my limits are. Still haven’t find my upper limits yet. I am not in the teensy market.

  4. If you care about making something commercially viable over a span of years or simply want a product that will stick around, vendor-subsidized boards represent a risk. Vendors focus their efforts on the new hotness, not the trade show swag from years ago. Your supply of boards may dry up at any moment and if you trip over a critical library bug, you’ll be lucky if someone suggests a workaround.

    I don’t speak for PJRC, but in my observation their business model is selling boards. It’s in their interest to keep their customers happy for years to come.

  5. I just got a teensy 3.1 to play with, mainly because it had a DAC. In love with the wee thing already, very capable, definately order a few more soon, and the support and documentation i have found answered every question i have had so far. perhaps a little rude to ask here, but wheres the best place to buy genuine ones in the UK. Bought this one off ebay(was £20 so presume its legit), but i really like it and want to support the right people when I buy more.

  6. >including its DMA features; we’ve been pestering him to write an article for us on that topic

    I wrote one for my HaD project log here: It was for my own mental note for understanding what it does. More of an executive summary before diving in the Freescale reference manual. Nothing can save you from the 10+ registers settings to get things going. :P Don’t let the 300+ bytes worth of hardware register in the K22 scare you. It is quite simple onces you used it. :)

    I also wrote a DMA driver from scratch for interfacing PS/2 keyboard/mouse. I talked about the limitations of DMA in the K22. See project logs. So instead of interrupts or bitbanging, the DMA transfer takes snapshots of the GPIO port. After the sampling is done, the ARM processor goes in and extract the bits. This reduces the number of interrupts & real time requirements.

    No meant to be code there (yet) as it is work in progress and highly hardware/RTOS specific – my unofficial ChibiOS 3.0 K22 port.

      1. I tried to respond, and it appears to have thrown it out when forcing login.

        Anyway, Seeed has those in stock, and did within a short time of going up on Hack-a-Day. My order has shipped and is trackable already.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.