New Parts, New Hacks

The biggest news this week is that Raspberry Pi is no longer synonymous with single-board Linux computers: they’re dipping their toes into the microcontroller business with their first chip: the RP2040, and the supporting breakout board, the Pico. It’s an affordable, capable microcontroller being made by a firm that’s never made microcontrollers before, so that’s newsy.

The Hackaday comments lit on fire about this chip, with some fraction of the commenters lamenting the lack of wireless radios onboard. It’s a glass-half-full thing, I guess, but the RP2040 isn’t an ESP32, folks. It’s something else. And it’s got a hardware trick up its sleeve that really tickles my fancy — the programmable input/output (PIO) units.

The other half of the commenters were, like me, salivating about getting to try out some of the new features. The PIO, of course, was high on that list, but this chip also caters to folks who are doing high-speed DSP, with fast multiplication routines burnt into ROM and a nice accumulator. (You know you’re a microcontroller nerd when you’re reading through a 663-page datasheet and thinking about all the funny ways you can use and/or abuse the hardware peripherals.)

All chip designs are compromises. Nothing can do everything. The new peripherals, novel combinations of old elements, and just pleasant design decisions, open up new opportunities if you’re willing to seek them out. When the ESP32 was new, I was looking at their oddball parallel-I2S hardware and thinking what kind of crazy hacks that would enable, and clever hackers have proven me right. I’d put my money on the PIO being similar.

New chips open up new possibilities for hacks. What are you going to do with them?

Raspberry Pi Enters Microcontroller Game With $4 Pico

Raspberry Pi was synonymous with single-board Linux computers. No longer. The $4 Raspberry Pi Pico board is their attempt to break into the crowded microcontroller module market.

The microcontroller in question, the RP2040, is also Raspberry Pi’s first foray into custom silicon, and it’s got a dual-core Cortex M0+ with luxurious amounts of SRAM and some very interesting custom I/O peripheral hardware that will likely mean that you never have to bit-bang again. But a bare microcontroller is no fun without a dev board, and the Raspberry Pi Pico adds 2 MB of flash, USB connectivity, and nice power management.

As with the Raspberry Pi Linux machines, the emphasis is on getting you up and running quickly, and there is copious documentation: from “Getting Started” type guides for both the C/C++ and MicroPython SDKs with code examples, to serious datasheets for the Pico and the RP2040 itself, to hardware design notes and KiCAD breakout boards, and even the contents of the on-board Boot ROM. The Pico seems designed to make a friendly introduction to microcontrollers using MicroPython, but there’s enough guidance available for you to go as deep down the rabbit hole as you’d like.

Our quick take: the RP2040 is a very well thought-out microcontroller, with myriad nice design touches throughout, enough power to get most jobs done, and an innovative and very hacker-friendly software-defined hardware I/O peripheral. It’s backed by good documentation and many working examples, and at the end of the day it runs a pair of familiar ARM MO+ CPU cores. If this hits the shelves at the proposed $4 price, we can see it becoming the go-to board for many projects that don’t require wireless connectivity.

But you want more detail, right? Read on.

Continue reading “Raspberry Pi Enters Microcontroller Game With $4 Pico”

Hackability Matters

The Unix Way™ provides extreme hackability. The idea is that software should be written as tools to accomplish discrete tasks, and that it should be modular, extensible, and play well with others. It’s like software as a LEGO set — you can put the blocks together however you want, within limits, and make stuff that’s significantly cooler than any of the individual blocks alone.

Clearly this doesn’t work for all applications — things like graphics editors and web browsers don’t really lend themselves to being elegant tools that integrate well with others, right? It’s only natural that they’re bloaty walled gardens. What happens in the browser must stay in the browser, right?

But how sad is it that the one piece of software you use all day, your window into cyberspace, doesn’t play well with the rest of your system? I’d honestly never really been bothered by that fact until stumbling on TabFS. It’s an extension to Chrome that represents the tabs on your browser as if they were files on your local system — The Unix Way™. And what this means is that any other program that can read from or write to a file can open tabs, collect them, change webpages on the fly, and so on. It opens up the browser to you.

