Best way to load the ELF image on a FEZ Panda II

Archive
1

Hi,

Being used to working with the ChipworkX I learned a hard lesson about restricted resources today :smiley:

Anyway,
At first my elf image was about 52kb, then after passing the -Os and -g0 options to the compiler,
I got reduced to about 39kb.

Later I noticed that the use of constants and the use of long variable names also increases the size of the image. The constants… that made sense… but the variable names?

Why doesn’t the compiler simply convert them to something very short so the code can stay clean
while keeping things small ?

I mean is this why C developers write ugly looking code?

So I have a few questions here

  1. What can I do to keep my elf image as small as possible, do I really need to write ugly code?
  2. What is the best way to load the bytes of the elf image, as I’m always running out of memory. Even if I use Debug.GC(true) before and after loading the bytes using File.ReadAllBytes
  3. What is the max size of en elf image that can (in your experience) be loaded on a Fez Panda II
2

Let me combine your questions in one answer. Panda (USBizi) has 40KB of RAM, ChipworkX 64000KB of RAM. So it maybe necessary to think really deep into how to optimize everything, even in making hte code not so pretty :slight_smile: Even if you were able to load the RLP bits into RAM, there is only 10KB reserved on USBizi for RLP.

3

I think I can work around that if I have to.
I’m just surprised the compiler doesn’t change the variable names,
and now I’m wondering if after all these years I’ve finally figured out why C developers write code that looks just … ugly :slight_smile:

Anyway, given what I will use the Panda for, I might not need RLP at this time.
Oh btw… I got a full green light to build our next projects on top of GHI hardware (mainly the chipworkX for large traffic guidance systems and the panda for traffic signs).

4

That is some great news. We thank you for supporting us.

5

With a little effort you could import the binary directly into usbizi not the elf, but you must provide the address of each function. This should reduce size a lot.

6

Yes direct binary should not have variable names.

7

I’ll look into that, thnx

8

Hi,
tell the linker to remove all symbols.
LDFLAGS+= -s

This brought my elf file from 15kb to 5kb.

mark

9

Nevermind. Just saw it strips all symbols and thus the elf cannot be loaded anymore :slight_smile:

10

A good way I’ve found is to use strip and delete all the non-global symbols.

Something like this on your makefile should significantly shrink the elf:

arm-none-eabi-strip -x $(OUTFILE).elf

Of course, YMMV and all that, but so far it was worked fine for me with no problems finding the function entry points.

11

good to know, will give it a try.

12

hi,

I am trying to optimize my elf and I want to try direct binary, how it works ?

Or if I delete symbols I have to find method with its address, how can I know the address of my methods ?

Thank you :wink:

13

You will need to look into the map file generated by the compiler.

14

My error is the following:

c:/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.0/../../../../arm-none-eabi/bin/ld.exe: ../Resources/RedpineWifiDriver.elf section `.bss' will not fit in region `SDRAM'
c:/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.0/../../../../arm-none-eabi/bin/ld.exe: region `SDRAM' overflowed by 8 bytes

If I tell the linker to remove all symbols ( -s ), it doesn’t change anything. Is it possible to optimize this problem ?

I want to try direct binary, but, is it the elf file that we have to copy with GHIElectronics.NETMF.Hardware.LowLevel.AddressSpace class ?