Been doing sundry development involving the Kinetis line of MCUs, and the KDS development environment had been kind of lagging behind.
Word since NXP acquired Freescale had been that there was something new and wonderful in the works. Lately, it seemed that a new development environment, MCUXpresso IDE, a wondrous offshoot of LPCXpresso, was to materialize on the 22nd of March, which is to say, yesterday.
Would Processor Expert finally support KSDK 2.x? Would there mayhap be integrated support for loading firmware via the Kinetis bootloader, Aard-wino style, for the benefit of those without debugging pods?
The day came, and the links went live. I downloaded the software for Linux, .deb flavor.
First off, the .deb package won't install if you already have KDS installed; there's a file in common.
(/lib/udev/rules.d/55-pemicro.rules, if you must know; it's obviously something that both packages need.)
So! I run the .run script until it starts unpacking the .deb, interrupt it, and make a copy of the .deb, which I then install with dpkg -i --force-overwrite, and installation completes. All appears well.
Except, um. I try to create a project, and no SDKs are available. I try to install an SDK, and, while I get the "are you sure?" dialog box, no installation happens. I copy an SDK to the directory where they need to go, and try to scan it, and I get a what appears to be a Java error, plus a "working" dialog box that just spins its little gears and does nothing.
Maybe I broke something by installing the .deb without its scriptular encapsulation? I fire up a VM with Linux Mint and no KDS installed, and do the install using the .run script. Same thing.
So, this morning, I download the Windows version, and install it on the Windows 7 VM. Installation is annoyingly time-consuming, with many "are you sure you want to install this device driver?" popups with enough time between them that I keep wandering off instead of sitting there waiting for the next prompt.
And, once it's installed, same thing as on Linux. No SDKs for creating new projects, the demo projects don't seem to be available, and I can't nohows install an SDK. Similar-looking Java error. Infinite gear-spinning when trying to grok a manually-installed SDK.
Such documentation as I've looked at doesn't seem to point to the continued existence of Processor Expert nor any other way of configuring device drivers short of digging through the documentation (such as it is) and source code for the SDK. Which makes for an awfully steep learning curve.
Well, I haven't actually gotten an e-mail from NXP announcing the availability of the new MCUXpresso, so perhaps they know it's not ready for prime time and a proper release will be forthcoming in a few days.
Update: OK, so it turns out I'd missed something. The on-line SDK generator has an option to generate the SDK for MCUXpresso IDE instead of for KDS. Do that, download the result, and the IDE installs and its demo projects are available.
But, no Processor Expert. There's the separate KEx Tools application, which can be used to configure pins & clocks, but it's not integrated, nor does it support configuring devices and their drivers (never mind the OS abstraction, FreeRTOS tasks, and suchlike). The on-line version says peripheral configuration is coming soon.
I guess the not-integrated tool may be somewhat OK. I plan on managing a line of gadgets - actually, there are two such in the works - with a base configuration (all use the same clock configuration, and some pins and some device drivers are in common), but with each family member having a unique configuration of the remaining pins and devices.
For now, things remain in KDS, but the production firmware may end up migrating; some restructuring is already called for anyway. Just to make life even more fun, I'm persuaded that one of these lines should really be set up as USB TMC (Test & Measurement Class); there's no handy reference implementation with KSDK, but I guess I can look at the KSDK's PHDC example and someone else's USBTMC implementation for a different platform and framework, and figure something out. And, currently, I only have use TMC device around here, that being the Rigol scope... and it seems that Rigol's TMC implementation is ill-behaved, so possibly the odd behavior I was seeing when I was poking at it from Linux last year was the result of Linux not recognizing the specific model and not using the special handling. So the idea of hooking up the scope via the USB protocol analyzer as a reference is maybe not so good.
Oh, well: I won't actually be trying to release that product line until maybe fall, what with there being much higher-priority stuff to do. I have one-each prototype board built, and quite a lot of markup for the respin (but no mandatory patch wires, and just one tacked-on resistor that shouldn't have been needed). And! I find that installing a set of swaged-in, nickel-plated-brass stacking spacers makes the little board seem Serious. Well, mostly heavy. But solid! Which is a good thing, I guess, as long as it's not meant to be flight-weight hardware (which this isn't).
Update 2: KSDK 2.x/MCUXpresso IDE share an annoying characteristic of KSDK 1.x / KDS, which is this: the example projects have a different structure from projects created with File →New→Project..., so creating a new project and swapping in code from an example Just Doesn't Work.
Oh, well. This whole thing needs to return to the back burner anyway. Too much real work to be done, plus tax time. Comes the time, I may adapt an example project, or try to figure out how to configure a new project, with the very latest version of the SDK, plus FreeRTOS and the USB stack. (Got to have the multi-threaded RTOS. Which isn't in any of the USB examples.)
Er. Some of that Real Work does involve Kinetis stuff, but not USB.
Recent Comments