DEV Community: Goose

EEPROM 28C64 API Performance with Arduino

Goose — Sat, 30 Aug 2025 20:09:21 +0000

EEPROM Read and Write Operations with Arduino

Motivation

In my previous post, I described a basic implementation of the EEPROM API and demonstrated, in a fairly simple example, how to read and write a few data cells. At that point, performance and operation speed were not particularly important, since the goal was only to provide an initial demonstration.

Now I would like to focus on improving performance and, moreover, comparing the values from the EEPROM's datasheet with the actual operation speed. This should not really be considered a precise experiment on measuring the raw speed of the chip itself, because the Arduino platform inevitably introduces certain performance limitations by adding some overhead. Therefore, my goal is to make the read and write API operations as fast as realistically possible, while still taking into account the constraints of the platform.

To achieve this, I will strictly follow the exact pin activation sequence described in the datasheet's waveforms and also respect the timing requirements for operations, such as the Write Cycle Time. I will eliminate unnecessary waiting functions and, in addition, use an oscilloscope to illustrate how the write waveforms actually look in practice.

Read Waveforms

The sequence of pin activations required for reading data from the EEPROM is, in fact, fairly straightforward.

Read Operation Steps:

Set the address on the Address Bus
Enable the Chip by setting CE pin to LOW
Enable the Output by setting OE pin to LOW
(*) Wait for the OE to Output Delay Time
Read the cell value on the Data Bus
Disable the Chip by setting CE pin to HIGH
Disable the Output by setting OE pin to HIGH

Step 4* is, interestingly, the one to watch, because Arduino platform specifics start to show. The EEPROM Datasheet states that the time between setting the OE pin LOW and the value appearing on the Data Bus is between 10 and 70 ns for my EEPROM model.

However, as the oscilloscope measurements indicate, the time between two pin write operations is about 120 ns. I can, reasonably, assume this is execution overhead, since the program is written in C and each function expands into a large set of low-level instructions. This delta between operations is sufficient for the value to appear on the Data Bus.

The Arduino Giga clock is 240 MHz, which is 20 times higher than the Mega’s 16 MHz, so the delta between pin write operations may be 20 times higher. I would like to run measurements of this kind in one of the next articles.

Write Waveforms

The operations required for writing data are slightly more complex and require additional polling of the READY/BUSY pin to determine when the write process has completed.

Read Operation Steps:

Set the address on the Address Bus
Enable the Chip by setting CE pin to LOW
Enable the Write by setting WE pin to LOW
Set the value on the Address Bus (~1us, see below)
Disable the Write by setting WE pin to HIGH (initiates the write)
Disable the Chip by setting CE pin to HIGH
(*) Poll for the READY status

The datasheet specifies two timing intervals important for implementing Chip Status Polling:

Time to Device Busy – the time between the WE pin rising edge and the READY/BUSY pin transitioning to BUSY, maximum 50 ns
Write Cycle Time – the time required to write data into the chip’s memory, maximum 1 ms

I added a 1 µs wait for the Time to Device Busy, though this is arguably unnecessary given the platform overhead for each operation.

For the status polling procedure itself, I implemented a simple mechanism:

If the chip is already in the BUSY state at the start of polling, check repeatedly every 200 µs until it transitions to READY, with a maximum timeout of 1.4 ms
Alternatively, simply wait 1.4 ms using a standard delay() function

The READY/BUSY status pin uses an Open Drain Output connection, so it is necessary to set it to INPUT_PULLUP mode for reading, or alternatively use an external pull-up resistor.

I will cover the performance details of polling in the next section.

The relationship between the CE (yellow) and WE (blue) pins, and their behavior during the write operation, is illustrated in the image above. First, the CE pin is pulled LOW to activate the chip. Then, the WE pin is pulled LOW, marking the start of placing a value on the Data Bus. The duration between the falling and rising edges of the WE pin is about 1200 ns, which corresponds to roughly 8 write operations at 120 ns each, plus the overhead required to set the value on the bus. The rising edge of WE initiates the actual data write process. The rising edge of CE no longer affects the operation, as can be seen from the waveforms.

It turned out I misread the waveforms last time. WE (blue) does indeed trigger the data-write operation on the rising edge, transferring the chip into the BUSY state (yellow). This is confirmed by the oscilloscope measurements shown in the image above.

Setting the chip to inactive mode by driving the CE pin HIGH does not affect the data write process, as shown in the image above.

Polling `BUSY` State

Using active polling of the READY/BUSY pin allows the write operation to be accelerated by roughly a factor of two.

Oscilloscope measurements show that a write takes about 500 µs, compared to the specified maximum of 1000 µs. However, even waiting manually for the maximum period can occasionally result in write errors. If a new write cycle begins before the previous one has completed, it can corrupt the data from the previous cycle by placing new values on the Data Bus. For reliability, I therefore set the minimum wait time to 1400 µs.

