These use up about 78% of my Mini Pro program memory before I start. Unfortunately, I cannot do without these libraries and the board has to be a Mini Pro.
The program is finished, and sitting at about 87% memory.
The variables are using about 85% of their memory as well..... hence it throws up the usual 'might have performance issues' warning. Although, I have not noticed any yet.
My program only adds 5x variables to the mix, so not really impacting that much.
I have trimmed the code as best I can to save space.
If I add a 24LC256, it doesn't really help me unless I can move some of the variable into it that the libraries use. Is that possible?
Not sure what else I can do to save space.
I did add the code to this thread, but apparently its too long
No you cannot store and run code from the EEPROM memory on the AVR based Arduino.
The warning is just a warning and you should be able to determine if the project is stable over time. You may find it will run perfectly okay for your needs.
You could attach your code here so people might see it and offer suggestions on space saving or you may need to consider a more powerful MCU.
SteveRC2017:
Although, I have not noticed any yet.
not now, it's dynamic memory as the name suggests, it tends to go little higher and higher as the program 'runs' over time, till it gets to 100%
I once was in your shoe , guess how i solved it, my system reboots every day at 00:00 hours (my project has gsm(rtc) in it ) so that memory will never pick to 100%
KASSIMSAMJI:
not now, it's dynamic memory as the name suggests, it tends to go little higher and higher as the program 'runs' over time, till it gets to 100%
I once was in your shoe , guess how i solved it, my system reboots every day at 00:00 hours (my project has gsm(rtc) in it ) so that memory will never pick to 100%
if the code is well written, it should not leak memory and thus not need to reboot... that's not a good engineering way of solving the leak.. (even if it feels it does the job)
Don't do dynamic data allocation - or handle that part with care, don't use the String class, look at your deepest recursion / function calls stack to see how much memory will be needed on the stack... that will help you feel good (or not) about how robust your code will be.
There is nothing wrong running a system close to 100% memory capacity - as long as you stay within capacity.
SteveRC2017:
Space... pure and simple. Can't fit a 2560p in the small enclosure.
Consider a Teensy LC or 3.2. Gobs of resources, small size, and more processing power than an AVR.
It seems to run fine. I wasn't thinking of putting the code in EEPROM (well.. you can't).... just variables that the libraries were using. If possible.
You'd have to rewrite the libraries' code to transfer the variables between EEPROM and RAM as needed. I imagine that would cause a significant performance hit. Also need to consider EEPROM lifetime write limit.
If you are going to have the EEPROM library anyways, why not store constants that are used in the setup on the EEPROM?
For instance if you use a high and low limit for servos, use the EEPROM to store those values in and retrieve them at start up.
If you use Strings create a String that is used to do all the String work in and in setup assign the string buffer space; such as sBuffer.reserve( read.StringEE( xxx,xx ).toint() ). The first String assignment would be sBuffer = "" to clear the buffer and the other sBuffer workings would be sBuffer.concat( "some string" ). Using a String buffer with concat() prevents the new memory allocation issue with each string manipulation.
I tend not to use the EEPROM reads during the loop function because of the read slow down but if its not an issue with you.
For functions, pass them variables byref instead of byval, which is the default.
Any variable int under 256(7) create it as a byte instead of an int.
You might get a few bytes from using #define.
If using millis and your value of milli interval is under a byte declare that value as byte instead of as a long.
If you work with char and have randomly assigned a char buff size, cause the bytes used in the char buffer to be printed out. I found that char buffers given an arbitrary number as a buffer size are assigned too much memory; don't forget that char buffers require an extra memory space.
When running your program and not connected to a Serial-show-me-info-on-a-screen comment those Serial prints, out and the Serial creation in setup.
Those are some of the ways, I have managed to get more space out of a Mini Pro that was tight on memory space.
SteveRC2017:
I considered a Teensy... never used one. But, I read they did not work with many libraries and that is BOUND to cause me issues!
They actually work with most libraries. You could get an idea by installing the Teensyduino extension to the Arduino IDE and attempting to compile your code. Will cost you nothing.
SteveRC2017:
No point it rebooting.... it will only ever run for 20 minutes at a time tops.
Unless it is a critical system I would not worry to much if it works okay for the short durations your using it.
As someone else mentioned the main thing that would make the system unstable is dynamic memory allocation as it can fragment memory and the String class is the main culprit for this though maybe the libraries may use malloc(). If you can avoid Strings and just use char arrays instead then you will probably be safe.
Other things besides using the F() macro to save RAM space is to only use the data size needed (don't use an int for a value that will not go above 255, long for values less than 65536 etc), unchanging values should be defined as const so they don't consume RAM (not sure if compiler is smart enough to do this for unchanging values but to be sure define them your self)
It may be one simple thing to fix. Post your latest code.
The "multiple libraries" is only a warning. It lets you know which one it used and which one it didn't. This is only information, in case you updated the wrong one or you wanted to customize the library yourself.
Space... pure and simple. Can't fit a 2560p in the small enclosure.