The Right Tools For The Job

February 6, 2021 by Elliot Williams 16 Comments

We’re knee-deep in new microcontrollers over here, from the new Raspberry Pi Pico to an engineering sample from Espressif that’s right now on our desk. (Spoiler alert, review coming out Monday.) And microcontroller peripherals are a little bit like Pokemon — you’ve just got to catch them all. If a microcontroller doesn’t have 23 UARTS, WiFi, Bluetooth, IR/DA, and a 16-channel 48 MHz ADC, it’s hardly worth considering. More is always better, right?

No, it’s not. Chip design is always a compromise, and who says you’re limited to one microcontroller per project anyway? [Francesco] built a gas-meter reader that reminded to think outside of the single-microcontroller design paradigm. It uses an ATtiny13 for its low power sleep mode, ease of wakeup, and decent ADCs. Pairing this with an ESP8266 that’s turned off except when the ATtiny wants to send data to the network results in a lower power budget than would be achievable with the ESP alone, but still gets his data up into his home-grown cloud.

Of course, there’s more complexity here than a single-micro solution, but the I2C lines between the two chips actually form a natural division of work — each unit can be tested separately. And it’s using each chip for what it’s best at: simple, low-power tasks for the Tiny and wrangling WiFi on the ESP.

Once you’ve moved past the “more is better” mindset, you’ll start to make a mental map of which chips are best for what. The obvious next step is combination designs like this one.

Run The Math, Or Try It Out?

January 30, 2021 by Elliot Williams 39 Comments

I was reading Sonya Vasquez’s marvelous piece on the capstan equation this week. It’s a short, practical introduction to a single equation that, unless you’re doing something very strange, covers everything you need to know about friction when designing something with a rope or a cable that has to turn a corner or navigate a wiggle. Think of a bike cable or, in Sonya’s case, a moveable dragon-head Chomper. Turns out, there’s math for that! Continue reading “Run The Math, Or Try It Out?” →

Before Google, There Was The Reference Librarian

January 27, 2021 by Al Williams 75 Comments

I know it is a common stereotype for an old guy to complain about how good the kids have it today. I, however, will take a little different approach: We have it so much better today when it comes to access to information than we did even a few decades ago. Imagine if I asked you the following questions:

Where can you have a custom Peltier device built?
What is the safest chemical to use when etching glass?
What does an LM1812 IC do?
Who sells AWG 12 wire with Teflon insulation?

You could probably answer all of these trivially with a quick query on your favorite search engine. But it hasn’t always been that way. In the old days, we had to make friends with three key people: the reference librarian, the vendor representative, and the old guy who seemed to know everything. In roughly that order. Continue reading “Before Google, There Was The Reference Librarian” →

A Few Of My Favorite Things: Amateur Radio

January 21, 2021 by Jenny List 50 Comments

Hackaday has among its staff a significant number of writers who also hold amateur radio licenses. We’re hardware folks at heart, so we like our radios homebrew, and we’re never happier than when we’re working at high frequencies.

Amateur radio is a multi-faceted hobby, there’s just so much that’s incredibly interesting about it. It’s a shame then that as a community we sometimes get bogged down with negativity when debating the minutia. So today let’s talk about a few of my favourite things about the hobby of amateur radio. I hope that you’ll find them interesting and entertaining, and in turn share your own favorite things in the comments below.

Continue reading “A Few Of My Favorite Things: Amateur Radio” →

The Origin Of Cut, Copy, And Paste

January 20, 2021 by Al Williams 90 Comments

I’m always fascinated that someone designed just about everything you use, no matter how trivial it is. The keyboard you type on, the light switch you turn on, even the faucet handle. They don’t just spontaneously grow on trees, so some human being had to build it and probably had at least a hazy design in mind when they started it.

Some things are so ubiquitous that it is hard to remember that someone had to dream them up to begin with. A friend of mine asked me the other day why we use Control+X and Control+V to manipulate the clipboard almost universally. Control+C for copy makes sense, of course, but it is still odd that it is virtually universal in an industry where everyone likes to reinvent the wheel. I wasn’t sure of the answer but figured it had to do with some of the user interface standards from IBM or Sun. Turns out, it is much older than that.

Continue reading “The Origin Of Cut, Copy, And Paste” →

Hackability Matters

January 16, 2021 by Elliot Williams 42 Comments

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

January 9, 2021 by Elliot Williams 104 Comments

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.

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?