Kinetis SDK 1.0.0 observations

[jrychter]

I was away from Kinetis for several months and I've just had a chance to spend some time looking at the code of the Kinetis SDK 1.0.0 release. I am very impressed. This is nearly everything I was asking for — I used to be rather disappointed with the state of library support for Kinetis devices.

The SDK is working together with CMSIS, which is great. It supports bare metal, and most importantly it aims to provide a system-level interface to certain components (a clock library and a power management library were sorely missing, I was about to write my own). Overall the code looks fine, and I think this is a great direction to take. Don't introduce too many abstractions and layers, just provide a good interface to the underlying hardware.

It still fails short in some ways, but I'm hoping this will improve quickly. Notably, the I2C master driver only works in blocking mode (which I why I'd still use my own code for this).

The biggest shortcoming, though, is the list of supported devices. I use KL05, KL25 and K20 in my projects, none of these are supported. What's worse, there seems to be no roadmap, so I don't know whether I should wait for the SDK to improve, put the projects on hold, or write code myself? On a practical level, right now the whole Kinetis SDK effort is a nifty demo from my point of view, with zero practical utility.

Please: it would help tremendously if you could a) try hard to support most Kinetis devices, b) post a roadmap of device support so that we know roughly what to expect.

[martinr_]

I'd like to also raise my voice in favor of K10D10 and K20D7 support. I've spent quite some time analysing the KSDK structure and the needed changes for K10 und K20 support and am left with the impression that it shouldn't be too much of a challenge with your established toolchain and process. From what I've gathered a lot of the files would need minute modifications, it's mainly the _registers and _features macros and defines that are problematic. But those 90000 line monsters aren't created manually.

So pretty please consider adding those platforms, even as a beta...

Or at least hurry up with a timetable.

[Kan_Li]

Hi Martin,

As I know, K10D10 should be already supported by KSDK 1.1.0, since TWR-K60D100M is supported in this release.

Have a great day,
Kan

[martinr_]

Thanks for your reply kan!

I thought so too, but didn't want to waste any effort on it. Especially whilst the second platform MK20D7 isn't supported and the hardware is still in development.

What do I need to change in or add to KSDK? I would use the flexcan uart sample as a starting point (minus the board.h)

Just copy over the relevant MK60D10 files*, replace all "MK60D10" with "MK10D10" and change the symbol from CPU_MK60DN512VMD10 to CPU_MK10DN512VLL10?

*MK60D10.h, MK60D10_registers, MK60D10_features.h, fsl_sim_hal_MK60D10.h, fsl_clock_MK60D10.h add "MK10D10_series" to fsl_uart_irq.c, fsl_clock_manager.h and fsl_power_manager.c, plus any changes I might have missed

[Kan_Li]

Hi Martin,

The header files in KSDK is CMSIS style header file, so just replacing the header files might cause some compiling issue, and I was told in rev 1.2.0, MK10D10 is fully supported by header files/linker files/startup codes, so you may wait for the next release, which should be available in April.

Have a great day,
Kan

[anthony_huereca]

Hi Jan,

I'm glad to hear the good feedback. We are still tweaking and improving things, but I'm glad you think we're going in the right direction with Kinetis SDK. We've made it a focus of our software enablement and there will be more to come.

  As to your concern about board support, that is something we've definitely looked at. The focus is on new Kinetis devices, but there are some older devices we will be supporting in future releases since we know there is demand there. To give you a glimpse at what is planned, here are the boards supported in KSDK 1.1 which will be released in mid December. One of the legacy MCUs supported is the K60D 100Mhz devices.

FRDM-K22F

FRDM-K22F-K02*

FRDM-K22F-K02 64*

FRDM-K64F

FRDM-KL03Z

FRDM-KL46Z

TWR-K22F120M

TWR-K22F120M-K02*

TWR-K24F120M

TWR-K60D100M

TWR-K64F120M

TWR-KV10Z75M

TWR-KV31F120M

TWR-KV31F120M-KV30*

*These boards do not physically exist, but you can use the associated board to develop code for the subset devices listed. So for instance, if you're interested in the K02 device, use the FRDM-K22F for evaluation but use the K02 libraries provided to write code which will run on the K22F since it is a superset device.

There will also be more stand-alone releases planned in Q1 and will make announcements as those become more finalized.

Regards,

Anthony 

[w2vy]

I see the TWR-K60D100M in the list, I am using a slightly different derivative of the K60 on a custom board.

Is there (or will there be) documentation on how to add new processors and target boards?

The new processors could be shared as well as any COTS boards...

Tom

[jrychter]

Hmm. What about low-end devices? All my projects are cost-sensitive, and at the moment I'm working with KL02, KL05 and K20 (possibly also KL25). None of those seems to be targeted by the SDK.

[anthony_huereca]

There are a few low-end devices supported, like the K02, KL03 (which is a newer version of the KL02), and KL46. Future Kinetis L devices will be supported by KSDK as they launch as well.

So while I can't promise KL05/KL25/K20 will be supported down the road, I just want to make it clear that KSDK is meant to work with both our high end and low end Kinetis devices. If I learn that those older devices will be supported in a future KSDK release I'll update this thread.

[jrychter]

Thanks. I guess that means I can't start to base my work on KSDK and have to just watch it from the sidelines, until it's ready.

I really wish you could publish a clearer timeline.