Hi Myke Predko ,
Do you want to use the MK22FN1M0Axxx12, right?
If yes, you can't refer to the FRDM-K22 board, you need to refer to the TWR-K21F120M board, as K22 series have a lot of types, you can find some information from this link:
https://community.nxp.com/docs/DOC-102548
About the TWR-K21F120M new SDK, I will help you to report your requirement to our SDK team.
Now, if you use the SDK2.3.0 for your MK22FN1M0Axxx12, any issues about it?
Kerry
-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!
- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------
Hi Kerry,
Thank you for responding.
With respect, how do you expect somebody to find the apparently random link Kinetis K22_120 MHz devices when they are starting out? If I look at Useful Kinetis Documents, discussions and questions it's not listed nor is anything approaching this listed.
As I embarked on this project, I did confer with my FAE to make sure I was selecting the correct device for the product (the MK22FN1M0Axxx12) and did ask what would be good for doing my hardware/software development and I was told "whatever, but use one with the latest SDK as it will be easier". He actually recommended the FRDM-K64F and FRDM-K22F as they have SDK 2.7.0. The TWR-K21F120M was never mentioned nor were any links discussing different options were presented.
I'm sure that NXP/Freescale engineers have spent a lot of time on the Tower boards but for doing hardware prototyping they're terrible - at a minimum you need the side boards along with the Protoboard which is mechanically unstable and quite difficult to plug/unplug as you are working on the circuitry. In contrast, the Freedom boards can take a simple Arduino prototyping board which is very mechanically stable and reliable. I can easily prototype the different systems and then integrate them together into the product (which is made easier by using FreeRTOS and merging the tasks together into the final product). For these reasons, I tend to eschew Tower boards for Freedom when I'm doing prototyping.
Here is one of the prototype circuits that I'm using for the product development:
In terms of SDK 2.3.1 issues, the big one for me is USB CDC Device - using the project wizard in SDK 2.7.0, when you select "USB device" in "Middleware" Bob's your uncle all the libraries are put in place and the clock generation tool seems to have the USB hardware clocking paths enabled. When using SDK 2.3.1, there is no selection for USB device in Middleware (but there is for CMSIS but this doesn't seem to load any hardware drivers) which meant I had to copy the driver files from the 2.3.1 FreeRTOS USB device example AS WELL AS figure out how to get clocking selected for USB. Clocking (as you will see if you look at my posts over the past six months) was a particularly nasty problem which took me literally months to figure out how to get the USB components enabled (and I'm still not sure of the process, I just bang on the clock wizard controls until they get enabled and then select the correct multiplier/divider values). For the most of this project, I copied clock_config.c/.h from the TWR-K21F120M example project as it was too frustrating to figure out how to get the USB paths working - I have figured it out, but it's only been in the last month or so.
When I have to create a new project, along with selecting the libraries I want to use, copying in the .mex file, followed by changing the size of the "SRAM_UPPER"/"SRAM_LOWER" (the need for doing will be a rant for another day) the SDK 2.3.1 process requires me to add the "osa"/"usb" folders for the USB drivers, make numerous changes to the "Preprocessor" and "Includes" of the "C/C++ Build" settings - none of which are required for SDK 2.7.0. Not a big nit, but it takes five minutes longer to create an SDK 2.3.1 project than an SDK 2.7.0 with a *lot* more opportunities for error.
There are a number of minor annoyances that I've encountered so far (like "GPIO_SetPinsOutput" which exists in SDK 2.3.1 and not in SDK 2.7.0 and the I2C/UART/SPI drivers don't work the same way between the two SDKs) but I'm bright enough to figure them out and work around them - as I said, I've changed my software architecture to place all the direct IO methods in separate files that I can swap in and out.
I don't want this to be thought of as a rant - I'm hoping that it is received as a valid complaint about the work required to port software across SDK versions for devices in the same Kinetis family. You may feel the approach that I'm taking for software/hardware development (using the Freedom boards rather than the Tower board) to be the wrong one, but I do have my reasons and it's not like there's documentation that can be easily found explaining the recommended approach. I do recognize that different devices are different and some features will work differently but I would expect the SDKs to minimize those differences as much as possible so that software can be shared between devices as much as possible.
Thank you for your consideration and understanding - in MCUXpresso with the device SDKs you have a very good set of tools. The value proposition for this approach is to minimize software development time by providing a set platform for the developer but, unfortunately, this value is lost when the SDKs across devices are not compatible and the developer has to spend long hours learning what the differences are and creating work arounds for them.
myke
