Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training


freeRTOS for µCs with huge address space

Posted by Nobody/Anonymous on 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.

RE: freeRTOS for µCs with huge address space

Posted by Nobody/Anonymous on 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?

RE: freeRTOS for µCs with huge address space

Posted by Nobody/Anonymous on 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.

RE: freeRTOS for µCs with huge address space

Posted by Richard on 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 everybody’s 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 don’t 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.


RE: freeRTOS for µCs with huge address space

Posted by Nobody/Anonymous on 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 : Guru79@web.de

[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]

Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.

Free TCP/IP and file system demos for the RTOS

Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists