How to create a list file?

[lpcware]

Content originally posted in LPCWare by RA1981 on Sun Aug 21 00:21:49 MST 2011
Hi,

I wonder if it's possible to create a list file with more details than the map file.

Especially I'm interested in how much memory a function needs and how the memory footprints of structs look like (e.g. checking if there are gaps between struct members, etc.).
Is there a way to get a detailed list file?

Regards,

Ralf

[lpcware]

Content originally posted in LPCWare by RA1981 on Wed Aug 24 09:43:13 MST 2011

---

Quote: CodeRedSupport
Sorry, you read a little too much into my statement here. This is a personal "wish list area" for me, but it is not an area where you are likely to see new functionality within LPCXpresso in the near future.

---

Don't worry, I didn't read to much into it (that's why I wrote it with a smilie).

---

Quote:
I just did a compare and contrast of the entries for the structures in the map file.

---

Mmmmmh.... For me the map isn't very detailful, that's the reason for this thread, but maybe I read the map file wrong...

---

Quote:
You want to be slightly careful of using 8 bit variables. Remember that we are talking about a 32-bit processor here, and 32-bit variables are the most efficiently handled from the generated code viewpoint. With 8-bit variables, you will often end up with additional code (for example, shifts). Thus your saving in RAM space may get offset by the increase in your code size in flash.

---

I know about the disadvantages using non-32-bit variables on a 32-bit MCU, but... if I understand it right this means: if I need a buffer with 1k entries, where each entry is only a byte value it would cost me half the RAM of a LPC1114 if I use 32-bit width variable type. Okay, this example is maybe a bit oversized, but in fact I'm right, right? :eek:
Or could such a case be solved better?

---

Quote:
[ There is a paper which includes some information on this here:
http://www.eetimes.com/design/embedded/4210470/Efficient-C-Code-for-ARM-Devices?pageNumber=1
Although this is focussed on ARM's RealView compiler, much of it equally applies to gcc.

---

Thank you, I'll read it :)

---

Quote:
But what is best for your application is really down to your own experimentation and system resources.

---

The best for my application is to get experience with the NXP devices and the LPCxpresso environment ;)

Regards,

Ralf

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Aug 24 00:12:50 MST 2011

---

Quote: RA1981
'Currently' means that this might be the case in the (near) future? ;)

---

Sorry, you read a little too much into my statement here. This is a personal "wish list area" for me, but it is not an area where you are likely to see new functionality within LPCXpresso in the near future.

---

Quote:

How to get the size? Use the C sizeof-Operator?

---

I just did a compare and contrast of the entries for the structures in the map file.

---

Quote:

Okay, I understand why it's not a good idea to pack it, but most of my projects data are mostly 8-Bit variables, so it would be wasting memory without packing (especially when large arrays are used and in this case with caution to the stack).

---

You want to be slightly careful of using 8 bit variables. Remember that we are talking about a 32-bit processor here, and 32-bit variables are the most efficiently handled from the generated code viewpoint. With 8-bit variables, you will often end up with additional code (for example, shifts). Thus your saving in RAM space may get offset by the increase in your code size in flash.

[ There is a paper which includes some information on this here:
http://www.eetimes.com/design/embedded/4210470/Efficient-C-Code-for-ARM-Devices?pageNumber=1
Although this is focussed on ARM's RealView compiler, much of it equally applies to gcc.
]

But what is best for your application is really down to your own experimentation and system resources.

Regards,
CodeRedSupport

[lpcware]

Content originally posted in LPCWare by RA1981 on Tue Aug 23 09:33:14 MST 2011

---

Quote: CodeRedSupport
I'm afraid that there is no [B]currently[/B] of extending the map information generated in these ways with the LPCXpresso IDE.

---

'Currently' means that this might be the case in the (near) future? ;)

---

Quote:
With regards to stack space, then the "simple" way to check this is to use "memory painting" - which basically involves initialising memory to a known value then looking at how much of this has been overwritten after running your code for a period of time.

---

Okay, my question doesn't target the stack space initially because I thought the linker would give me a warning if there's not enough stack space. If this is not the case I'll use your suggested approach.

---

Quote:
NXP also have a stack usage monitor example in their code samples that you might want to check out.

---

I'll search for it, thank you for the hint :)

---

Quote:
With regards to checking for how much padding your structures are using, one possible way to doing this would be to do a build as normal, and record the size of your structures. Then rebuild with the "[FONT=Courier New][SIZE=1]-fpack-struct[/SIZE][/FONT]" compiler option and compare the size of the structures.

---

How to get the size? Use the C sizeof-Operator?

---

Quote:
Note that I would not recommend the use of the "[FONT=Courier New][SIZE=1]-fpack-struct[/SIZE][/FONT]" for general usage due to the code size and performance overheads this can cause. However there are some  circumstances where you may need to make use of it - for example for  accessing data coming in from peripherals. If you want to pack your structures, then you would also be better off using "[FONT=Courier New][SIZE=1]__attribute__((packed))[/SIZE][/FONT]" to more finally control what you are actually packing....

---

Okay, I understand why it's not a good idea to pack it, but most of my projects data are mostly 8-Bit variables, so it would be wasting memory without packing (especially when large arrays are used and in this case with caution to the stack).

Regards,

Ralf

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Aug 22 01:20:49 MST 2011
I'm afraid that there is no currently of extending the map information generated in these ways with the LPCXpresso IDE.

With regards to stack space, then the "simple" way to check this is to use "memory painting" - which basically involves initialising memory to a known value then looking at how much of this has been overwritten after running your code for a period of time.

NXP also have a stack usage monitor example in their code samples that you might want to check out.

With regards to checking for how much padding your structures are using, one possible way to doing this would be to do a build as normal, and record the size of your structures. Then rebuild with the "[FONT=Courier New][SIZE=1]-fpack-struct[/SIZE][/FONT]" compiler option and compare the size of the structures.

Note that I would not recommend the use of the "[FONT=Courier New][SIZE=1]-fpack-struct[/SIZE][/FONT]" for general usage due to the code size and performance overheads this can cause. However there are some  circumstances where you may need to make use of it - for example for  accessing data coming in from peripherals. If you want to pack your structures, then you would also be better off using "[FONT=Courier New][SIZE=1]__attribute__((packed))[/SIZE][/FONT]" to more finally control what you are actually packing....

http://support.code-red-tech.com/CodeRedWiki/PackedStructs

Regards,
CodeRedSupport