Computer memory has taken on many forms over the years, from mercury-based delay-line tubes to handwoven magnetic core. These days, volatile storage using semiconductors has become ubiquitous with computing, but what if there was a better way? [Michael Kohn] has been working on a new standard for computer memory that uses glow in the dark stickers.
Clearly we jest, however we’re still mighty impressed by the demonstration. Eight delightful star-shaped phosphorescent stickers represent eight bits of memory, totaling one byte. The glow in the dark material is stuck to the inside of short cylinders, each of which contains a white LED and a phototransistor. The memory array is wired up to an iceFUN FPGA board, which is then connected via level shifters to a Western Design Center MENSCH single board computer.
Every time one of us flashes an Arduino’s internal memory, a nagging thought in the backs of our minds reminds us that, although everything in life is impermanent, nonvolatile re-writable memory is even more temporary. With a fixed number of writes until any EEPROM module fails, are we wasting writes every time we upload code with a mistake? The short answer is that most of us shouldn’t really be concerned with this unless we do what [AnotherMaker] has done and continually write data until the memory in an Arduino finally fails.
The software for this is fairly simple. He simply writes the first 256 ints with all zeros, reads them to make sure they are all there, and then repeats the process with ones. After iterating this for literally millions of times continuously over the course of about a month he was finally able to get his first read failure. Further writes past this point only accelerated the demise of the memory module. With this method he was able to get nearly three million writes before the device failed, which is far beyond the tens or hundreds of thousands typically estimated for a device of this type.
To prove this wasn’t an outlier, [AnotherMaker] repeated the test, and did a few others while writing to a much smaller amount of memory. With this he was able to push the number of cycles to over five million. Assuming the Arduino Nano clone isn’t using an amazingly high-quality EEPROM we can safely assume that most of us have nothing to worry about and our Arduinos will be functional for decades to come. Unless a bad Windows driver accidentally bricks your device.
Sounds like somebody had a really bad day at work, as Western Digital reports that “factory contamination” caused a batch of flash memory chips to be spoiled. How much, you ask? Oh, only about 7 billion gigabytes! For those of you fond of SI prefixes, that’s 7 exabytes of storage; to put that into perspective, it’s seven times what Google used for Gmail storage in 2012, and enough to store approximately 1.69 trillion copies of Project Gutenberg’s ASCII King James Version Bible. Very few details were available other than the unspecified contamination of two factories, but this stands poised to cause problems with everything from flash drives to phones to SSDs, and will probably only worsen the ongoing chip shortage. And while we hate to be cynical, it’ll probably be prudent to watch out for any “too good to be true” deals on memory that pop up on eBay and Ali in the coming months.
If you dig microcontrollers, and you like to dig into how they work, Elecia White wants to help you navigate their innermost secrets with the help of memory map files. In this refreshingly funny, but very deep keynote talk from the 2021 Hackaday Remoticon, Elecia guides us through one of the most intimidating artifacts of compilation — a file that lists where everything is being put in the microcontroller’s memory — and points out landmarks that help to make it more navigable.
And when you need to look into the map file, you probably really need to look into the map file. When your embedded widget mysteriously stops working, memory problems are some of the usual suspects. Maybe you ran out of RAM or flash storage space, maybe you have some odd hard fault and you want to know what part of the program is causing the trouble, or maybe you need to do some speed profiling to make it all run faster. In all of these cases, you get an absolute memory address. What lives there? Look it up in the memory map!
The all-in-one Raspberry Pi 400 computer is a capable device, but those seeking its maximum power may be disappointed by its 4 GB of memory. When the Pi 4 and Compute Module 4 have double that figure, surely the Pi 400 could catch up! A reddit user called [Pi800] rose to the challenge by replacing the 4 GB chip from the Pi 400 with the 8 GB chip from a Pi Compute Module, resulting in the so-called Pi 800, a working 8 GB all-in-one Pi.
As a piece of work it’s a deceptively straightforward yet extremely fiddly piece of soldering that requires a steady hand for even the most skilled of solderers. What takes it beyond the norm though is the reballing process. A ball-grid-array chip has a grid of small balls of solder on its underside that make the contacts, and these melt when it is soldered so require replacement before reworking. This is normally done with a template of carefully aligned holes to line up balls of solder in a stream of hot air, but lacking the template in this case the job was done by hand, laboriously ball by ball. A soldering task we’d hesitate to take on ourselves, so we’re impressed.
The result is an 8 GB all-in-one Pi, and it’s honestly not beyond the realms of possibility that an official version of this mod could be a future Raspberry Pi product. Perhaps we’ll wait for that, but should you be impatient then at least it’s possible to roll your own. It’s certainly not the first BGA memory swap we’ve brought you.
I’m excited to share the news that Elecia White will deliver a keynote talk at the Hackaday Remoticon in just a few short weeks. Get your free ticket now!
Elecia is well-known throughout the embedded engineering world. She literally wrote the book on it — or at least a book on it, one I have had in my bedside table for reference for years: O’Reilly’s Making Embedded Systems: Design Patterns for Great Software. She hosts the weekly Embedded podcast which has published 390 episodes thus far. And of course Elecia is a principal embedded software engineer at Logical Elegance, Inc working on large autonomous off-road vehicles and deep sea science platforms.
Map metaphor used to help visualize microcontroller memory. [Source: embedded.fm]For her keynote, Elecia plans to unwrap the secrets often overlooked in the memory map file generated when compiling a program for a microcontroller. Anyone who has written code for these mighty little chips has seen the .map files, but how many of us have dared to really dive in?
Elecia will use a nifty metaphor for turning the wall of text and numbers into a true map of the code. That metaphor makes the topic approachable for everyone with at least a rudimentary knowledge of how embedded systems work, and even the grizzliest veteran will walk away with tips that help when optimizing for RAM usage and/or code space, updating firmware (with or without a bootloader), and debugging difficult crash bugs.
The Call for Proposals closed a few days ago. So far we’ve made two announcements about the accepted talks and we’ll make two more, this Thursday and next. But there’s no reason to wait. With Elecia White, Jeremy Fielding, and Keith Thorne presenting keynotes, and some superb social activities soon to be unveiled, this is an event not to be missed!
Remoticon is free to all, just head over and grab a ticket! If you want something tangible to remember the weekend by you can grab one of the $25 tickets that scores you a shirt, but either option gets you all the info you need to be at every virtual minute of the conference.
On the scale of things worth worrying about, having to consider whether your EPROMs will be accidentally erased by some stray light in the shop is probably pretty low on the list. Still, losing irreplaceable data can make for a bad day, so it might just pay to know what your risks really are.
To address this question, [Adrian] set out to test just how susceptible to accidental erasure some common EPROM chips are. An EPROM, or “erasable programmable read-only memory”, is a non-volatile memory chip that can be programmed electrically and then erased optically, by exposing the die inside the chip to light at a specific wavelength, usually in a special chip erasing tool. But erasure can also happen in daylight (even if it takes a few weeks), so [Adrian] cooked up an experiment to see what the risk really is.
He exposed a selection of EPROMs with known contents to UV and checked their contents. Three of the chips had a simple paper or foil label applied, while one had its quartz window exposed to the UV. As expected, the unprotected chip was erased in just 30 minutes. The covered chips, though, all survived that onslaught, and much more — up to 780 minutes of continuous exposure.
So rest easy — it seems that even a simple paper label is enough to protect your precious retro EPROMs. It’s a good data point, and hats off to [Adrian] for taking a look at this. But now we can’t help but wonder: what would a little sunscreen applied to the quartz window do to erasability? Sounds like a fun experiment, too.