Chip status polling, however, reduces the waiting time from 1400 µs to 600 µs without compromising write reliability. Two oscilloscope waveforms illustrate this difference. In the first image, the program simply waits 1400 µs. In the second image, the program actively polls the chip status and returns control from the write function as soon as the chip enters the READY state.

This time could be further improved by reducing the delay() between pin polls to 50 µs, which theoretically would accelerate the waiting procedure by a factor of three instead of two.

Performance

GitHub Project with the Performance API

old API implementation:

WRITE | TOTAL: 8193044 us | AVG: 8001 us
READ | TOTAL: 15371674 us | AVG: 15011 us
VERIFY: OK

performance API implementation:

BUSY | TOTAL: 615502 us | AVG: 601 us | MAX: 605 us
WRITE | TOTAL: 622457 us | AVG: 607 us
READ | TOTAL: 4672 us | AVG: 4 us
VERIFY: OK

I run a sequential block of write operations followed by a block of read operations. I write 1024 cells one by one with random values, storing the written values in an array. Then I read the same 1024 cells one by one, storing the read values in another array. During each write operation, I also record in an array the waiting time for the chip’s READY/BUSY pin status, since this constitutes the main execution time consumption during writing.

The results of an "old API implementation" are not useful for comparison, as the first API version was optimized for visual demonstration rather than speed. I prefer to compare results against the maximum expected values from the datasheet.

I determined that a single digital pin read/write operation takes roughly 120 ns. During the write procedure, I perform 25 digital operations, giving 3000 ns, plus the array conversion procedure, resulting in about 4000 ns total, which aligns with the observed results. This process could be accelerated by caching the mapping between address values and bit representation, potentially speeding up single-cell reads by 5-10%. However, this is largely unnecessary, since the entire 8K cell address space can already be read in 40 ms.

For write operations, the picture is similar regarding execution overhead. The average operation execution time is 607 µs, with an average READY/BUSY pin polling wait of 601 µs, leaving about 6 µs for Arduino-side operations. This is slightly higher than for reading, due to data conversion and a 1 µs delay() before polling. The polling process itself could be sped up by checking the status every 20 µs, reducing total wait time by roughly 100 µs.

The values achieved for read operations are very good, as the datasheet specifies a maximum wait of 1 ms, whereas I achieve 0.6 ms.

Data Verification

After completing the write and read blocks, I compare the arrays to match data and check for errors. If writes are performed too quickly, operations overlap and data integrity suffers. For example, reducing the READY wait time from 1.4 ms to 0.2 ms results in almost all cells being written incorrectly.

This data verification is unrelated to the data corruption discussed in my previous article, since here I write and read within a single operational cycle. Detecting potential memory degradation of the chip requires performing a power cycle between write and read operations, which will be the topic of one of my upcoming articles.

Next Steps

(1) Check how many write cycles the new EEPROM chip supports and examine how its write endurance degrades, whether this manifests as slower write speeds or as data corruption.

(2) Write a program to verify the data stored on the EEPROM chip. Additionally, test data retention over a 24-hour period (the datasheet specifies 10 years).

(3) Assemble a breadboard setup with a ZIF socket to allow quick replacement of EEPROM chips for validation and verification.

(4) Compare the overhead of digitalWrite() and digitalRead() operations on Arduino Mega versus Arduino Giga, taking into account the 20× difference in clock speed.

EEPROM Read and Write Operations with Arduino

Goose — Wed, 27 Aug 2025 10:38:11 +0000

Motivation

I decided to dig into how computers actually work at the very lowest level. To do that, I chose to take individual components and perform various operations that are described for each component in its datasheet. Studying the parts of older computers is much easier, because thirty years ago each function had its own dedicated component or a small group of components, and I can study them one by one.

I started with EEPROM, since it is a fairly straightforward component that is responsible for static data storage, and it really supports only two operations: read and write. The pin structure of the chip is also very simple: there is one address bus, one data bus, and just a few pins for controlling the operating mode.

For my experiments I’m using an Arduino, because it allows me to recreate an artificial environment where the component is supposed to work without too much hassle. I picked a specific chip and wrote a small API class for it to work with Arduino.

The chip model is 28C64, which is a static EEPROM with digital rewrite capability. It has 28 pins, and I’m using an Arduino Giga, since the standard Uno model does not have enough pins available. The data bus width is 8 bits, which means that it writes one byte into a single cell. The address bus width is 13 bits, so in total it can store 8,192 words.

In this article I’ll walk through how the basic operations actually work and also highlight some of the subtle aspects of the chip’s behavior that might not be reflected in the datasheet. That’s exactly why I decided to check how well the documented operations match the real conditions.

Datasheet

Key points I can read from the 28C64 Datasheet:

The pin diagram, which helps us connect the necessary pins to the Arduino
The required voltage, which in our case is 5V, the same as Arduino
The behavior of the control pins, meaning which function is triggered by a positive or negative signal
The types of supported operations — at this stage I only care about reading and writing a single byte
The sequence of pin activations required to perform an operation (waveforms)

