(locations 0 to 63) of the 24LC256 and you start to write
data at address 50, there won’t be enough room to store
the string in page 0. Only 14 bytes can be stored in
locations 50 to 63, so the remaining 12 bytes won’t fit in
page 0. You might think that the extra data bytes would
“spill over” to page 1, but that’s not what happens!
(At this point, I should also mention that, unlike write
operations, read operations can freely cross page
boundaries. In other words, you can read and process the
entire contents of the EEPROM using one large loop. I
haven’t included a program that demonstrates this useful
feature, so you may want to do some experimenting on
Our next program clearly demonstrates why we need to
be careful to never attempt to write data across a page
boundary. Before running it, read the following footnotes for
Program 3 so that you know what to look for in the results
that are displayed in the terminal window:
1. The two hi2cout statements simply fill page 0 with
asterisks, so that the results of our mistake will be easier
2. Here, we try to write across the page boundary by
starting to write a 26-character string at location 50.
3. Here’s what happens: “A” through “N” ( 14
characters) fit, but “O” through “Z” ( 12 characters) wrap
around to the beginning of page 0.
All our programming experiments thus far have stored
data of a specified length, but there are many situations
where you don’t want to bother figuring out the length of
every collection of data you need to store. In Programs 2
and 3, for example, I had to manually count the number of
characters in the string before I could store it. This is a minor
nuisance at best, so let’s take a look at one way of avoiding
In this program, we’re going to define a special “end
of text” character, and use it to indicate when we have
reached the end of a data string. We could use any nonprinting character, but the ASCII code already defines a
value of 4 as “end of text,” so that’s what we’ll use as well.
Here are the more complete footnotes for Program 4:
1. This is simply our constant declaration for the “end
of text” character.
2. This group of four constant declarations specifies
the location of the first byte of each EEPROM page that
the program uses for data storage.
3. Each of the four hi2cout statements in the program
stores one of our data strings. Don’t forget that our “end
of text” character is also going to be stored in the
EEPROM, so this approach limits the maximum length of
the actual data that we can store with one page write
operation to 63 bytes.
4. At this point, we have stored the four text strings,
so we’re ready to fetch and display them. We’re going to
use a subroutine for this purpose because we’ll be doing
the same thing four times. Each time before we enter the
subroutine, we fetch the first data byte from the specified
page. This way, when we get to the subroutine, the data
location will be automatically updated for each byte that
5. Since we have fetched the first character in the
string before entering the subroutine’s do…until loop, we
need to display it in the terminal window before fetching
the next character.
6. Here, we continue displaying each character and
fetching the next one until we fetch the “end of text”
character, at which point the do…until loop terminates. As
a result, the “end of text” character is never displayed.
7. Just before exiting the subroutine, we move the
terminal window’s cursor to the beginning of the next line
so that we’re ready to display another string of text.
I realize that our programming experiments this
month have largely focused on the storage and retrieval of
text strings. This is probably because I have been thinking
about how to use EEPROMs to store and display text on
an LCD. However, I would be remiss if I didn’t mention