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. 😦
You can refer to https://mbed.org/ for other programs if you guys want to try.
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
I think writing code in KDS is a better option because now I do not have to worry about any missing libraries that I might have while importing the program from mbed. I found the gpio example really interesting to start from as it already has a code defining the gpio pins and I am thinking of just blinking the LEDs on my Adafruit Neomatrix instead of using my demo program to show various patterns. I guess it is a better way to start from the basics and proceed to the advanced level. So, in my next blog I will try my best to come up with small but working code. 🙂
Why don’t you try with the uTasker project – http://www.utasker.com/kinetis/FRDM-K64F.html ?
This will allow you to add your LED matrix to it simulator and simulate and debug the operation in its Kinetis K64 simulator (in approx. real-time). At the same time it will also work with KDS so you will be able to avoid complications and complete work much faster.
Unlike the Freescale framework you can then also run the same code on almost any Kinetis part (K, KE, KL, KV, KEA) without any porting efforts (or with CW, IAR, Keil, Greenhills, Atollic etc.). See supported boards at http://www.utasker.com/kinetis.html
The project also includes KBOOT support for all boards, plus USB-MSD (or SD card loading, or AN2295 Freescale Developer’s Serial Bootloade, or HIDBootloader.exe) at the same time and much more. This means that it is years ahead of Freescale’s own developments 😉
LikeLiked by 1 person
How AD works!?
How PWM works!?
How DMA works!?
How the Interrupt source works!?
Something simple… but try not to use the Process Expert
Use the native Registers of FRDM-K64F
LikeLiked by 1 person
I always think its a pretty bad idea to try and import mbed libraries to bare metal projects. Isn’t mbed written in C++? It’s great if you are adopting mbed, but porting mbed to KDS does not seem introductory at all. What you have chosen to do [start from scratch] is great. I have never used Kinetis SDK. I mostly use Processor Expert, or do bare metal code based on the manufacturer’s .h file provided for the chip. Its pretty easy. Another great way of learning about the ARM architecture is to try and mix C and assembly code, like write some functions in assembly and call them in C, when you need to optimize some parts of the code.
In my experience, using mbed code or project has been problematic. Same for Arduino projects. They are good as inspiration point, but I have never seen any of these projects going beyond the hobby or pre-hobby stage. I agree with Karibe: using Processor Expert or simply plain C gets me far faster to a working point, and I can use it in real and industrial projects. The Kinetis SDK has potential, at least it is plain C code. It is only that the Kinetis SDK is hard to learn and rather complex if you do not have experience with it. I have not used the Adafruit NeoPixels with the Kinetis SDK yet (and I’m even not sure if this would be possible at all). I had the NeoPixels working with Processor Expert without any issues.
The problem I, as a beginner in the ARM world, have,
is to get a starting point for simple projects
with the aim to understand the CPU.
What does I mean with a simple project, GPOI In/Out
(control a LED and read the status of a switch),
call a function by a interrupt triggered from a pin change
and to use a RS232 interface to send and receive data
to and from the cpu.
As a beginner the ARM world seems to be extremely complex,
because you have to make so many decisions at the start.
The easiest decision for me was to avoid the use of mbed,
because that’s obviously not what I was looking for
and I think it’s counterproductive to use
if your goal is to get a better understanding
how the things work behind the scenes.
But the next decisions are harder, did I realy need the help
of a SDK with such a complex CPUs like the Cortex-M
even for simple projects and if the answer is yes
should I start with the Kinetis SDK or should I try
to use CMSIS, which I found out is although a SDK
for the Cortex-M CPUs but with a general approach
and not vendor specific like the Kinetis SDK.
Or is it possible to reach my aim with plain C code?
even as a beginner and even with such a complex CPU like
the Cortex-M as a target, then I think I would prefer
to go the plain C way.
And my last question, what’s the mysterious Processor Expert?
Is it something like a header and macro generator
that connects names with bits of registers and memory adresses,
that I can use later to make it easier to address the gpio pins
from my own C code?
LikeLiked by 1 person
I understand your pain: I was in the same situation a few years ago. These ARM Cortex microcontrollers are by hundreds of factors more complex than simple 8/16 microcontrollers. I grew up with 68000, HC05, HC08, HC12 and many more. But these ARM cores are much more powerful, but the same time much harder to understand and use. And even worse: the Cortex A series is even more complex. So to some extend, there is a big need for vendors like Freescale etc to provide easier way to get started. That’s why all these ‘SDK’s, ‘ware’ and similar exist. Understanding GPIO/LED toggling is a great start. But in the ARM world only the core from ARM is about the same: everything else around (GPIO, UART, I2C, …) is completely vendor specific. So if you ‘know ARM’, then you know the core instruction and things like NVIC (nested vector interrupt controller), but not all the other things. Talking about vendor specific SDK’s: there is one SDK pushed by ARM (CMSIS-DRIVER), but I do not see it getting any traction anywhere: every microcontroller vendor fears that with this he cannot differenciate from the others, so everyone (STM, Freescale, NXP, to name a few) do their own thing. The good thing is that you can do things with plain C. But again, all the peripherals are vendor specific, and not portable. Even not portable in most cases between devices from one vendor.
About Processor Expert (http://www.freescale.com/ProcessorExpert): this is a tool which performs device/peripheral initialization, is able to configure drivers and to generate source code. It even has a technology included which is named CDE (Component Development Environment). It is a great tool (I use it a lot), because it allows me to keep my code (at least within the Freescale world) compatible between devices. I do not need to read the reference manuals if I do not want, as long as I have a understanding how the hardware works. If you want to control and know every single bit of your device, then this is probably not what you want, because it provides an abstraction of the device. But it provides normal C source code which you can take ‘as is’ or modify for your needs.
I hope this helps, otherwise let me know and I try to provide more insights.
LikeLiked by 1 person
>>such a complex CPU like the Cortex-M
In fact the Cortex M4 is very simple (for the user) – really there are only a few registers that need to be understood.
The complexity is in the peripherals that are in the chips. These can be quite complicated to control – plus there are often software protocol stacks on top of the drivers before they can actually be used.
Cortex M4 code will essentially run on any Cortex M4 processor (from Freescale, Atmel, ST-Micro, Ti etc.) but the peripheral code will not and needs to be re-developed for each one.
as an update, I made some progress last night. I have now the FTM0 working and it is able to trigger DMA requests to the GPIO pins. So the raw concept of driving the NeoPixels with the FRDM-K64F board is working. Now it is all about the details to get the timing right. I should be able to post an article about this shortly (I hope).
LikeLiked by 1 person
Hey Erich, that sounds great! I think that will be really helpful to see the raw concept for driving NeoPixels from FRDM-K64F!! 🙂
It is the same concept and approach as described in https://mcuoneclipse.com/2014/11/10/neoshield-ws2812-rgb-led-shield-with-dma-and-nrf24l01/. But I had to translate this into the Kinetis SDK language.
Unfortunately, using the Kinetis SDK is much more difficult and complex than using Processor Expert (as I did in that post with the FRDM-KL25Z).
With the FRDM-KL25Z I only had to understand Processor Expert (which is easy) plus understand how DMA works on the KL25Z (which was OK). But now on the FRDM-K64F there is the additional complexity with learning and understanding the Kinetis SDK. I don’t know if others have the same feeling about this, but it was definitely not as easy as before, so I feel with you that you did not make much progress 😦
LikeLiked by 1 person
Erich,Thanks so much for understanding! I can totally agree with you that using Kinetis SDK is much more difficult and complex. I was working out running the simple hello_world program and then turning the LED on with KDS and Kinetis SDK 1.2.0 for FRDM-K64F. I was stuck at the debug configuration though I am working on it. I was wondering to transfer the control from SW2 to turn on the NeoMatrix board instead of the LED on the board.Though I am having few problems in that! I hope if anyone else is trying do feel the same!! 😐
I know of two projects using Freescale processors, neither of which used either Kinetis SDK or Processor Expert.
One, the PteroDAQ data acquisition system, uses the KL25Z development board with code written using the mbed tools. (https://bitbucket.org/abe_k/pterodaq/wiki/Home)
The other was a price-sensitive device using a KL02 processor with the coding done with just the gnu ARM compiler—no software development kit. All the SDKs (even the “bare metal arm” one) had too much crap in them, resulting in very bloated code. With only 8kB of flash, code bloat is a serious problem. The bare-metal ARM code is good to look at for figuring out how to do things like starting up the clocks though the complicated state machine. The code from the other SDKs is nearly impenetrable tangles, layered so deep that it is nearly impossible to take just a little of it.
I’ve done almost all my coding with the mbed compiler, since I’m working with the KL25Z boards which have an enormous 128kB flash, which I never come close to filling.
Pingback: Tutorial: Adafruit WS2812B NeoPixels with the Freescale FRDM-K64F Board – Part 1: Hardware | MCU on Eclipse
I have a couple of the K64Fboards and I have been looking for a usable toolchain to program them. When I got the boards, they were pushing mbed, but I looked into that enough to know it was not for me. I see references about to UTasker and I am looking into that. You also refer to a Freescale SDK and I visited a page at: