ema083 wrote on Tuesday, March 11, 2008:
Hi everybody,
I’m using FreeRTOS on a MicroBlaze; I was surprised because the OS footprint is not 3-4 KB but, on my architecture, is about 12 KB.
Is the footprint supposed to be like that? Do you have any suggestions on how to shrink it? (I’ve already set the parameters in freeRTOSConfig.h)…
With thanks in anticipation,
Emanuele
davedoors wrote on Wednesday, March 12, 2008:
I don’t know about Microblaze but that does not sound right at all. How are you obtaining the footprint size? That is, where are you getting the 12K number from?
ema083 wrote on Wednesday, March 12, 2008:
Hi,
here is the output when I compile my project:
mb-gcc -O2 code/main.c code/Source/list.c code/Source/queue.c code/Source/tasks.c code/Source/portable/MemMang/heap_1.c code/Source/portable/GCC/MicroBlaze/port.c code/Source/portable/GCC/MicroBlaze/portasm.s code/serial.c -o MB_1/executable.elf
-mno-xl-soft-mul -mcpu=v4.00.a -Wl,-T -Wl,Proj_MB_1_linker_script.ld -I./mb_1/include/ -Icode/ -Icode/Source/include/ -I. -I./code/Common/include -I./code/Source/include -I./code/Source/portable/GCC/MicroBlaze -L./mb_1/lib/
-D MICROBLAZE_GCC -Wall -Wl,-Map=rtosdemo.map
mb-size MB_1/executable.elf
text data bss dec hex filename
12136 122 19720 31978 7cea MB_1/executable.elf
I’m getting the footprint size from the “text” value… I hope this is the right way to get it…
rtel wrote on Wednesday, March 12, 2008:
Yes this is a valid way of getting the size but the 12K for the kernel is very improbable. Can you look in the map file to see which module is taking up the text, I would be very surprised if it were anything to do with the kernel.
Is you main.c using any GCC libraries? In particular anything to do with sprintf/printf/scanf? This can bring LOTS of very inefficient GCC library code into your build.
Regards.
ema083 wrote on Thursday, March 13, 2008:
My main.c is the one included in the Demo, from which I erased the demo function calls; so I’m sure I’ve not included other GCC functions. The part of the map file dealing with text is listed below (I’ve cut some lines to don’t take up too much space). If you please can help me figure out what’s wrong, I’ll be very glad… I’m not an expert on this topic…
.text 0x00000050 _start1
0x0000006c exit
0x000000e8 _crtinit
.text 0x00000170 main
.text 0x000001d4 vListInsertEnd
… OTHER FREERTOS MODULES …
0x000020e8 xSerialPortInitMinimal
.text 0x00002388 _exception_handler
.text 0x00002390 _program_clean
.text 0x00002398 _program_init
.text 0x000023a0 _hw_exception_handler
.text 0x000023a4 microblaze_disable_interrupts
.text 0x000023c4 microblaze_enable_interrupts
.text 0x00002478 microblaze_register_handler
0x000023e4 _interrupt_handler
0x000023e4 __interrupt_handler
.text 0x00002910 XTmrCtr_Reset
… OTHER XTMRCTR AND XINTC MODULES…
0x00002bb4 XIntc_SetIntrSvcOption
.text 0x00002c7 XNullHandler
0x00002c34 XAssert
0x00002c68 XAssertSetCallback
.text 0x00002c80 memcpy
.text 0x00002d38 memset
.text 0x00002de0 strncpy
.text 0x00002f2c 0x3c /cygdrive/c/EDK/gnu/microblaze/nt/bin/…/lib/gcc/microblaze/3.4.1/m/crtend.o
Best regards
rtel wrote on Thursday, March 13, 2008:
Could you send me the .map file to r [dot] barry _at_ freertos.org.
Regards.
rtel wrote on Saturday, March 15, 2008:
In the map file there is:
2888 bytes for tasks.c
2748 bytes for queue.c
268 bytes for list.c
1000 bytes for port.c
Total for the kernel is then 6.9K which is the largest I have ever seen. This must be something specific to the Microblaze architecture or instruction set inefficiencies. I should turn on the optimiser and remove unused symbols, and see what it comes down to.
You could remove quite a lot from port.c by removing the code that fills the registers with known values. You could also make functions out of some of the inline code.
In addition you have:
1548 bytes for libxil.a.
732 bytes for the USRT driver.
416 bytes for the Xilinx interrupt handler code.
Regards.
ema083 wrote on Sunday, March 16, 2008:
Thank you very much for your help!
I’ll try and see if I can shrink it a bit with your suggestions.
Thanks again, best regards,
Emanuele