This is tremendously powerful. Don’t like the bookmarking paradigm of your particular browser? Writing your own would be a snap in Python — and you could do cleverer things like apply a little machine learning to handle putting them in categories. Want to pop open (or refresh) a set of webpages at a particular time every day? Cron, or its significantly more complicated counterpart systemd, and a couple lines of code will do that. Want to make a hardware button that converts dark mode to light mode and vice-versa for every website starting with “H”? Can do.

I’m picking on browsers, but many large pieces of software are inaccessible in the same way — even if they’re open source, they don’t open up channels for interaction with user code or scripts. (Everything “in the cloud” or “as a service”, I’m looking at you! But that’s a further rant for another day.) And that’s a shame, because most of these “big” pieces of software actually do the coolest things.

So please, if you’re working on a big software package, or even just writing a plug-in for one, do think about how you can make more of its abilities available to the casual scripter. Otherwise, it’s just plastic blocks that don’t fit with the rest of the set.

The Shell And The Microcontroller

One of the nicest amenities of interpreted programming languages is that you can test out the code that you’re developing in a shell, one line at a time, and see the results instantly. No matter how quickly your write-compile-flash cycle has gotten on the microcontroller of your choice, it’s still less fun than writing blink_led() and having it do so right then and there. Why don’t we have that experience yet?

If you’ve used any modern scripting language on your big computer, it comes with a shell, a read-eval-print loop (REPL) in which you can interactively try out your code just about as fast as you can type it. It’s great for interactive or exploratory programming, and it’s great for newbies who can test and learn things step by step. A good REPL lets you test out your ideas line by line, essentially running a little test of your code every time you hit enter.

This is your development environment

The obvious tradeoff for ease of development is speed. Compiled languages are almost always faster, and this is especially relevant in the constrained world of microcontrollers. Or maybe it used to be. I learned to program in an interpreted language — BASIC — on computers that were not much more powerful than a $5 microcontroller these days, and there’s a BASIC for most every micro out there. I write in Forth, which is faster and less resource intensive than BASIC, and has a very comprehensive REPL, but is admittedly an acquired taste. MicroPython has been ported over to a number of micros, and is probably a lot more familiar.

But still, developing MicroPython for your microcontroller isn’t developing on your microcontroller, and if you follow any of the guides out there, you’ll end up editing a file on your computer, uploading it to the microcontroller, and running it from within the REPL. This creates a flow that’s just about as awkward as the write-compile-flash cycle of C.

What’s missing? A good editor (or IDE?) running on the microcontroller that would let you do both your exploratory coding and record its history into a more permanent form. Imagine, for instance, a web-based MicroPython IDE served off of an ESP32, which provided both a shell for experiments and a way to copy the line you just typed into the shell into the file you’re working on. We’re very close to this being a viable idea, and it would reduce the introductory hurdles for newbies to almost nothing, while letting experienced programmers play.

Or has someone done this already? Why isn’t an interpreted introduction to microcontrollers the standard?

Remoticon Video: The Mechanics Of Finite Element Analysis

Hardware hacking can be extremely multidisciplinary. If you only know bits and bytes, but not solder and electrons, you’re limited in what you can build. The same is true for mechanical design, where the forces of stress and strain suddenly apply to your project and the pile of code and PCBs comes crashing to the ground.

In the first half of his workshop, Naman Pushp walks you through some of the important first concepts in mechanical engineering — how to think about the forces in the world that act on physical objects. And he brings along a great range of home-built Jugaad props that include a gravity-defying tensegrity string sculpture and some fancy origami that help hammer the topics home.

In the second half of the workshop, Naman takes these concepts into computer simulation, and gives us good insight into the way that finite-element analysis simulation packages model these same forces on tiny chunks of your project’s geometry to see if it’ll hold up under real world load. The software he uses isn’t free by any definition — it’s not even cheap unless you have a student license — but it’s nonetheless illuminating to watch him work through the flow of roughly designing an object, putting simulated stresses and strains on it, and interpreting the results. If you’ve never used FEA tools before, or are looking for a compressed introduction to first-semester mechanical engineering, this talk might be right up your alley. Continue reading “Remoticon Video: The Mechanics Of Finite Element Analysis”

Remoticon Video: KiCad To Blender PCB Renders

We seem to want our PCB design software to do everything these days, and it almost delivers. You can not only lay it all out, check electrical and design rules, and even spit out a bill of materials, but many PCB tools produce 3D models that are good enough to check parts clearance or are useful in designing enclosures. But when it comes to producing photorealistic output, whether for advertising or just for eye-candy, you might want to turn to 3D design tools.

In this workshop, Anool Mahidharia takes the output of KiCad’s VRML export, gets it rendering in Blender, and then starts tweaking the result until you’re almost not sure if it’s the real thing or a 3D model. He starts off with a board in KiCad, included in the project’s GitHub repo, and you can follow along through the basic import, or go all the way to copying the graphics off the top of an ATtiny85 and making sure that the insides of the through-plated holes match the tops.

If you don’t know Blender, maybe you don’t know how comprehensive a 3D modelling and animation tool it is. And with the incredible power comes a notoriously steep learning curve up a high mountain. Anool doesn’t even try to turn you into a Blender expert, but focuses on the tweaks and tricks that you’ll need to make good looking PCB renders. You’ll find general purpose Blender tutorials everywhere on the net, but if you want something PCB-specific, you’ve come to the right place.

Continue reading “Remoticon Video: KiCad To Blender PCB Renders”

Label Your Shtuff!

Joshua Vasquez wrote a piece a couple of weeks ago about how his open source machine benefits greatly from having part numbers integrated into all of the 3D printed parts. It lets people talk exactly about which widget, and which revision of that widget, they have in front of them.

Along the way, he mentions that it’s also a good idea to have labels as an integrated part of the machine anywhere you have signals or connectors. That way, you never have to ask yourself which side is positive, or how many volts this port is specced for. It’s the “knowledge in the head” versus “knowledge in the world” distinction — if you have to remember it, you’ll forget it, but if it’s printed on the very item, you’ll just read it.

I mention this because I was beaten twice in the last week by this phenomenon, once by my own hand costing an hour’s extra work, and once by the hand of others, releasing the magic smoke and sending me crawling back to eBay.

The first case is a 3D-printed data and power port, mounted on the underside of a converted hoverboard-transporter thing that I put together for last year’s Chaos Communication Congress. I was actually pretty proud of the design, until I wanted to reflash the firmware a year later.

I knew that I had broken out not just the serial lines and power rails (labelled!) but also the STM32 SWD programming headers and I2C. I vaguely remember having a mnemonic that explained how TX and RX were related to SCK and SDA, but I can’t remember it for the life of me. And the wires snake up under a heatsink where I can’t even trace them out to the chip. “Knowledge in the world”? I failed that, so I spent an hour looking for my build notes. (At least I had them.)

Then the smoke came out of an Arduino Mega that I was using with a RAMPS 1.4 board to drive a hot-wire cutting CNC machine. I’ve been playing around with this for a month now, and it was gratifying to see it all up and running, until something smelled funny, and took out a wall-wart power supply in addition to the Mega.

All of the parts on the RAMPS board are good to 36 V or so, so it shouldn’t have been a problem, and the power input is only labelled “5 A” and “GND”, so you’d figure it wasn’t voltage-sensitive and 18 V would be just fine. Of course, you can read online the tales of woe as people smoke their Mega boards, which have a voltage regulator that’s only good to 12 V and is powered for some reason through the RAMPS board even though it’s connected via USB to a computer. To be honest, if the power input were labelled 12 V, I still might have chanced it with 18 V, but at least I would have only myself to blame.

Part numbers are a great idea, and I’ll put that on my list of New Year’s resolutions for 2021. But better labels, on the device in question, for any connections, isn’t even going to wait the couple weeks until January. I’m changing that right now.