Hey falks,
I have a question: is it too bad if my code is too large ?
Or doesn't this matter at all, beause the IC is checking all RAM-places, even the empty space ?
If it is too large, it won't fit into memory, as you will see in the error message.
2 Likes
I can speak for a ESP8266 but when I was using an Arduino UNO I ran into random problems when running a sketch where my code was close to the limit without reaching the limit. I think it is a good practice to try and avoid getting close the allows space.
1 Like
Code goes in program memory, not in RAM.
It is indeed wise to keep well under the maximum of RAM usage, even for very small programs.
1 Like
The processor doesn't care what it's doing. It executes code at full-speed all of the time even if it's running NOPs (no operation instructions) or in a "do nothing loop" waiting for something to happen.
The exception would be if it's in a "sleep" or "low power" mode.
Most likely a different problem. The code goes into flash and it's normally "fixed" and if it fits, it fits. RAM usage can vary depending on the what the program is doing.
The bootloader also lives in flash, and I'm not sure if the "reported available space" takes that into account...
1 Like
Okay, but I do I know how much RAM is used by my code ? Could it be like this: the more variables I use, the more RAM is used ?
Sorry, just a wrong word from me. I know that is stored in Flash.
The IDE publishes an approximate report of RAM usage when when you do "upload".
Any dynamically allocated buffers (such as used by TFT displays and SD library file operations) and stack usage by function calls are not reported. Stack usage rarely exceeds 100 to 200 bytes.
1 Like
Thanks man 
Never seen to "repor of RAM usage"
As mentioned by @thetatek4 above, RAM usage can sneak out of bounds ar ‘run’’ time..
Apart from direct storage of variables etc, two other ‘reserved’ areas, known as the heap and stack, are managed by the processor to coordinate library calls and returns from functions,
There is no hard rule, other than analysing the memory map, but in a reasonably complex program using more than 80% of RAM at compilation may become risky with the potential for unexpected behaviour or crashes.
In a very simple program, with little use of functions etc, 90% or more is quite safe. Remember any library calls behind the scenes will still use the stack.
1 Like
Typical report for Arduino Uno: RAM=Dynamic memory
Sketch uses 3750 bytes (11%) of program storage space. Maximum is 32256 bytes.
Global variables use 235 bytes (11%) of dynamic memory, leaving 1813 bytes for local variables. Maximum is 2048 bytes.
1 Like
WOW man Since now, I only look at 100% uploaded part
The processor is a dumb thing, it does only what you told it to do, not what you thought you told it to do. It keeps executing instructions, if it is invalid code it will do something weird but that is upto the software engineer to be sure that does not happen. When it goes to a function it saves information in memory pointed to by the stack pointer. If you have something there it does not know and does its thing. Later when it tries to use that memory that has been overwritten it will make decisions on what is there not what was there. Also part of that information is the return address that it goes to when finished, change that and it will go where the new address is. Code is in FLASH, variable information such as return address etc is kept in RAM.
2 Likes
Okay Thanks man. I will look carefully for the RAM usage. As I used to say: "never say, that you 100% control of your IC, because there are allways some unknown thinks you don't know".
1 Like
Okay, but this should not happen, right ? Or could this happen, if I overload the RAM ?
Okay, but: does the processor really allways, and I mean allways do, what you are telling him to do ? Or could for example an electro magnetic disturbance fail the processor ?
Someday, I will be an ultimate master of the ESP8266... but it will take time and experience.
If so, you will see program malfunctions, like printing nonsense, or the MCU simply becoming unresponsive.
1 Like
The processor always does what it is told to do, that is not to imply it will do what you tell it to do. If it did not do what it was told it would be a useless device. Companies use these and measure failures in the PPB (Parts Per Billion) range. The electromagnetic disturbance will not change the processor, it will corrupt what the processor is reading or writing and it will proceed according to that information. It can corrupt the actual state machine of the processor and it will interpret an instruction differently. It is also possible it will damage the processor, it all depends!!!
It is the responsibility of the design team to protect the processor from these nasty things. If you follow this forum you will find you are far from the only one with this type of problems. The guidelines etc for the processor are in the data sheet. The same processor chip can be used in millions of different applications all in different environments, that is what the design team has to consider when doing a design. That is also why an annotated schematic is requested when trying to solve a problem.
This nasty stuff can be conducted in by any connection to the processor, radiated in through the case of the processor etc. They are defined as conducted and radiated, telling the difference is generally very difficult until you have experience and then it still can be hard to solve.
The software engineering portion of the team is to be sure the processor does not exceed its bounds and always has good instructions to follow.
2 Likes
I quote Murphy's Law but when i code, unknowns are to be removed if not eliminated.
It is very possible to develop bug-free code. It just gets harder with non-trivial code and/or loose specs.
If you want to count misuse as a thing you don't know then yeah, Murphy Applies!
1 Like
Okay, I understand. thanks man.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.