Close To The Metal

Firmware is caught between hardware and software. What do I mean? Microcontroller designers compete on how many interesting and useful hardware peripherals they can add to the chips, and they are all different on purpose. Meanwhile, software designers want to abstract away from the intricacies and idiosyncrasies of the hardware peripherals, because code wants to be generic and portable. Software and hardware designers are Montagues and Capulets, and we’re caught in the crossfire.

I’m in the middle of a design that takes advantage of perhaps one of the most idiosyncratic microcontroller peripherals out there – the RP2040’s PIOs. Combining these with the chip’s direct memory access (DMA) controllers allows some fairly high-bandwidth processing, without bogging down the CPUs. But because I want this code to be usable and extensible by a wide audience, I’m also trying to write it in MicroPython. And configuring DMA controllers is just too idiosyncratic for MicroPython.

But there’s an escape hatch. In my case, it’s courtesy of the machine.mem32 function, which lets you read and write directly into the chip’s memory, including all of the memory-mapped configuration registers. Sure, it’s absurdly low-level, but it means that anything you read about in the chip’s datasheet, you can do right away, and from within the relative comfort of a Micropython program. Other languages have their PEEK and POKE equivalents as well, or allow inline assembler, or otherwise furnish you the tools to get closer to the metal without having to write all the rest of your code low level.

I’m honestly usually a straight-C or even Forth programmer, but this experience of using a higher-level language and simultaneously being able to dive down to the lowest levels of bit-twiddling at the same time has been a revelation. If you’re just using Micropython, open up your chip’s datasheet and see what it can offer you. Or if you’re programming at the configure-this-register level, check out the extra benefits you can get from a higher-level language. You can have your cake and eat it too!

How Not To Build An RP2040 Board

We love that these days you can buy ready-made microcontroller boards that are very capable. But sometimes you need to — or just want to — do it yourself. Unfortunately, you really should design everything twice: once to figure out where all the problems are, and the second time to do it better. If you want to create your own board for the RP2040 then you are in luck. [Jeremy] has made the first (and second) iteration or an RP2040 board and shares with us what he would not do again.

In all fairness, he also has a blog post talking about what he did, so you might want to start there. However, we think his most valuable advice was his final word: Don’t fail to get started on your design. The longest journey, after all, begins with the first step.

His other advice is good, too. For example, don’t plug your new board into a computer because an error in the power supply could take the whole computer out. He also warns you not to do like he did and forget to order the $10 solder stencil with the PCBs.

Some of it is just good advice in general. For example — buy more small components than you think you need. There’s nothing worse than needing three resistors, having three resistors, and then watching one of the three fly across the room or stick to your soldering iron and melt into a pool of slag. Buy ten and you’ll save money in the long run.

In the end, the board did work and what he learned might help you if you decide to tackle a similar project yourself. [Jeremy’s] board is fairly large, but if you have an appetite for something smaller, check out the RPDot or the RP2040 Stamp.

RP2040 picture on left by Phiarc, CC BY-SA 4.0, via Wikimedia

Kaluma Puts JavaScript On The RP2040

With a simple firmware update, Kaluma puts a lightweight JavaScript runtime on the Raspberry Pi Pico (which uses the RP2040 microcontroller), providing handy modules for file systems, graphics, networking, and more. Code for a simple LED blink can then look like:

// index.js
const led = 25;
pinMode(led, OUTPUT);
setInterval(() => {
digitalToggle(led);
}, 1000);

Development can then be done using tools that are very familiar to JavaScript developers, such as npm and flashing new code to a USB-connected Pico with the (Node.js-based) Kaluma command-line interface. Take a look at the GitHub repository for the project, or browse some of the projects made with Kaluma.

Much like with MicroPython, there’s value to be had in putting implementations of high-level languages on microcontrollers. Each new language opens embedded programming to a whole new group of coders. But it’s not just languages making their way to the RP2040. Wonderful projects such as emulating the ZX Spectrum on an RP2040 also happen.

Thanks to [Shri Hari Ram] for the tip!

Dead E. Ruxpin Appears Alive And Well

What are you doing to scare trick-or-treaters this Halloween? Surely something, right? Well, Hackaday alum [CameronCoward] certainly has his holiday under control with Dead E. Ruxpin, a murderous, cassette tape-controlled animatronic bear.

Readers of a certain vintage will no doubt see the correlation to Teddy Ruxpin, an animatronic bear from the 1980s whose mouth moved as it read stories from cassette tapes. Cleverly, the engineers used one stereo channel for the story’s audio, and the other channel to control the bear’s mouth.

Dead E. Ruxpin takes this idea and expands it, using the same two channels to send audio and control three servo motors that move both arms and the mouth. How is this possible? By sending tones built from one or more frequencies.

Essentially, [Cameron] assigned a frequency to each movement: mouth open/closed, and left and/or right arm up or down. These are all, of course, synced up with specific points in the audio so Dead E. doesn’t just move randomly, he dances along with the music.

