Author Topic: What fills up the RAM in MCU  (Read 4716 times)

0 Members and 1 Guest are viewing this topic.

Offline A2Topic starter

  • Contributor
  • Posts: 44
What fills up the RAM in MCU
« on: July 15, 2014, 03:49:02 pm »
I am using PIC12F675 in my code & MPLAB with Hitech C.

In my entire code I am using 7 bytes varaibles as global, rest all are local.
But my data space is 32 bytes after I build the code finally.

1. So what is filling up the RAM?
2. How to know what is the stack size gone?
 

Offline rexxar

  • Frequent Contributor
  • **
  • Posts: 439
  • Country: us
    • Forever Tinkering
Re: What fills up the RAM in MCU
« Reply #1 on: July 15, 2014, 04:30:04 pm »
It's a bit hard to tell you what your code is doing without seeing it...

You aren't doing any floating point operations, are you? I've ran into the situation before where floating point operations chew up large chunks of RAM.
 

Offline A2Topic starter

  • Contributor
  • Posts: 44
Re: What fills up the RAM in MCU
« Reply #2 on: July 15, 2014, 04:44:16 pm »
no floats.

Just bunch of function called from inside. They have some specif tasks & two interrupts
 

Online tszaboo

  • Super Contributor
  • ***
  • Posts: 7314
  • Country: nl
  • Current job: ATEX product design
Re: What fills up the RAM in MCU
« Reply #3 on: July 15, 2014, 08:58:11 pm »
no floats.

Just bunch of function called from inside. They have some specif tasks & two interrupts
I think you opened too many topics in your MCU one after the other.
This one is useless without code.
 

Offline adi101

  • Contributor
  • Posts: 17
Re: What fills up the RAM in MCU
« Reply #4 on: July 15, 2014, 09:06:51 pm »
Just look in the project folder for a .LST generated file.
It contains a lot of information, including RAM usage.
 

Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2183
  • Country: au
Re: What fills up the RAM in MCU
« Reply #5 on: July 15, 2014, 11:52:25 pm »
I am using PIC12F675 in my code & MPLAB with Hitech C.

In my entire code I am using 7 bytes varaibles as global, rest all are local.
But my data space is 32 bytes after I build the code finally.

1. So what is filling up the RAM?
hmm maybe you should mention that the above PIC has 64 bytes total ram
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21609
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: What fills up the RAM in MCU
« Reply #6 on: July 16, 2014, 12:03:02 am »
RAM gets used up very quickly in C.  All variables are placed in RAM, even constants.  This may vary with platform, but because ROM is usually accessed differently from RAM, special calls are needed to use it.  Constant variables are initialized into RAM by an auto-generated program that runs before main().  Every function call uses at least one position on the stack, which is dynamic, not allocated, so you won't even see it in the listing.  The size of many variables depends on the platform; an int might be 32 bits or only 8 (you should only ever use uint8_t and similar types which are fixed size).

I don't know anything about PIC compilers, if they cover any of these issues or not.

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2183
  • Country: au
Re: What fills up the RAM in MCU
« Reply #7 on: July 16, 2014, 02:06:14 am »
I don't know if things have changed with their new compilers but I recollect being able to stipulate stack size to which the compiler would ignore any limits and simply grow it into the data section
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21609
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: What fills up the RAM in MCU
« Reply #8 on: July 16, 2014, 04:27:22 am »
Well, most embedded architectures, come run time, the stack is just a pointer into memory... allocation, what's that?  In general, the compiler has no way to possibly control that -- not without severely hindering performance, anyway (checking the stack pointer before or upon entering each and every function -- because, I mean, who even checks their array bounds anyway, come on, really?... </sarcasm>).

Most advanced architectures (anything with an MMU, virtualization, etc.) can support implicit memory allocation, but the kernel needs to set it up in the first place, and needs to actually do something about it to matter (i.e., usually terminating the program at fault and popping up a dialog box, or at least resetting).  An example like MIPS or ARM, or even just good old fashioned DOS on a 486, most of the time the user's going to have kernel mode control and a flat, unrestricted memory space anyway.  (It literally wan't until 2000 (Win2k, WinXP) when mainstream PCs finally started to use properly isolated user space.  And that's PCs, on a family that's supported full virtualization since the 386 was introduced in 1985.  Virtualization itself having been invented, and implemented, even farther back than that, in supercomputer architectures.)

Tim
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline Skimask

  • Super Contributor
  • ***
  • Posts: 1433
  • Country: us
Re: What fills up the RAM in MCU
« Reply #9 on: July 16, 2014, 05:49:01 am »
Stack is only 8 "levels" deep in the PIC12F series.  7 calls without returns and you're done.

The real question is WHEN is the O/P gonna post the code?
I didn't take it apart.
I turned it on.

The only stupid question is, well, most of them...

Save a fuse...Blow an electrician.
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9889
  • Country: nz
Re: What fills up the RAM in MCU
« Reply #10 on: July 16, 2014, 05:58:56 am »
hmm maybe you should mention that the above PIC has 64 bytes total ram

 :-DD
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2183
  • Country: au
Re: What fills up the RAM in MCU
« Reply #11 on: July 16, 2014, 08:02:54 am »
Well, most embedded architectures, come run time, the stack is just a pointer into memory... allocation, what's that?  In general, the compiler has no way to possibly control that -- not without severely hindering performance,
Don't know if that part of the statement was covered by your "sarcasm" clause ;)
But there's usually one of the registers dedicated to the current stack position (sp). It would take no more than 3 or 4 compiler generated assembly instructions to compare it with a stack limit (minus some safety buffer) and throw an exception.
A simple command line invocation for globally adding or removing that feature in conjunction with being able to exclude or include a function from that treatment in code would almost be trivial

In GCC at least I'm sure there is an option to add "pre-curser" code to a function that get's executed before the function itself is called but that's moot as lib funcs are already compiled and it's an ugly, cumbersome, user hack
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf