I have a Teensy 3.1 (MK20DX256) and I'm be interested in adding in support for that chip ontop of what you've done. I'm primarily interested in the C HAL layer for integration with MicroPython.

Hello Dave,

cool ! If you have time, look at the SPI driver which needs to be completed! I am working on another mbed task so this is on hold for a while.

Regards, 0cx0170

What problems remain for the K20, the KL05Z is up and running on Mbed, is there anything left for the K20 to be done? Without an in-depth check is the SPI code not the same for these platforms? RTC clock, is this self contained or does it rely on external clocking and will it run in Deep Sleep mode? The KL05Z is the definitive method.

The SPI code is completely different. I believe the rest is pretty much the same, but also on the KL targets the spi code is left in the target specific folders, the KL25 and KL46 have different ones, dunno actually about KL05. The K20 has again a different one, completely different from the others. (And very strange DMA implementation for the SPI, but thats another story).

Regarding RTC, I only checked the boards user manual, but it seems to be the same as the KL25Z, no seperate 32kHz crystal for the RTC. So if that is the case, then best case is that possibly the internal 32kHz oscillator can be routed to the RTC, but that won't be very accurate.

I would be able to help. I am currently working on Some "hack" projects for freescale:

https://community.freescale.com/docs/DOC-99621

Project 1 & 2 are about done. All the code is compiled with codewarrior but I would like to see an mbed version.

Let me know the process.

Hello Eki Hughes,

I am currently busy with one project, I am not able to allocate time for k20 at the moment. If you are wiling to help, pull mbed sources from github, look at k20 target. SPI is not completely implemented yet (spi freq for example).

You can test the rest of peripherals also. I can assist, let me know if you need any help. ANy progress, share with us.

Regards, 0xc0170

Hey guys. I am also interested in using k20D50M with mbed. I managed to load the interface on the board, though i can not understand how to make k20D50M as a target through the online compiler.

I am willing to test on it what you give me.

Cheers

It is not yet available in the online compiler. To use it you need to pull the files from the mbed github and make them (Some info: http://embeddedworldweb.blogspot.nl/2013/12/how-to-use-mbed-exporters-tutorial.html, also here in the SDK handbook page it tells you a bit about it), and then compile offline. But that isn't as trivial as the online compiler.

I currently just started finishing op the K20 code. Martin was a bit on the optimistic side of what still had to be done (some stuff for example changed in the mbed lib, which had to be added to the K20 code too), but progress is happening. I don't have a logic analyzer yet, so really checking SPI for example is not possible for me, but I am now first fixing some stuff regarding the timers.

When the code itself is close to being done (which should be fairly soon) it should be added to the online compiler, but I have no idea what is involved in that and how long it takes.

Ok, Thanks. I'll take a look.

@Erik: I will help to make this target complete ;)

Guys, use this notebook for development status discussion or anything related to this target. I am currently on vacation.. I will contribute once I get back. K20 and K64F should share most of peripherals as I recall during porting these 2 targets.

I will try to support testing as much as I can. I'll let you know if anything comes up.

I made for the timer changes and some general changes so that it compiles again a pull-request: https://github.com/mbedmicro/mbed/pull/264.

I think next I am going to check the I2C code. And yeah that one is complete, but there is a bug in the KLxx I2C code for byte-wise read operations, and I think the same code is used for the K20, so both can be squished at the same time :).

Btw is there a special reason why it is called K20D5M instead of K20D50M?

Conclusion: I need to wait on logic analyzer for I2C :(.

Edit: Not for sleep/deepsleep though. Pretty much copy paste from KLxx code:

• Running current: 16.5mA
• Sleep current: 9.5mA
• Deepsleep current: 3.5uA :)

Verified if it wakes up correctly using an InterruptIn as wakeup source, and since it works that also verifies that InterruptIns work.