Blogs | Technical Articles | Videos

When using the Micrium kernels, it’s possible for the C startup stack to be lost, thus reducing the amount of RAM available to your embedded application. This note shows how you can completely recover this valuable RAM for use as one of your task stacks.

Most embedded applications are written in C, and upon reset, the CPU is provided the address of the startup code (i.e., boot code) from the default vector table. On a Cortex-M, the vector table also contains the initial value of the stack pointer and is automatically assigned to the CPU’s main stack pointer (MSP). For the IAR toolchain (i.e., EWARM), the storage area for the initial stack is set up by the linker command file, and the stack space itself is called the CSTACK. Once the startup code completes, the MSP is generally left untouched and the CSTACK is thus used to process interrupt service routines (ISRs).

In EWARM, the size (in bytes) and storage for the CSTACK is defined in the linker command script as shown in the following statements (see your MCU’s .icf file for your project):

Memory-protection units (MPUs) have been available for years on processors such as the Cortex-M, and yet, embedded developers shy away from using them. Is it because they aren’t useful? Is it because MPUs are complex devices? Do they add too much overhead? In this article and the subsequent multi-part series, these questions and more will be answered.

In Part 1, I’ll cover MPU basics using generic concepts. Then, I’ll get into specifics using the MPU found in an ARM Cortex-M. Finally, I’ll show you how to organize your code by processes, how a process can communicate with one another, what happens when a process accesses memory or I/O outside of its assigned memory, and finally, offer some recommendations when using an MPU.

I’ll start off with a brief description of what an RTOS is and then show how an MPU fits into the picture. An RTOS (a.k.a., real-time kernel) is software that manages the time of a central processing unit (CPU) or a microprocessing unit (MPU) as efficiently as possible. Most RTOSs are written in C and require a small portion of code written in assembly language to adapt the RTOS to different CPU architectures.

Message queues can be used in a number of different ways in embedded software design. You can write fairly complex applications in which you might use message queues alone. And using only message queues can reduce the size of your code (i.e., memory footprint) because many of the other services (semaphores, time delays, and event flags) can be simulated.

Read the full article at Embedded Computing Design.

μC/OS-III has a rich set of built-in instrumentation that collects real-time performance data. This data can be used to provide invaluable insight into your kernel-based application, allowing you to have a better understanding of the run-time behavior of your system. Having this information readily available can, in some cases, uncover potential real-time programming errors and allow you to optimize your application.

Once your application performs satisfactorily and meets your real-time needs, you can compile out the instrumentation code, which would not only reduce code and data size but would also improve the kernel’s performance.

Download the white paper "µC/OS-III Performance Optimization ARM Cortex-M (Part 1)"

Download the white paper "µC/OS-III Performance Optimization ARM Cortex-M (Part 2)"

 

More and more embedded systems rely on the use of Real-Time Operating Systems (RTOSs) to: satisfy real-time requirements, reduce time-to-market, simplify development, increase code portability, and simplify development. Despite its many benefits, an RTOS also has its drawbacks, one of which is the possibility of introducing improperly assigned task priorities, stack overflows, starvation, deadlocks, priority inversions, and other hard-to-find bugs.

In this three-part series, Jean Labrosse looks at tools specifically designed to help RTOS-based application developers uncover some of these elusive bugs, identify issues and offer corrective actions. These tools are readily available yet often unknown to embedded developers.