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 (Guru79@web.de). 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.