Free RTOS Memory Management

markreus wrote on Saturday, November 26, 2016:


I am trying to dig further in how the memory is managed in FreeRtos. I did go through the brief description given at . But I wanted to understand in deep the details of how kernel memory is allocated, what constitues of the user code etc. For example here is a nice link explaning for Linux

In essence, I am interested in understanding how FreeRtos uses message queues to transfer data. Where in the memory are the queues created and when context switch happens how is the data send to the other process throught IPC.

Hope someone can help me.


richard_damon wrote on Sunday, November 27, 2016:

On processors without a MMU (which is likely most of them used with FreeRTOS, and how it started), things are pretty simple. Everyone runs in the same memory space and everyone sort of trusts everyone as there isn’t much to do about it. Task Stacks, and the various control blocks can either be created on the ‘Heap’ (either the standard C heap from malloc/free (with a wrapping layer to keep them thread safe) or more specialize routines to hand out memory from a specialized heap, or with other calls, you can create the needed structures from statically allocated memory.

Queue copy the data given into the memory allocated to the queue on a send, and that data is copied to the receiving task on a get. That data might be a pointer to memory that is just shared. Memory also can just be shared, with maybe a semaphore or mutex guarding it from incorrect multiple access.

With a MMU, things can get a bit more complicated, FreeRTOS and privileged tasks work just the same as above, but a task can also be made unpriviledge, and then the memory it can access is limited by the MMU (it might just be write access that is limited for normal memory, I haven’t used it). The task by default with be given Read/Write access to the reagon of memory allocated to its stack, and it can be given read/write access to a couple of other blocks of memory for shared memory access. I don’t think it uses the MMU to perform any address translation.

Note, this is a much simpler model than something like the Linux kernal, In particular, there is no dealing with ‘virtual addresses’, the MMU is generating protection rings, not remapping memory. Tus there is also no concept of swap space or virtual memory.

markreus wrote on Sunday, November 27, 2016:

Hi Richard

Thanks for the reply. It is very detailed and helpful. However, I have some follow up question regarding FreeRTOS on architecture with MMU.

  1. Is there no concept of virtual memory or Vspace in FreeRTOS?
  2. We usually create memory for the Queue via xQueueCreate() from the initial code before creation of tasks. What is this initial part called? Does it have access to the entire physical memory or is it some sort of kernel space and user space divide like in Linux
  3. I have read that xQueueCreate() creates memory in the heap. But what is this heap? Is it kernel heap?

richard_damon wrote on Sunday, November 27, 2016:

  1. As far as I know, NO, FreeRTOS does not deal with ‘virtual’ spaces/memory. In part, because virtual memory is the enemy of Real-Time (the Linux Real Time extensions as far as I know just lock the real-time parts into memory), the problem is that paging in virtual memory adds significant unpredictability to timing.

  2. I just tend to refer to the stuf before FreeRTOS is started as the initialization section, or ‘Main’. When this part is running the processor hasn’t been put into protected mode yet. Kernal Space/User Space is a virtual space-ism, it doesn’t apply to FreeRTOS. As far as I know, addresses stay at their physical addresses, so there isn’t this great divide between them.

  3. The heap is the program heap. It might be the one created by the library for malloc/free, or it might be a speciallized on in heap#.c. Again, you don’t have special types of memory, so you don’t have a ‘kernal heap’

One thing to help think about it, is for a Linix model, your WHOLE program is really just a single process, and your tasks are threads. With a MMU you get a bit more seperation, and you can restrict some threads to only being able to work with limited memory, but you don’t have multi-process type operations. For example, if you delete a task, FreeRTOS can’t cleanup its resources, because it hasn’t kept everything in a neat seperate virtual space. This is a limitation you have to deal with, but it comes at the benefit of a MUCH smaller and faster kernel.

markreus wrote on Sunday, November 27, 2016:

Thanks a lot. It is very clear now.