What fills up the RAM in MCU - Page 1
Forum section: electronics / beginners

author: A2
author_rank: Contributor
timestamp: July 15, 2014, 03:49:02 pm
content: 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?

author: rexxar
author_rank: Frequent Contributor
timestamp: July 15, 2014, 04:30:04 pm
content: 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.

author: A2
author_rank: Contributor
timestamp: July 15, 2014, 04:44:16 pm
content: no floats.Just bunch of function called from inside. They have some specif tasks & two interrupts

author: tszaboo
author_rank: Super Contributor
timestamp: July 15, 2014, 08:58:11 pm
content: Quote from: A2 on July 15, 2014, 04:44:16 pmI think you opened too many topics in your MCU one after the other.This one is useless without code.

author: adi101
author_rank: Contributor
timestamp: July 15, 2014, 09:06:51 pm
content: Just look in the project folder for a .LST generated file.It contains a lot of information, including RAM usage.

author: AlfBaz
author_rank: Super Contributor
timestamp: July 15, 2014, 11:52:25 pm
content: Quote from: A2 on July 15, 2014, 03:49:02 pmhmm maybe you should mention that the above PIC has 64 bytes total ram

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 16, 2014, 12:03:02 am
content: 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

author: AlfBaz
author_rank: Super Contributor
timestamp: July 16, 2014, 02:06:14 am
content: 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

author: T3sl4co1l
author_rank: Super Contributor
timestamp: July 16, 2014, 04:27:22 am
content: 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

author: Skimask
author_rank: Super Contributor
timestamp: July 16, 2014, 05:49:01 am
content: 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?

author: Psi
author_rank: Super Contributor
timestamp: July 16, 2014, 05:58:56 am
content: Quote from: AlfBaz on July 15, 2014, 11:52:25 pm

author: AlfBaz
author_rank: Super Contributor
timestamp: July 16, 2014, 08:02:54 am
content: Quote from: T3sl4co1l on July 16, 2014, 04:27:22 amDon't know if that part of the statement was covered by your "sarcasm" clauseBut 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 thatfeaturein conjunction with being able to exclude or include a function from that treatment in code would almost be trivialIn 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 compiledandit's an ugly, cumbersome, user hack