Setting Up debian-backport Repository On A Raspberry Pi

Sometimes I write these posts because I’ve found something interesting. Sometimes I write them because I’ve done something I want to share. And, sometimes I write them because I don’t want to forget how I did something.

This is the latter.

I was trying to set up the debian-backports repository and after I’d added it to the sources.list file I kept getting this:

GPG error: buster-backports main:The following signatures couldn't be verified because the publickey is not available: NO_PUBKEY

and then a 16-character hex number. To fix it, I did the following:

sudo apt-key adv --recv-keys --keyserver [16-character hex number] [other 16-character hex number (if applicable)]

That seems to have done the trick. Source information from:

Very Simple CircuitPython Driver for Generic 64Mb SPI PSRAM

I really like this PSRAM chip from Adafruit. It behaves very much like SRAM, but with a much higher capacity and an SPI interface, which is so much nicer to deal with than more address lines than I can count. Hauling that much data back and forth with (Circuit/Micro)Python over a microcontroller SPI interface isn’t fast, but having that much capacity at your disposal makes it really useful.

I wrote a MicroPython driver for it a little while ago and have put together a CircuitPython version. I’ve tested it with CircuitPython 6.2, 6.3, and 7.0.0-alpha.3, and it seems to work pretty well.

You can find the driver and an example program for it at:

Very Simple MicroPython Driver For Microchip 24×256 and 24×512 I2C EEPROMs

This is a slightly modified version of the CircuitPython driver I released a couple of days ago. Functionality is all the same but it runs with MicroPython v1.15.

If you’re interested, you can find it here:

Very Simple CircuitPython Driver For Microchip 24×256 and 24×512 I2C EEPROMs

Took me a while to get this one working. CircuitPython is juuuuuuuust different enough from MicroPython to be… well… pretty infuriating at times.

Do you know what I2C looks like on an oscilloscope? I didn’t until today, when I spent a long time looking at stuff like this:

I pay extra to get “comfortably rounded” square waves.
One, zero, one, zero, one, zero, zero, ze… DAMMIT

Anyway, if you’re interested, you can find the driver here:

Very Simple MicroPython Driver For Microchip 47×16 I2C EERAM

Up until a short while ago, I’d never heard of EERAM. When I saw it, I initially thought it was a typo, but after looking into it I was pretty intrigued.

Turns out it’s SRAM and EEPROM packaged in the same device, and you get the benefits of both. During regular operation, you read and write to the SRAM, which means it’s nice and quick and has unlimited write cycles. If power is lost (and you have the right capacitor connected to the Vcap pin), the contents of the SRAM are automatically written to the EEPROM. When power is restored, the contents of EEPROM are automatically read into SRAM.

You can’t use the EEPROM directly, but you can trigger the device to store the SRAM data to the EEPROM with a command or pin, and you can recall the EEPROM data to the SRAM with a command.

It’s kind of strange but neat at the same time. Oh, and it shows up as two devices on the I2C bus! Weird, eh?

I put together a little MicroPython driver that sets the device to auto store in the event of power failure (so you’ll need that capacitor), and added functions to manually store SRAM to EEPROM and recall EEPROM to SRAM. If you’re interested, you can find it at:

Very Simple MicroPython Driver for Generic 64Mb SPI PSRAM

Picked up an 8MB SPI PSRAM on sale a little while ago and have been excited for the possibilities of having that much extra room to do microcontroller-y stuff with. I wrote a simple driver for it, you can find it at:

I’ve only used it with a Raspberry Pi Pico (RP2040) since that’s the only MCU I have that’s running MicroPython, but it should work with other MP-capable devices that can use a hardware or software SPI bus.

Writing and reading 64Mb over SPI is not fast, but it works!

Very Simple MicroPython Module To Use A Microchip 23LC1024 SPI SRAM With A Raspberry Pi Pico (RP2040)

As I’ve said many times, I’m not much of a programmer. But, on occasion, I cobble together something that I find useful. Ms Geek suggested a few times that I should throw that stuff onto GitHub so others could use it, even if it’s to give them a good laugh.

So my first submission is a MicroPython module for a Microchip 23LC1024 SPI SRAM that (to me) is very easy to use and seems to work. You can find it at:

I only have a Raspberry Pi Pico RP2040 to use it with, but it should be pretty easy to use with any other MicroPython or CircuitPython installation.


