54 November 2013
Post comments on this article and find any associated files and/or downloads at
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.
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
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
■ FIGURE 3: Mechanical
■ FIGURE 4: Mechanical
temperature and humidity logging.