petitfs + Data Size Viewer = surprising results?

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using PetitFS on my mega32 and was running into RAM usage issues.  I stumbled on the Data Size Viewer extension (what a great extension!) and was pretty surprised by the results.

According to the extension, pf_mount is using 694Bytes of RAM.  Looking at the function... I don't see it:

 

FRESULT pf_mount (
	FATFS *fs		/* Pointer to new file system object */
)
{
	BYTE fmt, buf[36];
	DWORD bsect, fsize, tsect, mclst;

If I interpret this correctly, this function is using 1+36+(32*4) = 165 bytes of RAM not counting the stage usage in passing *fs to the function and returning the FRESULT.  Can someone point out where the other 500+ bytes are coming from?

 

 

-Adam
"Please don't judge my God by my inability to follow him" - Chris Mollins
================
www.onecircuit.com
================

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ahhhh the tool is telling me that function consumed 694 bytes of Text Segment space (code) not RAM. 

 

Is there an option to tell me how much RAM is being used?  I'm running out of RAM and am trying to pinpoint what might be the cause.

-Adam
"Please don't judge my God by my inability to follow him" - Chris Mollins
================
www.onecircuit.com
================

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you looked at the map file?

 

Cliff will be along soon to tell you to try nm - as here: http://www.avrfreaks.net/comment...

 

https://www.systutorials.com/docs/linux/man/1-avr-nm/

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Short answer:  MAP file.  For a longer answer, tell toolchain and version and optimization settings.

 

If really that short on SRAM, then have you considered moving on from the venerable Mega32?  There are two models with more SRAM in the '164 family.

 

http://elm-chan.org/fsw/ff/00ind... indicates 44 bytes of working SRAM, plus stack needs when calling functions.

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ajcrm125 wrote:
Is there an option to tell me how much RAM is being used?
Not for automatics. When you write:

{
	BYTE fmt, buf[36];
	DWORD bsect, fsize, tsect, mclst;

then those things are created at run time on the stack. It looks like 1+36 + (4 * 4)  bytes (the DWORDs are 32 bits not bytes - that is 4 bytes each) so the total usage there looks like 53 bytes in fact.

 

Some folks have written utilities (Eugene Zharkov springs to mind) that try to do this kind of analysis by looking at the source. You may want to search out such tools.

 

The usual "culprit" for over RAM usage in AVR are "const" things that could be in __flash/PROGMEM but that are placed in RAM.

 

But FatFs can be a heavy user two as it uses 560+ byte RAM structures.

 

However this is the raison d'etre for PetitFS - it's supposed to trade inefficiency for lower RAM use.

 

I thought mega32 had 2K RAM - surely that's enough even for most FatFs applications let alone PetitFS ones?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

the DWORDs are 32 bits not bytes

 

Doh... I realized that shortly after I typed that :P

 

The usual "culprit" for over RAM usage in AVR are "const" things that could be in __flash/PROGMEM but that are placed in RAM

 

Agreed and one such case I'm finding are the strings used in printf statements.  Not only do these show up in .text but in .data as well.  I had added some debugging functions which use a lot of printfs and all of a sudden my usable RAM shrunk significantly.  Now I know why...

 

 

-Adam
"Please don't judge my God by my inability to follow him" - Chris Mollins
================
www.onecircuit.com
================

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ajcrm125 wrote:
Agreed and one such case I'm finding are the strings used in printf statements. Not only do these show up in .text but in .data as well. I had added some debugging functions which use a lot of printfs and all of a sudden my usable RAM shrunk significantly. Now I know why...
theusch wrote:
For a longer answer, tell toolchain and version and optimization settings.

Are we to assume GCC?  Isn't there an option for "constant strings in flash" or similar?

 

http://www.avrfreaks.net/comment...

Most stdio functions have an equivalent with a _P suffix for PROGMEM data like printf_P() etc.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Tue. Oct 17, 2017 - 06:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ooooo this is good stuff. Thank you guys!

-Adam
"Please don't judge my God by my inability to follow him" - Chris Mollins
================
www.onecircuit.com
================

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gcc has functions like printf_p() and other functions with _p suffix that use PROGMEM strings. Also %S not %s takes strings from flash