I am using SD and SPI and they hog more than 50% of memory so I am getting a warning on uploading that only "451 Bytes are left for local variables" and "Low memory available, stability problems may occur."
I read about using Program Memory for variables but it seems really complicated to manage. I have stripped everything down to Constants where possible and can't get below the current 500-Bytes my part of the sketch requires when SD and SPI are not included.
Or, what can I do to make sure I don't get stability issues. So far it all seems to work OK, but...
Has anyone re-written SD/SPI libraries to use Program memory instead?
Based on info provided, you could use PFat instead of SD and only enable functions you need.
To gain flash, upload with a USBasp programmer, but you won't gain SRAM.
You need to give more info about your setup to get more usable suggestions.
e.g.
Disable Serial.print() at run-time if u don't need it.
Use F() macro to print constants.
SPI uses very little flash or RAM. SD uses a bunch but probably less than half. When I tested it on the 1.0.6 core it used about 11.5K of flash and something like 750 bytes of RAM, give or take, plus significant stack space. SdFat is more efficient. It still uses a big chunk of an Uno's memory resources but not everything. It's hard to figure out what your problem is based on what little you've written.
Thanks for the advice, sorry, can't post the code it is not mine and the guy who owns the data logger doesn't want to share. It's a data logger for a friend's chicken farm and nothing I think would be secret, but it's his code, so his say.
@jboyton: Might be time to check the latest builds. Since you say SPI doesn't take much, then it must be the SD. A compile shows 24,098 and 1587. If I rem out the SD and SPI and also the small section that logs it which is only 41 lines of code, I get 14,204 and 719 which is 868 difference and amounts to 45.% of the available memory.
My code is not the problem as you an see 719 is not a lot at 35%. I was more interested in how to get the SD/SPI chunk down as my code is pretty conservative.
@aisc: There are no Serial prints as it is only logging numeric data blind. Temp, humidity, smell etc. Oh wait, we have no smell sensors yet.
@florinc: The only Objects used are those needed by the SD/SPI. I always use Bytes where possible, been programming for 40-years and started when there was only 4K of total memory in a Tandy Model I.
I estimated 11.5K/750 for 1.0.6 and you estimated 9.9K/868 for 1.6.x. That's within ballpark. You still haven't said what your problem is. Not enough flash? Not enough RAM? Too many chickens? It's a guessing game. The fact is that you can do data logging with an Atmega328, up to a point. The compiler reports that global variables use only 52% of dynamic memory when I compile my data logger. I'd send you some RAM if I could, I've got plenty. Flash I'm short on though (92% used).
Squeezing more out of the resources is possible, up to a point. But how can we help you without knowing more? Maybe the chicken code is the problem.
Thanks, as I mention in both my above posts, I see the problem as being in SD/SPI and NOT our code. I have been unable to track down anything on PFat. There are just 41 lines of simple code writing to the SD that is eating that 868 bytes. I see that as a problem with SD/SPI.
We have control over local variables in our code, but NOT in SD/SPI so when the compiler warns of instability from low memory, I am concerned about over-run in those two libraries NOT our code. I am quite confident that our locals will happily run in 170-Bytes at any given time.
Stay calm Delta, you clearly didn't read my last post. I am not concerned about the base code of the sketch as it represents only 35% of the available memory. It is SD/SPI that I was asking for help in finding a solution to it's hogging memory.
You CAN see the code should you wish to help, it is SD.cpp and SPI.cpp. May I suggest you slow down and read all of the post before dashing off into vilify mode. And, I don't need to go tell him anything as I am betting you do not talk to your friends that way.
@aisc: I can't find anything on PFat, any links I have found are all broken. Can you please point me at where I might get a copy of the library? Thanks.
Delta G isn't being rude. He just knows you can't fix something invisible.
WaitSome:
There are just 41 lines of simple code writing to the SD that is eating that 868 bytes. I see that as a problem with SD/SPI.
SD cards require a 512 byte buffer and that's the biggest part of the RAM hit. SdFat is more efficient than SD. I compiled a basic SD logger under 1.6.x and it required ~860 bytes. The same logger using SdFat used ~660 bytes. Under the hood SdFat also uses less stack. When you get a warning about possible stability issues it's because the compiler can't figure out your stack usage. You may be just be fine with your current code and in need of some Xanax. It's hard to say.
Pfat -- probably he meant PetitFat. It's a more drastic approach but worth considering if you're really up against the wall. There have been some recent posts in the storage forum with examples of how to use that library. I suspect you just don't know what you have and what you're doing. You're probably fine using SD.
It's all hypothetical since you can't provide any details.
WaitSome:
am getting a warning on uploading that only "451 Bytes are left for local variables" and "Low memory available, stability problems may occur."
(and)
I don't need to go tell him anything as I am betting you do not talk to your friends that way.
I think you do need to. We don't, but that's because our friends are a bit more forthcoming about the problem when they need help, instead of wasting everybody's time. You would have to wonder how yours gets on with his doctor or his lawyer.
As it is, you are getting a clear message from the IDE, and you have two solutions - stop using the SD card, or get an Arduino with more memory. Maybe your friend might eventually concede that using a nano for datalogging is like sending a boy on a man's job, but I doubt it.
I had exactly this low memory problem with a Nano, in a program with lots of text output being sent to an LCD display. Some kind soul on the forum pointed out to me that there is an important difference between
lcd.print("This is a sentence");
and
lcd.print(F("This is a sentence"));
In the former case, the text is being stored in your variable memory. In the latter case, the text is being stored in the flash memory along with the program. So if there's lots of flash memory available, use it.
This may or may not be of value to you, but if you've got any text strings stored, you could recover some variable memory.
Yes, PFat = PetitFat which can download here.
Sorry assumed u would know what it was.
I am using it in one of my sketches.
Note it has the option to enable/disable read, write etc.
FWIW I use the read component only.
You will find more info about PetitFat here.
It's not worth listing all the memory saving techniques here, as they can easily be found with the search box in the upper right hand corner of the page.
Specific, targeted advice does require source code. I think it is quite obvious why.
Oscarko:
You don't need more memory, you need efficient coding.
That is rather more likely to be pompous horseshit than good advice. The cautious tone in reply #15 is well-justified and there are plenty bloodstained areas in the Arduino world where people have bashed their head against the wall while trying to get efficient software to solve what is actually a simple hardware problem. One lesson they may learn is that, even if they then solve the problem with efficient code, it will re-emerge later as the project inevitably develops. That's the way it is with Arduino.
Delta_G Great idea use Serial.print with F() macro. You saved my life! I was trying ESP8266 and SD card and DS18B20. With your method really really decreasing use of RAM. Thanks alot man.
