Add support for Freescale K20 MCUs and the mchck board #2271
Conversation
This needs a lot of testing right now as it is only tested on k20 CPUs
The cpu/k20 module includes code for the Freescale K20 series. This is in an early stage with some bugs remaining in the UART code (transmission is working, there still seem to be some problems with receiving data though.)
miri64
added
Discussion: RFC
|
There is also an import of |
|
For those who are unfamiliar with the MCHCK: https://mchck.org/ |
|
See also #2188 for a coordination/tracker for all things related to Kinetis MCUs. |
OlegHahm
added
the
Platform: ARM
|
This is interesting, I completely missed that kinetis_common PR. I checked a few days ago but not when creating the PR today. Should have :) Thanks for adding it to that list. I will look through some of that existing code, compare it with mine, test it on my device and merge the things together. |
|
Great work and welcome to RIOT! |
|
I recommend that you find a CMSIS compliant header for the device rather than the memory map header found among the Freescale downloads, for easier integration with the other Kinetis ports and other Cortex-M4 code. http://www.keil.com/dd/docs/arm/freescale/kinetis/mk20dz10.h is one example. A recent one can be found in the Keil MDK (Windows IDE). |
|
Ah thanks, I didn't know those were available, I searched for them before but probably just not enough. I'll use them then. |
|
@Farthen Actually, that header has an incompatible license, sorry. We need to resolve this header situation some other way.. |
|
Yup, the headers I found don't have any license information embedded in them at all (only Copyright: 1997 - 2012 Freescale, Inc. All Rights Reserved.) Should I write Freescale and ask them if they could (re)license them or would they just not care? |
|
@Farthen My guess is that they won't care until someone complains. Could you write them asking for permission to distribute the files? |
|
I asked them. I hope I'll get a response soon, but we will see about that. I did ask them about all of the K20 headers so if I get an OK from them I'll just include them all to prevent future hassle with this. Oh and I found out that the D10 header I used was wrong, I need the D5 header for the 50 MHz MCU I am using. |
|
Quick update: I got a response from Freescale telling me I should contact Keil because I obtained the header files through them. So now I wrote Keil about it… I am expecting a lot of ping-pong here but we'll see. This can only be a matter of months until it is resolved. ^^ |
|
@Farthen Could you ask them for redistribution licenses for all our other unresolved Kinetis CPU headers?
|
|
Whops, I was cleaning up and accidentally closed this. Well… I'll reopen once I have the license situation cleared. |
OlegHahm
added
the
State: archived
|
@Farthen @gebart Seems Freescale is ok with distributing the header files with the copyright header untouched. I still would prefer a proper license header but ... |
|
This is great news, now we can tick off another couple of points on the big tracker #2188 |
This adds multiple things:
This is very obviously not done yet. I am mainly creating this pull request so that people can look at the code, make suggestions and otherwise comment on the matter. As I added a kinetis_common module this would also be very relevant to the kinetis k60 port that is currently ongoing. I figured it would be easier if those drivers would reside in one directory instead of many different ones. I can split the pull requests if this is desired, I just thought that a _common module without anything to at least test build it would be more or less useless.