The bear is actually a hand puppet, which leaves room for a 3D-printed skeleton that holds the RP2040 and the servos and of course, moves the puppet’s parts. We can’t decide if we prefer the bulging bloodshot eyes, or think the cutesy original eyes would have made a scarier bear. Anyway, check out the build/demo video after the break to see it in action.

Are you now into Teddy Ruxpin? Here’s a bit more about those scare bears. And don’t forget, Halloween Hackfest runs now until October 31st.

Continue reading “Dead E. Ruxpin Appears Alive And Well”

RP2040 Emulator Brings The Voice Of The 80s Back To Life

You may not have heard, but there’s a chip shortage out there. And it’s not just the fancy new chips that are in short supply; the chips that were fancy and new back when you could still buy them from Radio Shack are getting hard to come by, too. For different reasons, of course, but it does pose a problem that requires a little hacking to fix.

The chip in question here is the General Instrument SP0256, a 1980s-era speech synthesizer chip that [Andrew Menadue] relies on. The LSI chip stored 59 unique allophones, or basic sounds the vocal tract is capable of, and synthesized speech by rapidly concatenating these sounds. The chip and its descendants made regular appearances in computers and games throughout the 80s, so chances are good you’ve heard it. If not, think WarGames (yes, we know that wasn’t actually a computerized voice) or [Stephen Hawking] and you’ll be pretty close.

[Andrew]’s need for such a chip stems from his attempts to give voice to his collection of Psion Organisers, another 80s relic that was one of the first pocket computers. Some time ago he built a speech board for the Psion based on the SP0256-AL2, but had to resort to building an emulator for the chip since none were to be had. The emulator uses an RP2040 and lives on a PCB that has the same footprint as the original chip, so it can just plug right in. He dug up WAV files of the allophones and translated those to sequences of bytes, allowing the RP2040 to output the correct sounds as they’re called for. Speaker problems notwithstanding, it sounds pretty good in the video below.

We’ve featured a fair number of SP0256 projects before, on everything from Amstrad to Z80. We’ve also shown off a few of [Andrew]’s builds before, including this exploration of the voltage tolerance of the RP2040.

Continue reading “RP2040 Emulator Brings The Voice Of The 80s Back To Life”

Accurate Cycle Counting On RP2040 MicroPython

The RP2040 is a gorgeous little chip with a well-defined datasheet and a fantastic price tag. Two SDKs are even offered: one based on C and the other MicroPython. More experienced MCU wranglers will likely reach for the C variant, but Python does bring a certain speed when banging out a quick project or proof of concept. Perhaps that’s why [Jeremy Bentham] ported his RP2040-based vehicle speedometer to MicroPython.

The two things that make that difficult are that MicroPython tries to be pretty generic, which means some hackery is needed to talk to the low-level hardware, and that MicroPython doesn’t have a reputation for accurate cycle counting. In this case, the low-level hardware is the PWM peripheral. He details the underlying mechanism in more detail in the C version. On the RP2040, the PWM module can count pulse edges on an input. However, you must start and stop it accurately to calculate the amount of time captured. From there, it’s just edges divided by time. For this, the DMA system is pulled in. A DMA request can be triggered once the PWM counter rolls over. The other PWM channel acts as a timer, and when the timer expires, the DMA request turns off the counter. This works great for fast signals but is inaccurate for slow signals (below 1kHz). So, a reciprocal or time-interval system is included, where the time between edges is captured instead of counting the number of edges in a period,

What’s interesting here is how the hardware details are wrapped neatly into pico_devices.py. The uctypes module from MicroPython allows access to MMIO devices such as DMA and PWM. The code is available on GitHub. Of course, [Jeremy] is no stranger to hacking around on the RP2040, as he has previously rolled his own WiFi driver for the Pico W.

RPDot: The RP2040 Dev Board Barely Bigger Than The Chip

Is [William Herr]’s RPDot actually the world’s smallest RP2040 dev board? We can’t say for sure, but at 10 mm on a side, we’d say it has a pretty good shot at the record.

Not that it really matters, mind you — the technical feat of building a fully functional dev board that’s only 3 mm longer on each side than the main chip is the kind of stuff we love to see. [William] says he took inspiration from the [SolderParty] RP2040 Stamp, which at one inch (25.4 mm) on a side is gigantic compared to the RPDot. Getting the RP2040 and all the support components, which include an 8MB QSPI Flash chip, a 3V3 LDO, a handful of 0201 passives, and even a pair of pushbuttons, required quite a lot of design tweaking. He started his PCB design as a four-layer board; while six layers would have made things easier, the budget wouldn’t allow such extravagance for a prototype. Still, he somehow managed to stuff everything in the allotted space and send the designs off — only to get back defective boards.

After reordering from a different vendor, the real fun began. Most of the components went on the front side of the board and were reflowed using a hot plate. The RP2040 itself needed to go on the back side, which required gentle hot air reflow so as not to disrupt the other side of the board. The results look pretty good, although those castellated edges look a little worse for the wear. Still, for someone who only ever worked with 0402 components before, it’s pretty impressive.

[William] says he’s going to open-source the designs as well as make some available for sale. We’ll be looking out for those and other developments, but for now, it’s just pretty cool to see such SMD heroics.