At this initial stage I am not concerned with tolerances, error handling, or performance characteristics, I just wanted to validate the basic functions of the chip.

EEPROM API for Arduino

class Eeprom28C64Api {
public:
  Eeprom28C64Api(... set pins layout ...);

  void init(); // init pins

  void readInit(); // init pins for read mode
  uint8_t readData(const uint16_t address);

  void writeInit(); // init pins for write mode
  void writeData(const uint16_t address, const uint8_t data);
}

I wrote a simple Arduino library that hides the low-level interaction with the chip behind just a couple of read and write functions. Here I’d like to go over some details of the implementation.

The constructor defines how the chip’s pins are connected to the Arduino. This wiring is unique for each board, in my case I connected the pins in a certain order, but if you decide to repeat the experiment, your layout may look quite different. After that you need to explicitly call init() method, which activates the Arduino pins for either input or output to the chip, and only then you can start reading and writing data.

Two separate types of functions are defined for read and write operations:

Initialization, which sets the Arduino pins into the correct state. For example, the data pins can be used for both reading and writing, and the mode depends on the microcontroller settings.
The actual operation, which reproduces the sequence of toggling between LOW and HIGH signals on the pins, exactly as shown in the waveform diagram.

At the time of writing this article, the library was not optimized for high-speed operation with the chip. Long delays are used between operations, and the status pin is not used at all. I plan to cover optimization and the chip’s performance characteristics in a separate article.

(*) Note that Arduino Uno is not suitable, since it lacks enough digital pins. It has only 14, while you need 24 to connect the address bus, the data bus, and the control pins. So the minimum workable option here is Arduino Mega.

(**) A project with a usage example can be found on my GitHub: EEPROM Basic RW

Arduino and EEPROM Wiring

I used half of a breadboard to place the EEPROM chip. On the same breadboard, I also added a control button and then connected everything to the Arduino. After that, I created an Eeprom28C64Api class object, specifying which pins I used for which functions.

White wires are used for the address bus, red wires for the data bus, and colored wires for the control pins.

The button controls the program’s execution loop, switching between read and write modes. First comes the read mode: the program reads ten memory cells one by one with a half-second interval. After that, the button press enables the write mode, where the program writes ten memory cells with a half-second interval. Then it reads again, and the modes are looped, basically.

I use a I2C 2004 LCD screen to display the status of the current operation, the address, and the data. Using this screen is not strictly necessary, but I found it convenient to have both control (the button) and display (the LCD) in one place, without relying on the Arduino console.

Bits to Bytes Conversion Logic

I use a closed ecosystem, so I can convert bit arrays into numeric values in any order I choose. I follow the Most Significant Bit First ordering, where the least significant bit represents the minimum value and the most significant bit corresponds to the maximum value.

{ 0,0,0,0,0,0,0,1 } == 1
{ 1,0,0,0,0,0,0,0 } == 128

Read Operation and Sequence

The sequence for executing a read operation follows the waveforms:

Set the address
Set the control pins such as –CE, –OE, and +WE (not shown in the diagram)
Read the data

Write Operation and Sequence

The datasheet shows two waveforms for writing: the first uses !WE for control, the second uses !CE. In both cases, the data bits are set after the control pins go LOW. However, the operation description states that data is written on the rising edge.

In practice, I could not reproduce this behavior. If I first set the control pins LOW, then set the data, and finally bring the control pins HIGH (rising edge), the data written to the cell corresponds to what was on the data bus at the moment of the falling edge. This leads me to hypothesize that the waveform diagram is incorrect, and the actual write trigger is the transition to LOW on the control pins.

I will investigate this discrepancy further when studying performance and attempting to achieve the specified 120 nanoseconds per read operation.

Thus, in my case the working sequence is:

Set the address
Set the data
Send a LOW signal to the control pins as –CE and –WE
Wait 1 millisecond

Summary / Next Steps

The chip behaves as expected, writing data to memory and allowing it to be read afterward. Questions about performance and the accuracy of the write operation remain open. I will address these issues in future articles in the EEPROM and Arduino series. For that, I will need readings from the READY/!BUSY pin with an oscilloscope.

Additionally, data verification raises an interesting point. It seems that the chip I am using cannot reliably retain data at the beginning of the address space after a power cycle. I wrote numbers 0–9 to the first ten addresses, but after a power cycle, reading these cells returns random values. However, using cells from the middle of the address space does not show this problem.

DEV Community: Goose

EEPROM 28C64 API Performance with Arduino

Motivation

Read Waveforms

Write Waveforms

Polling BUSY State

Performance

Data Verification

Next Steps

EEPROM Read and Write Operations with Arduino

Motivation

Datasheet

EEPROM API for Arduino

Arduino and EEPROM Wiring

Bits to Bytes Conversion Logic

Read Operation and Sequence

Write Operation and Sequence

Summary / Next Steps

Polling `BUSY` State