FreeRTOS Support Archive
The FreeRTOS support forum is used to obtain active support directly from Real
Time Engineers Ltd. In return for using our top quality software and services for
free, we request you play fair and do your bit to help others too! Sign up
to receive notifications of new support topics then help where you can.
This is a read only archive of threads posted to the FreeRTOS support forum.
The archive is updated every week, so will not always contain the very latest posts.
Use these archive pages to search previous posts. Use the Live FreeRTOS Forum
link to reply to a post, or start a new support thread.
[FreeRTOS Home] [Live FreeRTOS Forum] [FAQ] [Archive Top] [July 2013 Threads] portBYTE_ALIGNMENT in heap_4.cPosted by 386 on July 5, 2013 I am wondering why is necessary to align PortMalloc blocks? My MCU is Cortex M3 / STM with 128K RAM. I have large number of small objects and lose 10-15K only for the alignments. Is there any problem if I modify heap_4.c to align at byte boundary? Probably the memory access may be slower but this is less important than memory size. I read that it is not recommended to modify portBYTE_ALIGNMENT macro because it is used for stack alignment.
RE: portBYTE_ALIGNMENT in heap_4.cPosted by Richard on July 5, 2013 “I read that it is not recommended to modify portBYTE_ALIGNMENT macro because it is used for stack alignment.” Then you have answered your own question :o) You must be allocating a *lot* of blocks to loose 10-15K in alignment padding as the current FreeRTOS release will loose a maximum of 8 bytes per allocation. The next FreeRTOS release does improve the amount of loss so blocks that are 8 byte aligned already don't loose any, meaning the maximum loss per allocation is 7. Regards.
RE: portBYTE_ALIGNMENT in heap_4.cPosted by 386 on July 5, 2013 I am parsing XML file. All dynamic data is about 47K (about 1500-2000 small objects). I tested with portBYTE_ALIGNMENT = 2 and the free memory difference at the end was about 7K - the percentage (7 of 47) is not small. Maybe it is a good idea to have heap_5.c for "economical" pvPortMalloc. Also I think it is necessary to implement PortRealloc.
RE: portBYTE_ALIGNMENT in heap_4.cPosted by Coco on July 22, 2013 Hi, I'm also interested in this topic. Just curious, Is there any specific reason to align the memory for M3 in 8 bytes (is it to resolve some issues)? I realize that the older FreeRTOS sets this value at 4 bytes.
RE: portBYTE_ALIGNMENT in heap_4.cPosted by Richard on July 22, 2013 Heap_4.c has been updated in FreeRTOS V7.5.0. “Hi, I'm also interested in this topic. Just curious, Is there any specific reason to align the memory for M3 in 8 bytes (is it to resolve some issues)? I realize that the older FreeRTOS sets this value at 4 bytes. ” The ARM ABI is to have 8 byte alignment. You probably won't notice any difference unless you start calling library functions that assume 8 byte alignment. The one that shows this up normally is calling printf() with a %f to format a double precision floating point value. Regards.
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.
|