Nuts and Volts - November 2013

54 November 2013

Post comments on this article and find any associated files and/or downloads at www.nutsvolts.com/index.php?/magazine/article/november2013_Smiley.

electronic sensors connected to microcontrollers to do the sensing as in our fresh air controller example. We only need to add the equivalent of the pens and strip chart by recording the sensor data to computer memory. (Though you may end up pulling out a few hairs of your own.)

Recording Data With an Arduino

How much data can an Arduino hold? Arduinos now come with an ATmega328p which has 32K bytes of in-system self-programmable Flash program memory, 1K bytes of EEPROM, and 2K bytes of SRAM. Theoretically, we could use any of these to record data. We learned about computer memory — especially that on AVRs — back in the June through October 2010 Workshops.

Of the three available types of memory, Flash — which is the largest — seems the most tempting to try to use to record data, and indeed it can be used as such. If your application is relatively small and you have relatively little data to store (but more than can be accommodated by the EEPROM or the SRAM), then Flash looks especially attractive. Unfortunately, while it is relatively easy to store program data at compile time [we have discussed storing preset data like strings using the features in pgmspace.h], it gets quite a bit more complicated to store data in Flash at run time. The bootloader does this as a matter of course, but it has to take special measures involving special timing and erasing large blocks of code and so forth that make adapting these procedures to saving data a byte at a time a bit obtuse. If there is one thing we know, it is that we are using the Arduino to avoid obtuse.

If writing data to program memory at run time was easy and a good idea, there would already be a plethora of Arduino libraries to do just that, but there aren’t. So, we will only look at using the SRAM and EEPROM on the Arduino; we’ll then graduate to external SD cards which do have a plethora of Arduino libraries and are a cheap and easy way to store LOTS and LOTS of data. But first, SRAM.

The SRAM

SRAM is re-writable essentially for all time and eternity. However, we are short on SRAM because it is the most expensive type of memory, and we are given the minimum deemed necessary to run the microcontroller Let’s say small means we are allocating a fourth of the SRAM which is 512 bytes, and dump quickly is to be determined. We’ve already discussed that one of the main attractions of our handheld prototyper is that it doesn’t need to be tethered to a PC. If we are tethered to a PC, then our data memory isn’t a problem. We just continuously upload the sensor data as we get it and let the PC deal with it.

Since we want to record data in isolation from a PC, let’s arbitrarily demand that it only be connected to a PC once per day. That means we can record our 512 bytes in 24 hours, or 21.333... samples per hour — roughly one sample every three minutes. If we want to record the temperature and humidity, then we can do that about once every six minutes. If we want both the indoor and outdoor data, we can record it about once every 12 minutes. Is that bad? Not in my humble opinion. We should hope that the outdoor and indoor climate is changing slowly enough that 12 minutes isn’t too much.

So, can we improve this? Of course. One way is to observe that neither the temperature nor the humidity will change more than a few points in a few minutes. We can again arbitrarily say that the temperature won’t go up more than one degree in two minutes, and that the humidity will only change by one percent in two minutes. This means we can expect a maximum rise or drop of six degrees or percent in our 12 minute sampling interval.

Neither is true if a storm hits, so you’ll have to build in some sort of exceptions which we’ll get to later. Other than those rare exceptions, you should only need to record a difference of a few integers from the last reading at each new reading.

This gives us the opportunity to record temperature or humidity in a byte — capable of coding 256 values — then next only record the difference + or – in the next reading that (as we saw above) will be much smaller than the 256 a byte can hold. We can use a four-bit half-byte called a