So… here we are. It’s been a little over a week since I started this project. Lots of ups, downs, laughs, tears, fist-shaking, face-palming, thumbs-upping, head hung in defeat, and arms raised in victory. I gave up on the Raspberry Pi Zero/Arduino combination (curse you, Timer3!!!) and switched to a Raspberry Pi Pico microcontroller (which, aside from making an LED blink by copy-pasting an example a few months ago, I knew nothing about) and started the electronics from scratch. By yesterday evening, things were moving along again. And in the end…

I failed.

It was pretty close, though. By this morning, my little robot could move around on its own and successfully detect and turn to avoid (some) obstacles using an HC-SR04 ultrasonic rangefinder. I was working on LED rangefinding and cliff sensing when I ran out of time.

Head bowed and properly ashamed, I told my wife that my robot sweeper wasn’t ready. She assured me that it was “cute” and thanked me for not setting the house on fire. Then, a twist: she’s been doing a ton of research into the little robots and based on the layout of our house and the stuff we have kicking around, she’s not sure which one would be a good fit. We even talked about getting a (gasp) cordless stick vacuum instead. Personally, I’d still rather have a robot because neither of us enjoy vacuuming or sweeping (does anyone?) and it’s more likely to get done if a computer does it.

Regardless, the sale is now over and we didn’t buy anything. Which means… I have more time. It’s not really a challenge anymore since we don’t know when the next good sale will be (or even what we want) but as it’s been quite the learning experience and we both agree that having a cheap little sweeper robot can’t hurt, I’m going to keep working on this project.

I have also “discovered” the Pi Pico. I’ve had a couple of them for a while now but since most of the stuff I do is with an Arduino, they’d been sitting around until I had time to tinker with them. Well, in the last 48 hours or so I’ve tinkered with them until my eyes would no longer focus and I’ve got to say that I’m quite pretty extremely impressed. Setting up MicroPython was easy, it’s easy to program with Python, and it has so many peripherals built in (not to mention the PIO stuff which I haven’t tried but looks great) that it’s… well… pretty amazing. And I’ve barely scratched the surface. I’ve got a million other project ideas for it, and it could well become my go-to when I need a microcontroller for something.

With the time constraint relaxed (at least for now), I’m very interested in seeing where this project goes. But now it’s late again and I really, REALLY need to clean my piles of components, wires, and papers off the dining room table before I go to bed.


Well… things aren’t looking great at this point.

I thought I had everything figured out. Raspberry Pi Zero was going to talk over I2C and a level shifter with two Arduino Pro Micros – one for sensors and one for motors.

Rangefinder and LED/phototransistor pairs were working great and reporting nicely back to the Pi over I2C.

I wasn’t worried about the motors because a couple of days ago I had the drive motors working when sending commands using the USB serial on the Arduino (that’s what I was doing in the video from the other day).

But alas, the USB serial port uses timers differently than I2C on the Arduino, and the servos and I2C are arguing over the same 16-bit timer hardware in the 32U4. There is one other 16-bit timer on the chip (Timer3) but when I tried using it instead of Timer1 for the servos it doesn’t have the same kind of access to the pins that Timer1 has.

I think, anyway. The best I could get out of the servos was an occasional irregular “putt”. And now it’s getting late and I’ve spent way too much time staring at datasheets. Oh, and of course when I went to the Arduino forums I was greeted with this today:

Don’t get me wrong – it’s great they’re doing maintenance. I just wish they weren’t doing it NOW.

I know there’s a solution, but my old worn-out brain can’t think of it right now. I guess I could run the sensors over I2C and the motors over UART, but I was hoping for a cleaner, less confusing setup. A different microcontroller? ESP32? Pico? Ehurrrghhh.

At any rate, I need to get to bed. Lots of stuff I’ve been putting off that I should really do tomorrow before I get back to work on this particular project.


I can’t believe I’m saying this, but… IT’S ALIIIIIVEEE!

Doesn’t do much more than drive around with commands sent through a terminal session to the onboard Pi Zero, but I’m pretty sure this is the best run at building a robot I’ve had.

Needs better wheels, though – shiny hard plastic drive wheels aren’t so good on carpet, and a front “wheel” made out of a big blob of masking tape leaves a lot to be desired.

But there is definitely some progress going on. And it already picked up some hair (and there’s no brush or mop or vacuum on it)!

Woohoo little robot!