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




Loading

AVR with XRAM?

Posted by Nobody/Anonymous on April 3, 2006
I have an ATMega128 which has 32k of external RAM; I use the GCC port of FreeRTOS using winAVR 2006*.

I'd really like to use the XRAM for things like queues etc, as well as be able to use pvPortMalloc routines to allocate memory in this region. I believe I can do this relatively easily by using the __heap_start and __heap_end linker directives. However, I would like the stacks to remain in the internal memory of the AVR. Is there an easy way for FreeRTOS to handle this? Would I have to generate an extra pvPortMalloc routine to allocate memory in the external memory (pvPortXRAMMalloc())? Or will FreeRTOS automatically allocate the stacks in the internal memory and the rest of the heap in the external memory?

Cheers,
Matt van de Werken.

RE: AVR with XRAM?

Posted by Nobody/Anonymous on April 4, 2006
Looking at the source of FreeRTOS, it seems that pvPortMalloc is not called in the taskcreate functions, although the documentation would indicate it is. The FAQ reads:

"How is RAM allocated to tasks?

To create a task the kernel makes two calls to pvPortMalloc(). The first allocates the task control block, the second allocates the task stack.

Please read the memory configuration section of the API documentation for details of the allocation scheme. "

I had interpreted this as the task creation allocates the entire stack inside the heap, however the source indicates that the stack is only referred to via pointers. So, when a task is created, the start (and end??) of the stack is retained in the (statically-allocated) heap, not the entire stack itself. So, the bottom line is I believe I am free to allocate as much heap in XRAM as I want, which will of course free up the internal ram for more stack space (to run more processes, etc).

Please correct me if I am wrong,

Cheers,
Matt van de Werken.

RE: AVR with XRAM?

Posted by Richard on April 4, 2006
Take a look at the line:

pxNewTCB = prvAllocateTCBAndStack( usStackDepth );

in xTaskCreate(). This is where the stack and the task control block are allocated - it is within the task create function.

This makes use of pvPortMalloc. You should be able to set the memory pool used by port malloc to use your internal RAM. If you then set your heap (allocated by the linker rather than the heap used by the kernel) to be in external RAM you could use the standard library malloc and free to allocated external memory, and pvPortMalloc/vPortFree to allocate memory from internal RAM.

Regards.

RE: AVR with XRAM?

Posted by Nobody/Anonymous on April 5, 2006
Thanks Richard; I hadn't looked into the xTaskCreate function in enough detail to realise it called pvPortMalloc indirectly.

Your suggestion of using the libc malloc() and free() functions to allocate memory in the XRAM while setting the pvPortMalloc function to use internal RAM is a good one. I believe that a simple __malloc_heap_start and __malloc_heap_end directive on the linker command line should fix my problem.

Am I right in assuming that the big array from which pvPortMalloc allocates memory lives in the .bss section?

On a related note, the sizes of the .bss section and the .data section, they are quite large (total 3k between them - I have a whole stack of strings I haven't moved into program space yet). Now, if the .bss section is where the task stacks are allocated, then I can surely let these grow to almost the entire memory space, minus the stack required for main() to start, I would guess. Is this a correct assumption?

Cheers,
Matt van de Werken

RE: AVR with XRAM?

Posted by Matt van de Werken on April 10, 2006
Thanks for all the suggestions, Richard; just to tie up all the loose ends, I had to adjust the linker options to get it all to work; it's now working well (I managed to put .data in the XRAM along with the rest of the heap):

Add the following lines to the Makefile:
LDFLAGS += -Wl,--section-start,.bss=0x800100 \
-Wl,--section-start,.data=0x808000 \
-Wl,--defsym,__malloc_heap_start=__data_end \
-Wl,--defsym,__malloc_heap_end=0x80FFFF

Note that the .bss start has to be explicitly defined, otherwise ld will stick it after the .data section, which is definitely not what we want (don't forget that all the stacks for each process are allocated in .bss, which must therefore be in internal RAM).


[ 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