rounding off. At this point, the tempF variable is in tenths
of a degree, so if we simply divided it by 10, we would
truncate the “tenths” digit, not round it off. By first adding
5 to tempF, any value of 5 or greater in the tenth’s digit of
tempF will be increased by enough to cause a “carry” to
the one’s digit; if the value of the tenth’s digit is less than
5, adding 5 will not cause a “carry” to occur. As a result,
when we then divide tempF by 10 (truncating the tenth’s
digit), the presence or absence of the “carry” correctly
rounds the result to an integer.
■ FIGURE 10.
Schematic #2 for
Experiment 2.
6. The LED display that I’m using is based on the
MAX7219 display driver, which requires a value of 15 to
blank any digit in the display. Therefore, if you use a
different LED display, you may need to modify this portion
of the code. Also, the four values are displayed from left
to right, so sending 15 as the first value results in the leftmost digit being blanked.
7. We want to right justify the displayed temperature
value, so digits don’t “bounce back and forth” whenever
tempF increases or decreases above or below the value of
100. Therefore, if tempF < 100 degrees, we send another
value of 15 to blank the second digit from the left, and
then send the two-digit value of tempF. On the other
hand, if tempF >= 100 degrees, we just send the three-digit
value of tempF. As a result, the LED display is always right
justified.
8. Each time the four bytes of data are stored in the
FRAM, two additional “end of file” (EOF) markers (i.e., two
values of 255) are also stored. When we power-down the
program, carry the FRAM inside the house to the data
reader breadboard, and transfer the data to the PC, the
data reader software uses one of those values to
determine when to stop transmitting the data to the PC.
Of course, it is possible for the minuteL variable to have a
value of 255. For example, if a “low and slow” cooking
session lasts longer than four hours and 15 minutes,
minuteL would equal 255 at that point in time. However,
we would have to cook something for more than 45 days
to store a valid data value of 255 in the minuteH variable!
So, as we’ll soon see, the data reader program stops
reading the data as soon as minuteH contains the EOF
marker.
■ FIGURE 11. Breadboard setup #2 for Experiment 2.
The software for the data reading circuit
( FRAMdataReader.bas) is also really simple. There’s also
only one point here I want to clarify about how the
program uses the EOF marker to determine when to stop
processing the data. When I first wrote the program, it
hi2cin FRAMloc,(minL,minH,tempFL,tempFH)
At this point, we’re ready to move on to the data
reading portion of this experiment. Fortunately, this
portion of the experiment is much simpler than the data
logging portion we just discussed. The schematic for the
data reading circuit is presented in Figure 10, and my
breadboard setup — which is identical to one we used in
the previous Primer — is shown in Figure 11.
do
sertxd (#minute,”,”,#tempF,CR,LF)
FRAMloc = FRAMloc + 4
hi2cin FRAMloc,(minL,minH,tempFL,tempFH)
loop until minH = EOF
This circuit really doesn’t require an explanation. The
only point I want to mention is that the +5V connection to
pin 1 of the FRAM board — which wasn’t visible in the
temperature monitoring and logging circuit (see Figure 8)
— can be clearly seen in Figure 11.
If you compare the above code snippet to what’s
written in the program listing, you can see that both
versions essentially implement the same set of tasks. What’s
the difference? (I’m glad you asked.) See if you can figure it
out before I explain why I modified the original code.
In the above code, the first four-byte data entry is read
February 2016 19
