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: http://deb.debian.org 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 keyserver.ubuntu.com [16-character hex number] [other 16-character hex number (if applicable)]

That seems to have done the trick. Source information from:
https://backports.debian.org/Instructions/
https://rolfje.wordpress.com/2017/06/09/installing-gpg-keys-for-debian-backports/
https://answers.launchpad.net/ubuntu/+source/apt/+question/118944

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:
https://github.com/MarksBench/mb_PSRAM_64Mb_SPI_CP

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: https://github.com/MarksBench/mb_24x256_512

So… Firefox.

Firefox has been my browser of choice for over fifteen years now. I’ve repeatedly donated to Mozilla and have enjoyed the security, stability, and “Firefox-ness” of the browser.

Times and technologies change, though, and while Firefox has on occasion irritated me (the change to “Quantum” a few years ago, for example), I think today is the first time that they’ve put out an update that actually strains my eyes. I present to you Firefox 89.0:

Aside from resizing, this image has not been manipulated in any way. Not a lot of contrast there. Here’s a different view:

Note how there’s nothing dividing the tabs and they all just blur together. I routinely have 25+ tabs open in a browser and this update isn’t going to make that any easier. I need glasses for distance and close work, but not for computer work, and I find this new UI hard on my eyes. I wonder how the changes will impact people with impaired vision.

Fortunately, Mozilla/Firefox has a way to submit feedback about their product so I thought I’d leave my thoughts about the new design:

Erm…

Considering that they just released a new version, I’m guessing that “We’ve paused submissions to this form so that we can improve how we collect feedback” actually means “We’re being buried under an avalanche of comments and can’t keep up”.

I understand (and agree) that things need to evolve. After all, we’ve come a long way from this (which, interestingly, is ALSO all grey but makes my eyes ache less and I find it a lot easier to pick things out from the menus and bars):

Picture of NCSA Mosaic web browser from the 1990s.
Full disclosure: Mosaic KICKED ASS back in the day. Way better than Gopher and Archie. Seriously.

But I think the Firefox developers dropped the ball on version 89.0. Hopefully the next update will bring some contrast, or at least menu options so folks like me can tweak some UI settings and make it a bit easier on our aging eyeballs.

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:
https://github.com/MarksBench/mb_24x256_512_CP

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: https://github.com/MarksBench/mb_47x16

Generator Salvage!

I’ve been looking around for a generator for a while now, and Ms Geek just happened to come across one that someone had placed in their yard, hoping it would go to a good home. She was nice enough to pick it up and store it for a while until I could go pick it up (thank you!). This afternoon I gave it a quick look.

It’s… well, it’s seen better days:

A bit of rust on the muffler, some oil that’s hopefully from the air filter and not the crankcase, some dust, a couple dents. Okay, it’s worn, but not too bad. Should just need a good cleaning and a few new parts. Let’s see…

Okay, a little more rough than the back. More rust, missing bolts, and lots of cracked plastic. Still, with a little time and the right tools, I should be able to…

Oh.

Methinks this has met the ground whilst in free-fall at least once. Or perhaps it got dragged behind something. Astonishingly, the front panel is beat to shit but the meter still looks mint. Maybe someone replaced it already.

Looks pretty oily and grimy in there. Still, it seems all the pieces are technically there.

I took the cap off the gas tank and was pleased to find the tank wasn’t half-filled with thick, stale varnish. In fact, what I could see was dry as a bone. A bit of rust here and there, and some top-notch quality welding:

When Ms Geek found it, it was sitting out all by itself with this sign held to it with a piece of twine:

Hopefully the first line is accurate – the rest of the sign sure is. Still, it looks like an earnest little machine that has most of its parts. Plus, it has a red fuel tank and I do like red things. So over the next while I’m going to pull it apart and see if it’s going to work (and not fog the entire neighbourhood with blue smoke), and if it looks hopeful, I’ll get to cleaning and fixing it. Regardless of how it turns out, it’ll be fun!

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: https://github.com/MarksBench/mb_PSRAM_64Mb_SPI

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:
https://github.com/MarksBench/mb_23LC1024

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.

CHALLENGE ACCEPTED: ROBOT SWEEPER, PART VI

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.