EEPROM "Write Cycle Exhaustion"

 

What Write Cycle Exhaustion Is

EEPROM (Electrically Erasable Programmable Read Only Memory) is part of a whole class of circuits placed on chips that form dynamic and static solid state memory. Hard drives (old school ones, at any rate) were electromechanical memory in that they were - well, mechanical. SSDs (Solid State Drives) are a form EEPROM. (Sort of - bear with me, I'm simplifying a lot here or else this article could get to be a smol book hence I leave out a lot of stuff.) 

Solid State

Solid State Memory doesn't have mechanical parts and stores data in the form of  some kind of electrical circuitry. The RAM in your device laptop or PC is volatile memory, that is, it only holds memory while powered and clocked. (The clock signal is a usually system-wide regular pulse that synchronizes all operations in a computing circuit. RAM generally 'refreshes' the contents of each location on a regular basis. When power or clock signal is lost, so is the memory.)

Mechanical

Mechanical hard disks on the other hand store data as magnetic dots that are aligned N-S or S-N depending on how they're designed. These are (almost) permanent rewritable memory. But over time, the data bits it stores may be corrupted by external magnetic fields, or after a great number write-rewrite cycles, a region of the disk may stop being able to change magnetic state, resulting in "bad blocks" or garbage being read back from the disk, or write failures. 

Now - some memory systems are better at certain things than others. RAM is great for working memory that you read and write to during the execution of a program. It's thousands of times faster than doing all those operations on a mechanical hard drive would be, it has a read/write lifetime that's practically unlimited. But when you turn the power off, all data on it is gone. 

Mechanical hard drives can take the results of the program off the RAM and store it more or less permanently, perfect for the output of your program. But mechanical hard drives are s--l--o--o--o--o--o--w. Programs that have to load from hard drive to RAM can take a significant time. 

If that program had to write to and read from a mechanical hard drive it would be incredibly slow and frustrating. As it is, loading a program is slow - imagine loading a large game or program, and you know it can take many second to several minutes, and a significant portion of that time is due to hard drive speeds.

Also, you sometimes needed a simple way to get a program loading that didn't rely on a slow and extremely fragile mechanism like a mechanical hard drive. 

My quick storyline of memory referred to in this article.

The EEPROM And Beyond

EPROMS (Erasable Programmable Read Only Memory) solved that problem - and created another few in the process. They did give a way to store a program permanently that could load quickly. Once loaded, the program could read and write to RAM. But due to the nature of the first EPROMs there was nowhere to write those results back to.

Early EPROMS were written to once, on a special programmer device, and they couldn't be erased except from exposure to ultraviolet light. They had a round "window" on the chip right over the actual silicon, and to erase them you had to expose them to UV light for a certain amount of time. To prevent stray UV from erasing the chip in operation, a small sticker was generally put over the window.

With those EPROMS, (and to EEPROMs) the number of times you could write to them was limited. During the development of a program to run from EPROM, you could well end up "write exhausting" (and I don't know if that's the correct term, but we used it where I worked) the EPROM and it would no longer hold all the bytes of a program. 

Luckily, you developed the software on a PC, saved it to a hard drive, and wrote it ("burned" was the common term) from there to the EPROM chip, then installed the chip in a device, turned it on - and generally at some point during the testing process, you swore under your breath, erased the EPROM, corrected a section of the program, and went back the the "burn" stage and repeated. So you could exhaust the limited number of write cycles of an EPROM quite quickly.

Once the EPROM was fully debugged and in the device, the number of read cycles was practically unlimited. But when the program needed updates (to add features, correct a bug that had somehow escaped notice until the client used the device to do something that you thought would never EVER happen so didn't even think to test for it) you'd have to erase the EPROM and burn the new software onto it. 

And of course, whatever program you burned onto the EPROM had nowhere to store the output it created. Unless you wrote that output to a printer or a magtape or a series of flashing lights or a video display. And then the client wanted to use a CNC machine to carve the result into a wood panel, and that would generally also need a rewritten EPROM.

Yep, fun times.

EEPROMS solved many of those problems because it was electrically erasable. The program on it could erase a spare bit of the EEPROM and write the resulting data there, and it would have that data available after being switched off and back on. Also, the technology of the gate arrays that stored the program and data was getting better so EEPROMS started being good for a thousand or more cycles instead of just a few hundred. But write exhaustion would still get you in the end, because you could now use part of the EEPROM memory space to store results, and each save was a write operation... 

(ASIDE: A place I worked used a small microcontroller device to monitor some industrial operations for a client. The gizmo was a single-board microcomputer with an SD card (which is just an EEPROM embedded in a lovely little slice of plastic at heart) that held the program and the data. It worked like a champion in the lab, was installed - and failed two days later, the SD card corrupted. Turns out that writing data to the SD card every two seconds got to 100,000 read/erase/write cycles in around two days. A hasty rewrite of the software to only write once every few hours ar at a power-down event fixed the issue, or at least pushed the problem out to two hundred years. . .)

Why Does This Concern Us?

Well, this write limitation includes the EEPROMs on all the microcontrollers and single-board computers and devices that we work with commonly, including my beloved Aduinos of all flavours and ESP32 devices and the motherboard of Brucely The 3D Printer. 

Every time I saved a setting on the printer, I was aware that it was a write cycle, and each time, I'd cringe a little inside. I'm old school, used to EEPROMs failing at the drop of a hat. Every time I altered a program sketch and uploaded it into a D1Mini or Uno, I expected a failure. 

So it was a bit cool to see that someone took the time to actually do the experiment(s). If you want to know, modern EEPROMs can take over five million write cycles. That failed microcontroller could have run between 60 and 90 days if we'd had anything as robust as modern tech back then.  

My programming of SCM boards is going back to software micromanagement... 

And Finally The Arduino Nicla Edge AI Vision Board

Are you interested in using edge AI for video? (Face recognition, number plate / barcode / QR code reading, machinery fault / operation detection, etc?) Want that in a format you're already familiar with programming, that's known technology?

I reckon the Arduino Nicla will do that, and I might start experimenting with one if I can get hands on a few. 

As you know my main focus is cottage industry level recycling at RCX-AU. I am aiming to produce the designs for machines that anyone can build from mostly common and even household equipment for recycling parts of their local waste stream. I know that at $115USD the Nicla Vision is not the cheap and cheerful Arduino I'm used to, but if it is possible to make ANY of the processing more repeatable and more safe, then it's worth it.

I'm envisaging a Nicla Vision and a Nicla Sense or two monitoring a plastic grinder or extruder and adjusting the PID as needed to prevent sub-optimal or even dangerous conditions. When you're working by yourself or with only a couple of other people, the last thing you want is for part of the process to drift out of tolerance while you're busy with filling and clearing injection molds. And they also have the Portenta range of boards I just saw, so I'll have plenty of  choices for making effective, safe, and efficient machine designs. 

We're At The End And You Know What That Means. . .

Yep, the footer boilerplate. Please use the Contact Form if you'd like to say anything about this article, want to help development or organisation of RCX-AU.

Go to the News Stand and subscribe or get feeds for your feed reader, go to my PTEC3D Ko-Fi page and send me the price of a coffee or take a monthly membership, or donate directly if you prefer.

Disclosure: Some of my links are affiliate links, that is, if you use them directly from this page to buy the linked item, I'll receive a commission. This comes at no extra cost to you, and if you don't use the link the company just silently pockets the commission themselves. It may as well come to me and help me pay for parts, servers, search engine boosts, etc. 

I've investigated the items and use many of them myself, and offer them in good faith. But ever sale made though affiliate links in my articles helps. 

Also, not all links are affiliate links, but still they have generally been investigated and vetted by me. 

Cheers! Now go and make stuff, do stuff, and make a difference!