The Need For Speed?

May 24, 2025 by Elliot Williams 18 Comments

We wrote up a video about speeding up Arduino code, specifically by avoiding DigitalWrite. Now, the fact that DigitalWrite is slow as dirt is long known. Indeed, a quick search pulls up a Hackaday article from 2010 demonstrating that it’s fifty times slower than toggling the pin directly using the native pin registers, but this is still one of those facts that gets periodically rediscovered from generation to generation. How can this be new again?

First off, sometimes you just don’t need the speed. When you’re just blinking LEDs on a human timescale, the general-purpose Arduino functions are good enough. I’ve written loads of useful firmware that fits this description. When the timing requirements aren’t tight, slow as dirt can be fast enough.

But eventually you’ll want to build a project where the old slow-speed pin toggling just won’t cut it. Maybe it’s a large LED matrix, or maybe it’s a motor-control application where the loop time really matters. Or maybe it’s driving something like audio or video that just needs more bits per second. One way out is clever coding, maybe falling back to assembly language primitives, but I would claim that the right way is almost always to use the hardware peripherals that the chipmakers gave you.

For instance, in the end of the video linked above, the hacker wants to drive a large shift register string that’s lighting up an LED matrix. That’s exactly what SPI is for, and coming to this realization makes the project work with timing to spare, and in just a few lines of code. That is the way.

Which brings me to the double-edged sword that the Arduino’s abstraction creates. By abstracting away the chips’ hardware peripherals, it makes code more portable and certainly more accessible to beginners, who don’t want to learn about SPI and I2C and I2S and DMA just yet. But by hiding the inner workings of the chips in “user friendly” libraries, it blinds new users to the useful applications of these same hardware peripherals that clever chip-design engineers have poured their sweat and brains into making do just exactly what we need.

This isn’t really meant to be a rant against Arduino, though. Everyone has to start somewhere, and the abstractions are great for getting your feet wet. And because everything’s open source anyway, nothing stops you from digging deeper into the datasheet. You just have to know that you need to. And that’s why we write up videos like this every five years or so, to show the next crop of new hackers that there’s a lot to gain underneath the abstractions.

Where Is The End Of DIY?

October 5, 2024 by Elliot Williams 72 Comments

Al and I were talking on the podcast about Dan Maloney’s recent piece on how lead and silver are refined and about the possibility of anyone fully understanding a modern cellphone. This lead to Al wondering at the complexity of the constructed world in which we live: If you think hard enough about anything around you right now, you’d probably be able to recreate about 0% of it again from first principles.

Smelting lead and building a cellphone are two sides of coin, in my mind. The process of getting lead out of galena is simple enough to comprehend, but it’s messy and dangerous in practice. Cellphones, on the other hand, are so monumentally complex that I’d wager that no single person could even describe all of the parts in sufficient detail to reproduce them. That’s why they’re made by companies with hundreds of engineers and decades of experience with the tech – the only way to build a cellphone is to split the complicated task into many subsystems.

Smelting lead is a bad DIY project because it’s simple in principle, but prohibitive in practice. Building a cellphone from the ground up is incomprehensible in principle, but ironically entirely doable in practice if you’re willing to buy into some abstractions.

Indeed, last week we saw a nearly completely open-source build of a simple smartphone, and the secret to making it work is knowing the limits of DIY. The cell modem, for instance, is a black box. It’s an abstract device that you can feed data to and read data from, and it handles the radio parts of the phone that would take forever to design from scratch. But you don’t need to understand its inner workings to use it. Knowing where the limits of DIY are in your project, where you’re willing to accept the abstraction and move on, can be critical to getting it done.

Of course, in an ideal world, you’d want the cell modem to be like smelting lead – something that’s possible to understand in principle but just not worth DIYing in practice. And of course, there are some folks out there who hack on cell modem firmware and others who could do the radio engineering. But despite my strong DIY urges, I’d have to admit that the essential complexity of the module simply makes it worth treating as a black box. It’s very probably the practical limit of DIY.

Abstracting Transistors Into High-level Design

November 26, 2012 by Brian Benchoff 10 Comments

Although it’s not the best way of understanding computers, most people tend to imagine electronic devices as black boxes filled with magic and blue smoke. Even microcontrollers, the most fundamental means of computation, are treated like little black plastic centipedes with metal legs. In a series of blog posts, [Andrew Gibiansky] is tearing down the walls of obfuscation and illuminating the world of transistors, gates, and FPGAs.

The first blog post goes over the idea of electronic circuits as a waterfall; a positive voltage is a reservoir on a mountain top and ground is sea level. This idea is extended to the lowly transistor acting as an electronic switch, able to turn a circuit on and off.

Continuing on to logic gates, [Andrew] covers the NOT, AND, and OR gates before moving on the flip-flops and SRAM. These can, of course, be modeled in Verilog and VHDL – programming languages that abstract the world of transistors and gates into a much more human-readable form.

[Andrew] is far from done with his series of blog posts, but judging from his work so far it seems to be a great resource for untangling the obtuse concepts of gates and memory into the coherent design of a computer.

Map Abstraction API In Javascript

July 11, 2008 by Juan Aguilar 1 Comment

Maybe you’ve tinkered a bit with the Google Maps API. Most of the software produced with it is not all that useful or entertaining, but a few gem have shone through. Still, wouldn’t it be better if applications produced with it could be easily ported to other online mapping services like Mapquest or Yahoo! Maps?

This is possible with Mapstraction, a Javascript API that works with nine mapping services and plans to incorporate more into the fold. Mapstraction has open-source features that normalize functions across the biggest services, which makes searching for map data a consistent, predictable experience no matter which service you use.

Some of Mapstraction’s current features are what you would expect: point, line, and polygon support, image overlay, GeoRSS and KML feed importing, and several others. We’re really looking forward to future versions with OpenStreetMap support. Currently Mapstraction works with only commercial mapping services, but OpenStreetMap combined with Mapstraction directly hits the sweet spot; a customizable, open source map.

[via Hackszine]