How to know if a Arduino has enough memory for a project

Hi,

I'm doing some home automation stuff and sensor reading with some Arduinos.
I bought a Nano for the bathroom and now I'm scared that the 32 KB are not enough.
I chose the Nano cause it's easy to integrate him into the PCB.

I have just the code i posted here now on it: http://arduino.cc/forum/index.php/topic,141240.msg1105074.html#msg1105074
So 14 KB are already gone.

But i want to see life data of my sensors on the web page, save data to the SD-Card and upload them to
the servers database.

This is what was planned:
D2 S0-Interface Electricity Meter Bathroom Underfloor heating
D3 S0-Interface Electricity Meter
D5 One Wire BUS (1 DS18B20)
D6 Flow Sensor Bathroom Sink Cold
D7 Flow Sensor Bathroom Sink Hot
D8 Flow Sensor Shower
D9 Flow Sensor Toilette

A0 (14) Reed Switch Bathroom Window
A1 (15) Push Switch 1 (Shower On)
A2 (16) Push Switch 2 (Shower Off)
A3 (17) Push Switch 3 (Bathroom On)
A4 (18) Push Switch 4 (Bathroom Off)
A5 (19) Push Switch 5 (Bathroom On)
A6 (20) Push Switch 6 (Bathroom Off)

The push switch stuff is send trough my Windows server with MQTT to another Arduino and
later i also want to change the code so that i can dime the lights.
Looks like 32 KB is not enough and i need a Mega?

PS:
Is it a good idea to start one thread for the whole project instead of spreading the stuff
where i need help and have problems over the forum? Cause this way all the code is
in one place and i do not need to copy it around and always need to explain what the
rest of the code does that has nothing to do with a particular thread.

If you know it does compile and it doesn't upload, then it doesn't have enough memory.

MrGlasspoole:
PS:
Is it a good idea to start one thread for the whole project instead of spreading the stuff
where i need help and have problems over the forum? Cause this way all the code is
in one place and i do not need to copy it around and always need to explain what the
rest of the code does that has nothing to do with a particular thread.

Well, from my own personal experience, posting your entire project in one thread results in people not reading it and just asking you questions that are answered in your post to begin with. But, on the other hand, if you post only snippets, people will ask you to describe your entire project.

Unfortunately, that's just the way it goes on forums. I prefer to have (and read) it all in a single thread. If I am interested or I think I can help, I bother to read the entire thing. If I am not or can't, then I don't.

You also run into the fact that people may not keep coming back to your thread to see that you've asked new questions when it is all in one place.

So, I don't really have an answer. Only my preference. If there is a better way, I would love to hear it, because I have asked the same question myself. What I do in some cases is post a thread about my entire project as a whole, and then post other threads asking specific questions. When people ask me to describe the project, I refer them to the other thread.

in order to save memory... make the function compress...

Depends what your coding skills are like really, memory ( SRAM ) is an important issue, but 32kb to an experienced coder is quite significant.
It doesn't help if 3rd party code takes up a large chunk of flash, but you can utilise many devices efficiently if planned out optimally.

There are also ways to see the static memory usage, ( 'avr-nm.exe -S' will give some info. )

I don't know what the interface to your electricity meter will be like, but everything else you're doing seems fairly straight forward. I doubt that program space will be a problem. RAM is a separate issue, and you would need to know how much RAM your Nano variant has and what data structures your sketch will need in order to estimate the RAM requirements.

Given a project of this complexity it would be sensible to implement it in small steps, adding functionality as you go. With that approach you can be confident that the early versions will fit in the available program and RAM space, and measure how much they're actually using as the sketch evolves to see whether you're approaching a problem.

I suggest that the best way to get help is to only post when you have a specific problem or question that you want help with, and provide as much detail as is necessary to understand that problem or question. Anything involving software will almost always involve posting your whole sketch, but you can help a lot by doing some work in advance to reproduce the problem or question in isolation in a much smaller and simpler sketch. This will help your own understanding of the problem too, and quite likely you'll find that the act of reproducing the problem in a minimal environment reveals a false assumption or mistake in your understanding which enables you to solve the problem on your own.

http://playground.arduino.cc/Code/AvailableMemory

Get the Mega. It's not much more expensive.

You can do an awful lot with the Uno provided that it is a lot of the same job. You are doing different jobs. That changes things immediately and the problems are beyond your control. Different things to be done require different libraries, and that is where the memory goes.

I can see two new libraries coming over the hill, SD and RTC. My stuff is sent to cosm for live view on the internet. In my case the cosm library was the straw that broke the camel's back, and I was obliged to move to Mega 2560.

I think it would be fair to say that, if you want to have a proper system sending data the to internet, a Uno will not suffice. It may be that some smart operators can squeeze it all in by stripping down the libraries. I have no idea about that, but I'm sure you can come to your own conclusions about the merits of such an approach.

Nick_Pyner:
Get the Mega. It's not much more expensive.

I actually bought my Mega2560 on ebay for $17 shipped. Less than I paid for my Uno. It probably isn't "official" even though they even screen-printed it all official, but it has been working fine.

I can see two new libraries coming over the hill, SD and RTC.

I failed to notice the SD lib was mentioned, right in the OP. I tested it once that it takes about 1.5 KB SRAM.

Well I did say

coming over the hill.

And when it arrives, you can be fairly sure that the code that uses it is soon to follow. It's a minor stretch of the intellect, sometimes known as forward planning. If you buy a Uno for the purposes stated and then come to regret it, remember where you heard it first.

