freeRTOS for Cs with huge address space

nobody wrote on Wednesday, February 16, 2005:

Hello everybody,

as I already mentioned in several threads I’m working on a port to C167CR (Infineon).

Now there’s an issue that does not appear in the existing ports and I want to discuss it here. I propose changes in the OS itself and I will try to make clear, that the changes do NOT affect existing applications and ports.

The 16bit Controller C167CR has a very large address space. This full 16Mbtye-space can be covered with RAM. It also explicitly supports the utilisation of so called user stacks. This user stacks can be used instead of the system stack, because the system stack pointer is not capable of addressing the whole memory. Furthermore the memory is segmented in memory pages, which can be addressed via Data-Page-Pointers.

freeRTOS uses one memory allocation scheme for allocation of task-stacks (system stack type) and memory for user objects (general purpose type). User stacks (user stack type) are not supported.

The system stack memory type has to stay inside the borders defined by the stackpointer SP of the microcontroller. The user stack type may be anywhere in memory but may not contain any page-crossings. Finally the general purpose memory type does not have any constraints.

I developped a memory allocation scheme, that allows the allocation of the correct type with freeRTOS. The user (as the person who makes a port) has to define 3 allocation, free and init functions, one for each memory type. The kernel now uses the correct allocation function. The application programmer does not see this changes - he can just use pvPortMallov as he always did.

Another point of my development is the scalable extension - all changes I proposed above (as well in the kernel, as in the portable-interface) can be scaled away via conditional compilation. When the developper wants to use the AVR for an example, he can scale away the triple-allocation scheme and the use of user stacks. Code size is NOT increased in comparison to the traditional kernel code.

As you see, my proposal is rather a "can" then a "must" extension. In that way freeRTOS can advance to more powerfull microcontrollers in way consistent to prior development.

If you have any questions, please ask me here or per mail ( I’d also like to discuss possible changes here.

Regards, Daniel Braun

P.S.: I used the kernel with the above mentioned modifications as a framework for further research in resource managment and successfully tested a complex application.

nobody wrote on Wednesday, February 16, 2005:

Does this mean that all the changes you have made are within the memory allocator?  Or are there changes to the kernel itself, for example the TCB structure?

nobody wrote on Wednesday, February 16, 2005:

There are extensions in the TCB, the calling conventions of some functions (kernel)  and the code had to be extended in several places. Conditional compilation makes the code to look like standard v2.6.0 - kernel or behave different.

The use of the conditions is hardware dependent in my case. Complete transparency is guaranteed to the user.

Regards, Daniel Braun.

rtel wrote on Wednesday, February 16, 2005:


Marcel (writing the WizC port) has a similar issue where he needs to add an extra few keywords to each task function definition, and is proposing a macro for the purpose.

We need to be careful about adding code specific to one target or compiler as the source could quickly become less readable.  However, it sounds like what you are proposing will be suitable.  We need to asses the best way of accommodating everybodys requirements in the least intrusive manner.

Marcel has added a feature request (through sourceforge), could you do the same with your requirements  both this change and the pxQueue / void* issue.  You could just reference the relevant thread in this forum so you dont have to write them out again.  This way everything will be in one place and I won’t forget anything.  I am hoping the next FreeRTOS 2.6.x release with the H8 port will be available very shortly - its already running and is being tested but things are a little hectic at the moment.  Following this we can do a 2.7.0 release with the required kernel changes where deemed desirable.


nobody wrote on Thursday, February 17, 2005:

Hi again,

I will send a feature request. I’m a little busy right now, as my work at the university comes to and end this days. I have to rework some things in code construction, to present it here in good way. I’ll be on vacation the next two weeks also.

I don’t know your version scheduling. I know it would be nice to have my extensions in the next version, but I can’t say if I find enough time to do it before friday evening (UTC+1). I’ll do my best.

Regards, Daniel Braun
eMail :