The Code Diarist

A diary about code

Talking to a Memory

April 15, 2025

The memory is very good; the problem was to access it. I write here about EEPROM, a kind of memory for microcontrollers.

The acronym represents Electrically Eraseable Programmable Read-Only Memory. Think of it as a USB thumb drive for an Arduino. A program can store, retrieve, and even change the data stored on an EEPROM.

Now, as this is a diary and I expect no one will ever read it, I shall scribble blithely and let the words fall where they may.

An inexpensive circuit called a ZS-042 module provides both an accurate, digital clock/calendar and a small EEPROM. Two wires attach it to a microcontroller, such as an Arduino or Roger Wagner's wonderful MakerPort.

The device makes it possible to write a program that gathers data from a sensor at certain times then stores both the sensor reading and the time it was taken.

A project I have in mind would store data including:

What sensor is that? It does not matter here. The range of values it can produce needs attention, however.

Data stores in an EEPROM in eight-bit bytes. A byte can represent a number in the range of 0 – 255. It needs two of these bytes to represent a number in the range of 0 – 1023. My code will have to store the two bytes separately.

This means my data will consist of seven bytes: one each for the five time and date values plus two for the sensor reading. Together, the seven bytes form a record. How many of these seven-byte records should I plan to store in the EEPROM?

My mind spends far too much time and energy puzzling over that sort of question.

The EEPROM on a ZS-042 module can store 4,096 bytes. One answer is that I could store as many as 4096 / 7 = 585 whole records (disregarding the remainder). However, a limitation inside the EEPROM tells me not to try so many.

The memory in there is organized into pages of 32 bytes each, giving 4096 / 32 = 128 pages. The number of whole records that can fit into such a page is 32 / 7 = 4. It would complicate my code to have part of a record on one page and the rest of it on another. Limiting the number of records to four per page gives 4 × 128 = 512 records.

512 is still a lot of records. My code would have to keep track of where each record was located in its respective page. It would simplify things ever more if I used one page for each record. That decision would give me 128 records that my code could refer to solely by the page number.

The project I have in mind would need far fewer than 128 records. Therefore, I shall talk to my EEPROM in terms of just one record per page.

Who else do you know who fusses so much over such tiny details? This disclosure helps to explain why I lack many friends. My code, however, loves me for it.