To me, software and tools are by far more important than the microcontroller. Because the silicon is a ‘one time kind of thing’, where the software has to be maintained and working over a longer time. And at least my software usually needs to be ported to a new device, so portability and available software and tools are critical to me.
The combination of MCUXpresso SDK (formerly Kinetis SDK) and Processor Expert is unfortunately not supported by NXP. But I have found a way to get them work together in a nice way, and this article is about making that combination possible :-).
SDKv2 Project with Processor Expert which is supposed not to work together
The reset and signal line of a microcontroller is probably the most important signal to a microcontroller. And if things go wrong, then a first thing to check is the reset line. So having control over reset is an important aspect for embedded development. You would think that if you download a program to a microcontroller, the debug probe would put the device into reset at the start with a short pulse like this:
One of the most important aspects for developing complex realtime applications is get insights into what is going on the target. Segger just has released a free tool which gives an incredible useful insight view and visualization:
Hi again to all the amazing readers of this blog! Well guess what, I am still stuck with the programming code of my NeoMatrix Demo. I think it all started with a bad choice of importing the program and libraries from the mbed to KDS. 😦
Well in my last blog I told you about importing the projects and then building them. Well that was what I was trying to do but it turns out that it is not a good idea. I still have a compilation error which is there probably because of a missing assembly. Debugging the code can sometimes be really frustrating for me. 😐 So, I have decided to start from the scratch and write the code in Kinetis Design studio with the help of the Kinetis SDK. There is already the gpio example for FRDM-K64F available under the driver examples folder in KSDK_1.2.0
Getting the hands on an embedded project has always been exciting for me. So, here I am again with my blog trying to provide you with an easy to use guide for the Kinetis Design Studio 3.0.0 (KDS_3.0.0). Well, as you all know I am an intern at Freescale working for the first time on KDS, I will tell you what all we can do to start working on it with a perspective of a novice. But personally I feel KDS is one of the most encouraging IDE you can work on. So how do I start with my code for our NeoMatrix board? I am currently working with one of the demo codes for the NeoMatrix:
So, my first task is to write the code in KDS for the NeoMatrix_Demo. How do I do that? After opening the KDS 3.0.0, I need to go to File and select New and then Kinetis Project. You can see that the New Kinetis Project wizard appears once you click the File>New> Kinetis Project. Type a name and click next.
This link gives me the opportunity to download the very helpful Kinetis Software Development Kit (SDK) along with the Integrated Development Environment which includes the toolchain Kinetis Design Studio. Let us talk a bit about the Kinetis SDK in this blog. So what does Kinetis SDK is responsible for? In simple terms, it is just software framework which helps us in developing applications across all Kinetis Microcontrollers. It is a package of pre-written code that developers can re-use in order to minimize the amount of unique code that they need to develop themselves.
I believe waiting makes you feel more impatient. So here I am, waiting for my NeoMatrix 8×8 – 64 RGB LED Pixel Matrix to arrive, so that we can begin working on our cool project. But looking on the brighter side, I got some time to make the beforehand preparations for our Signboard project. I took the opportunity to invest this time in finding out how to start running the Adafruit NeoMatrix with Kinetis FRDM-K64F development board. We should definitely get ourselves ready with something so that we can test NeoMatrix with FRDM-K64F as it arrives. So I thought of setting up a repository where we can turn back anytime we feel we are stuck.
Unlike CodeWarrior, the Kinetis Design Studio (at least in V1.1.1) does not offer a choice between C and C++ projects. That makes sense with the GNU ARM Eclipse plugins, other than the CodeWarrior gcc integration, there is no need for setting up a special tool chain for C++ (see “Compiling C Files with GNU ARM G++“). While this is great, things are not perfect yet, so I’m providing in this post the information needed to properly setup a C++ project with Kinetis Design Studio V1.1.1.
Debug View of Startup Code Calling C++ Constructors
Student: “Professor, my application does not work!”
Professor: “What is the problem?”
Student: “I don’t know, but the LED on my board is not blinking.”
Professor: “Can you step through the port initialization sequence and check if the clocks are initialized correctly?”
Student: “I have pressed the ‘Run’ button, I’m not debugging”.
Professor: “Why are you not debugging?”
Student: “I always do a ‘Run’, and I do ‘Debug’ only if needed.”
Run and Debug in Eclipse
Clearly, I’m not immune to the ‘déformation professionelle‘. I very rarely use ‘Run’, because it simply does not offer much value compared to ‘Debug’ during development. If using ‘Run’ and then there is a problem, I have to ‘Debug’ anyway, why not ‘Debug’ from the beginning? It is simply not an efficient way to work for me. Or I’m missing something?