Retroplayer:

Nick_Pyner:
Get the Mega. It's not much more expensive.

I actually bought my Mega2560 on ebay for $17 shipped. Less than I paid for my Uno. It probably isn't "official" even though they even screen-printed it all official, but it has been working fine.

Yes, Retro. I paid about $70 for my store-bought EtherTen. My Mega with Ethernet+SD shield was about $27, I think. I don't regret getting the EtherTen, but it's the sort of thing you only do once. I think type-for-type a Mega is typically about $10 more than a Uno, and that seems reasonable. The only advantage a Uno has is its size, and I imagine it will be squeezed from both ends and die a natural death - rather like the VIC-20.

I don't think so. UNO has it place and will keep its place. A carefully planned project such as on I carried out, did accomplish a lot with the SD card, RTC, and a few other things and extensive menu interface, all on an UNO. I'm not saying anyone else can easily pull this off. :wink:

The only advantage a Uno has is its size, and I imagine it will be squeezed from both ends and die a natural death

As liudr said, the Uno ( 328, 168 chips ) certainly have their place. Code will actually execute faster on an UNO, you pay a price for the convenience the 2560 provides.

The faster execution has not been evident in practice, and I doubt the OP will see it either. Convenience is hardly the word for it. The difference between being able to do the job and not being able to do the job is not a matter of convenience, it's a matter of having the right tool.

And, despite liudr's self-aggrandisement, I submit that the Uno is the wrong tool for the job or, even if it is OK now, it will be wrong soon enough.

So, in the light of the OP having no more gold stars than I do, and the minor extra cost, he/she would be wiser not to bother with a Uno.

Nick_Pyner:
The faster execution has not been evident in practice, and I doubt the OP will see it either.

On a large project the difference can be significant.
The 2560 for example is slower at branching. And jumps do not have to move to far locations on the Uno.
Not to mention the 20MHz capability.

I reckon the statement: 'The only advantage a Uno has is its size', is better off: 'The only advantage a Mega has is its size'

pYro_65:
'The only advantage a Mega has is its size'[/i]

This may be true but, when Uno is too small, it's the deal-maker. So, i guess my comment still stands.

For me, the Uno is nice for testing out bits of code on unknown hardware. If I break it, I can replace the IC easily and won't shed tears. But if I break the Mega doing something dumb, I have to buy a new one or pay almost as much for a new SMD chip as I did for the whole thing and attempt to rework it.

And the Uno is also nice for the fact that since it is using a DIP chip, you can prototpye with it and then build your project easily on a perfboard with just the 328P.

I came from using straight AVRs for my projects, and I had the Uno for a couple years that I got for a gift and never used it. I have come to like how easy it is to use and how the direct register stuff is mostly hidden. But, I will admit that the code it generates is huge compared to doing everything the raw way. Such are the sacrifices and the decision to make.

Arduino is really just C (and some C++) with really nice libraries written for you, so once you finish a project, it isn't terribly difficult to just port your code over to using raw gcc code. At the core of arduino, it using the raw C code anyway. So for digitalWrite for example, you can just go into the core code and look at how it was implemented and transfer the pieces over to your raw code. Learning C the Arduino way makes moving over to doing it another way a relatively small step.

In the end, Arduino is really, at it's base level, just an AVR development board. So there is also nothing stopping you from using the boards with just AVRStudio and writing code that way and just using the boards for all the support circuitry and shields. In fact I was doing just that when I first pulled my arduino out of the toolbox (maybe a month ago, actually) because I didn't see the beauty of the Arduino "package" at first.

It may not seem obvious to someone first starting out, but there is "Arduino, the hardware", and "Arduino, the software." And they are really separate from each other.

I do think someone needs to smack the person upside the head that decided to put in the offset headers, though. Definitely a marketing ploy to sell shields! There was no reason to do that other than to purposefully make it non-standard in a way that (mildly) forced people to buy shields. The marketing guys will say it is a "feature" to ensure you only plug in "blessed and tested" shields, but the marketing guys always say stuff like that. Obviously, many people have found ways around that, and of course they would.

With all that said, because the hardware and software are separate in the Arduino world, the code you develop on the Uno could easily just be compiled right on to the Mega by changing the "board" in the IDE if you start running out of room. If you have to make any chages at all to your code, it will be minor. But before changing out boards, I would experiment with trying to optimize code. There is more than one way to skin a cat, and some compile to smaller code than others. 32K is relatively huge in the microcontroller world. I have skimmed off a few K before just by changing the way I do things. Many people leave in Serial.begin for example when they aren't using the serial port in their final design. This adds in the entire serial library to the compiled code. By removing just that one line, you leave out a ton of code that you weren't using anyway.

I have also stripped down libraries and clone it to a new library when they have way too many features that I am not using. Whether you use functions in the library or not, the entire library will get added into your code when you #include them. So, I often strip out all the stuff I don't use in my particular project if I want to save the room. Stuff like ifdefs which reconfigure the functions for different boards and such are easy targets.

I have an old Mega and the last revision.
The reason i took the Nano for the bathroom was that i can solder him on a Stripboard.
Yes i saw there is a shield with screw terminals. But it costs money, you have to order
it and wait for another part and then i also have to solder the cables to the PCB/Stripboard
and then screw them to the shield.

Also with just plugging the cables in the shield headers (something i don't like for fixed installation)
it's a cable mess.