Well, there I was trying to stuff 200 pounds of stuff into a 50 pound box...in this case, a combined gas and ion grid controller for the fusor, to be part of the data aq and control for fully remoting and automating it.
It almost fit. And I could have forced it, but it would have required re-writing a couple of the base arduino libraries for I/O to get the speed I needed to have a stable loop for certain, and it probably would have stumbled slightly when a host PC wanted to send it a command or get data. Since we are not yet at the end of the world, and resources are there - what the heck, I thought about trying out the new Teensy from PJRC. After the usual bit of fiddling around to get the toolchain going (it requires any version of the arduino IDE except the one I had, a few slight system file edits, and so on - nothing unusual) - it's one really nice piece of work. Thanks Paul and Robin for making this so I didn't have to and can just move on to programming it and making use of it in a practical application.
There was (and is) of course the usual learning curve. As Paul wrote - the dox are kinda hard to read - even if you can find them all and you're an engineer experienced in translating obscure data into useful information. Such is life with ARM things (and a few others that are almost as weird). Obviously, Paul alone can't re document everything. So there are a few glitches along the way. Example - arduino.cc says an integer (for uno) is 16 bits, but here it's 32. No big deal unless you weren't paying attention. I suppose that's why a lot of the raw code additions use things like int16_t as typedefs for stuff - so there is simply no question about that kind of thing - the bitness is right in the definition itself. This is good for the few of us that work on many different platforms at a time, versus using C's "int" and so on...as my email sig says "Why guess when you can know?".
One of the reasons I got interested in the Teensy in the first place was the built in D/A, as I'm doing a PID loop control for the ion grid bias, along with other things, and that requires an analog output. While the Uno could do this via an MCP4725(from Adafruit), the combined delay from the I2C and the conservative a/d timing (max wait between samples on different channels to let the S/H acquire) meant I was really pushing things.
While I have not yet tested the A/D performance on the Teensy (coming up, one thing at a time) - the D/A is nicely quick, around 3.5 us/sample when fishing samples out of a table. I also need interrupts for this project, so I wrote a little test. I make a sine table of 50 samples at startup and push that out to the D/A, then wait 5uS and do the next sample. I set up an interrupt from timer one to go 10 Hz, and watched to see if there were any issues (like the famous "pentium pause") - but nope, after a couple days, they're still in the same exact sync as when it first powered up with this sketch. Not too shabby...I will go on to other tests and provide the code for those as well, but here's the picture - same one for about 72 hours of running, not one sample off. I had the scope triggering on the interrupt which also toggled the LED pin, so it's showing 5 hz, or a very close approximation - at that many digits, it's hard to tell which one is closer to the truth - this is darned good.
And of course, here is the test code I was running as a sketch in arduino IDE 1.6.5r5+teensy tools. FWIW, I'm using Mint-Mate 17.2 as the PC host system, which is based closely on Ubuntu except for having a far nicer desktop and user interface (obviously, a matter of opinion, but a lot of people have this one, having fled from Unity being crammed down our throats with only options for an incomplete and broken GTK3). Works fine. I haven't yet really run into any problems with ubuntu things working fine on Mate - they just look nicer and are easier to use than with Unity.