...at a Freescale event in Santa Clara, picking up information on, mainly, the rapidly-evolving Kinetis* MCU family.
This inspires me to do a bit more digging, and fiddling, and....
Well, the MCUs themselves are quite impressive, and, as I've noted, some of the low-end ones are seriously competing on price with low-end 8-bit MCUs.
The software support, though, is lagging a bit. They're in process of moving from CodeWarrior (I've encountered other people using that, many years ago, on well-funded projects) to free Eclipse-based Kinetis Design Studio, and, well, things are in transition. Real Soon Now, there's supposed to be KDS for Mac (it's currently on Windows and Linux, but one of my potential products is likely to have firmware developed for it by the sort of people who use iThings), and also key code ought to be migrated to the KDS/GNU environment, but that's Not There Yet, and importing example projects doesn't seem to work the way one would expect.
There was a hands-on KDS session at the Thursday thing, but, having been rather late in deciding I could attend at all, I was too late to get a seat in that session, and instead sat in on the sensor fusion session in the next room (which was interesting indeed, and I've downloaded those libraries, and sometime this spring I'll be trying to figure out how to use them).
Ah, well. Another interesting development: some of the new chips (e.g., KL27Z series) come with a multi-interface bootloader in ROM, to allow installing firmware over USB, UART, I2C, or whatever, without at any time requiring use of a special-purpose debug/programming connector**. Could be handy, and maybe for the project that was tentatively planned with a KL26Z, I should use a KL27Z instead (same size package, and, I believe, slightly more expensive but with more memory, and still price-competitive with an 8-bit solution when all's said and done).
Update: Now my FRDM-KL25Z board seems to have gotten frotzed. I don't know if this happened as a result of my attempting to speak OpenSDA to it using KDS, or if it happened earlier, but now if I try to load an Mbed program I get the dreaded SWD ERROR, and, while there are various suggestions out there in Netland as to the cure for this, none of them actually appear to work.
The FRDM-K64F board does still work as an Mbed, and I'm not sure I want to sic KDS on it until I have a better idea what's going on.
As is typical In The Industry, the third-party tools (debugging pods and the like) are wildly expensive, at least the versions not subject to severe licensing restrictions (generally forbidding any manner of commercial use), and it looks like the firmware needed to make the vendor's own development tools work is also subject to awkward (and, presumably, widely ignored) restrictions. So, it's not altogether clear whether one could, legally, sell knockoffs of the FRDM OpenSDA subsystem in pod form, at least in any usable state. Which is really a shame, because (assuming it actually does work with KDS, if your target board hasn't gotten frotzed) it would make a nifty cheap programming pod, only a little pricier than one of the little USB AVR programmers and having actual debugging capability to boot. (Though extending the pod design and its protocol to include control of target power would be a really nice thing for those of us who like to automate processes, hint hint.)
Update 2: Based on the debugging output when I run openocd manually, it looks like it's the target processor on the FRDM board that's gone bad... or maybe I messed up the SWD interface to it somehow, perhaps when I installed a set of headers on the board.
Anyway, for all I know, I've got a perfectly usable programming/debugging pod sitting there. But if not... it looks like the "Multilink Universal" from P&E Micro might be about right, and the $200 price tag isn't all that painful as capital equipment goes.
* I still get this mixed up with Kinect and/or K'NEX.
** NXP has had this feature for years, but only supporting a UART interface, and with a somewhat poorly-considered convention for the use of modem-control signals.
Comments