“Learning-by-doing” is one of the core principles of my embedded systems and robotics course at the Lucerne University. For this the students apply what they learned using a robotics platform. In earlier semesters we did a Sumo battle at the end. This time the challenge was to build a remote controller plus to add the ability to explore and solve a line maze:
I’m using FreeRTOS in most of my applications. There were only a few exceptions where an RTOS has to be used in safety critical systems: there usually it is not permitted to use any dynamic memory allocation because this adds the risk that a memory allocation could fail at runtime because of memory fragmentation or memory leak. And FreeRTOS uses a dynamic memory (heap) for the task stacks and the RTOS resources including semaphore, mutex and queues.
This is now a thing of the past. This week a new FreeRTOS Version 9 was released which does not need any dynamic memory allocation anymore: it is possible now to build completely statically allocated systems with FreeRTOS :-).
Dynamic and Static Memory Allocation in FreeRTOS V9.0.0
Time is passing fast, and many components have been updated to make the compatible with the NXP Kinetis SDK V2.0. As a highlight, besides of FreeRTOS the following components are now usable with the NXP Kinetis SDK:
It has been already two months after the Feb 2016 release, and so much things are going on, so a new release was overdue. Today I have released a new version of the McuOnEclipse components on SourceForge with the following main changes and features:
Kinetis SDK v2 with Processor Expert: Now many components can be used even with the Kinetis SDK v2.0 even with the Kinetis SDK not having Processor Expert included.
Updated Segger SystemViewer to v2.32a with post-mortem and static buffer support
Updated Segger RTT to v5.10u and fixed an issue with interrupts on Cortex-M4
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:
In “Overview: From Snippets to Code Generation” I discussed several tools used in my development process. On tool which helps me a lot to get things done is Processor Expert. In this post I’ll give an overview about this tool and reasoning for the pros and cons of using it.
FreeRTOS is probably the most popular RTOS used and I love it: it is efficient, has a lot of features, simple and easy to use. But despite its popularity, debugging it with open source tools as with Eclipse and GDB is really not that user-friendly: debugging threads/tasks is a pain compared to commercial solutions. For my university classes this semester I was looking for something easy to use by my students. Finally I managed to use a GDB helper which makes things easier now: I can switch task threads in Eclipse with GDB now 🙂
This blog is a guide on how to setup using the FatFs library included with the Kinetis SDK 1.2.0 using mostly the Processor expert within Eclipse Luna. FatFs is a generic FAT file system module for small embedded systems written by Chan. I prefer to use Processor Expert when possible as this will often generate code that is smaller in size than using the KSDK library files direct. I experienced many gotcha’s and complication setting this up and wanted to share how I finally managed to get it to work.
Key to successfully implementing embedded applications these days is to have detailed visibility into what is going on with the application on the board. For this, I’m using the FreeRTOS+Trace from Percepio to inspect the runtime behaviour. Stop-Mode debugging is very useful, but visibility into the runtime is even more important. FreeRTOS+Trace is a tool to accomplish this, but it requires to dump the data off the target to the host (see “Updated Percepio Tracealyzer and Trace Library to Version V2.7.0“). Usually, I’m using the GDB debugger for this, and that works for shorter trace sequences like a few seconds. Yes, I can combine them, but it painful to stop, dump and continue. So what if I could collect trace for several minutes or hours without the need to stop the application? Why not stream the data to the host directly?
So here is it: I’m now able to get almost unlimited trace streaming off the target, witout user intervention. I can trace my application for hours 🙂