|
|
|
Getting started with ferroelectric RAM
Sunday, January 12 2025
First thing this morning, I was cleaning up another couple turds Oscar had squeezed out in the northeast corner of the laboratory, near where I keep my collection of old Macintosh 3.5 inch disks. He apparently didn't like the plastic I had put down behind my main computer, Woodchuck, and had opted to poop on a carpet fragment instead. It was nasty, but at least it wasn't embedded in a rat's nest of wires. And it was fairly dry, so it didn't seem to leave much residue. But our time of dealing with this sort of thing looks to be coming to a close. Gretchen and I agreed we should call the vet on Monday and arrange to have him euthanized. He's clearly not happy, as indicated by the pooping and pissing he is doing all over the house. And lately he's been sleeping in a nook behind the laboratory bookshelf that he only goes into when he's not feeling well. He also looks like shit, with no flesh on his backbone, mangy fur, and now a runny eye in the somewhat-swollen right half of his face. Despite all that, Oscar still loves wet food, and that seems to be all he lives for. But even there, his interest in it seems pathological.
Today I began working on building an offline logging functionality into my ESP8266 Remote Control firmware. The idea is to use a 32 kilobyte FRAM (ferroelectric RAM) chip to store as many as 500 or so records during times when a remote cannot reach the internet (this might be, for example, because it is attached to a moving object). In the cabin application, this functionality won't actually bring much benefit, since a reliable internet connection is one of the very last things lost as power runs out in the winter. But I have other uses for storage that survives an ESP8266 reboot, particularly the logging of such reboots.
The first thing I had to do was make it so the firmware doesn't just keep trying to connect to the WiFi router but instead gives up at some point and goes into "offline mode." In that mode, instead of trying to send data via http requests to the server, it logs it in a concise timestamped format in the FRAM. I had some sketchy code created by ChatGPT to get started with, but as I tried to test my FRAM breakout boards, they couldn't be detected. Were they defective? After much fiddling and swapping of SCL and SDA (the two I2C data lines, which seem to be backwards about as often as USB A is upside-down), I finally figured out what the problem is: there is a write-protect pin between the power pins and the I2C pins on the AdaFruit breakout. (I'd never before seen extra pins that needed to be skipped on slave I2C devices before.)
For linking purposes this article's URL is:
http://asecular.com/blog.php?250112 feedback
previous | next |
