Where is the Teensy M0 hardware?

Status
Not open for further replies.
I hope this upcoming chip is not vaporware. An ARM M0 microcontroller is very inexpensive and has uWatt capabilities.
 
Why would it be vaporware? AFAIK the chip itself has been identified and is in commercial supply.

I don't see why the board would be vaporware either. Or did you mean "why doesn't layout, fabrication, verification, debugging and testing with 400 libraries take zero time"?
 
Actually, the main holdup is a TON of little manufacturing details, which are needed to get the cost down.

I can tell you it's certainly on its way. In fact, I was planning to make an announcement early next week, with some actual solid details, rather than the gradual bits of info "leaked" in various threads over the last few months.
 
@Nantonos
testing with 400 libraries take zero time"?

Are you inferring that all the libraries will be released along with this new M0 ARM stamp? It took over 1.5 years to have the Teensy 3x libraries where they are today when the Teensy 3 was released from Kickstarter:rolleyes:
 
The honest reality is porting all libraries will take time. But not nearly as much time as Teensy 3.0/3.1 took, and many will "just work".

The M0+ chip we're using has a very similar peripheral set at Teensy 3.1. Most even have the exact same registers. Some libraries using Teensy 3.1 registers will work as-is, or with very little work. This isn't going to be anything like 2 years ago, starting fresh on a brand new platform with absolutely no software support.

Two years ago, many of the important libraries had AVR timer registers hard-coded. Many of them used timers only to run an interrupt routine at some predictable rate. I ported all of those to use IntervalTimer. So all those libraries will "just work" with a working IntervalTimer in the core library.

Also, since 2 years ago, the entire Arduino world has started changing. Especially Adafruit (who are responsible for a lot of the modern Arduino libraries) have adopted much more hardware neutral approaches. Others have too. Some people are still hard-coding AVR stuff, but it's not nearly as terrible as it once was. Teensy 3.1's avr_emulation.h has also come a long way since the early days!

But not everything is going to be perfectly smooth. Some libraries, like IRremote, are going to take some significant work. Some code will probably hard fault due to unaligned access (which works on M4, but faults on M0+).

The best I can tell you is, unlike pretty much all the other Arduino-compatible board makers, including Arduino themselves, I absolutely am committed to making nearly all 400-some widely used Arduino libraries work. I believe I have a pretty well established trend of not necessarily having everything smooth and perfect at release, but a pretty responsive process of truly investigating compatibility problems and fixing/porting libraries.

I hope you'll have realistic expectations, and most of all, I hope you'll post reproducible bug reports (eg, the "forum rule"). The vast majority of the time I spend on bugs is figuring out how to reproduce them. Once I get it happening on my workbench, I usually come up with a fix very quickly. Please, help me out if you can, with detailed reproducible bug reports!
 
Last edited:
Nevermind, manitou posted correct links in the announcement thread.

Hm...I can find document number KL26P64M48SF5 (Sub-family datasheet), weighing in at 61 pages, but no reference manual that seems to be written for that chip. Is one available?

There's a link from the KL26 page to document number KL24P80M48SF0RM, and the page states that this document is for the MKL26Z64VFT4. The first page, though, only shows the MKL24Z64VFT4 (note MKL24, not MKL26).
 
Last edited:
Status
Not open for further replies.
Back
Top