6/5/2014– Eric Kolker
You hear the phrase “hardware is hard” a lot these days, usually when someone is new to hardware, and often in the context of what it takes to build it. Without forcing words into peoples’ mouths, the speaker is generally trying to convey the sense that building hardware feels more difficult than building other things because there’s so much to keep track of and think about.
As someone who designs hardware but is joining the world of software, I have some problems with this shorthand dismissal and what it implies. I’m also making a conscious point of saying this just as the first Tessels are hitting your mailboxes and as some of you are getting your first taste of hardware.
“Hardware is hard”
No, it isn’t. Really. If anything, software is just incredibly easy. However, because many people who started off in software are now interested in hardware (hopefully you!), it behooves us all to try to understand what they’ve gotten themselves into and how it’s different from what they’re used to.
Allow me to back up, explain, and then offer some advice before we all leap headfirst into the world of hardware.
My background is in electrical engineering. In previous lives, I built and programmed robots small and large – everything from LEGO MindStorms to Boston Dynamics’ LS3, which, at the time, was arguably the most advanced quadruped robot in the world. I’ve designed large portions of a small satellite, an ultra-high bandwidth, medical-grade wireless data link for CT scanners, and my own integrated circuit. I’m used to, and indeed completely comfortable with, creating entire systems which work correctly the first time, due in large part to careful architecting, simulation, and a firm grasp of innards of every would-be black box and pitfall in the system. I’m accustomed to spending enough time planning that the implementation goes off largely without a hitch, which is typically the expectation for electrical engineers.
All that goes to say that hardware engineers must be considerably more careful about the work they do than web developers because the costs of a second chance are so much higher. Case in point: I have never met an EE who would even entertain the notion of “FISI” because doing so is unforgivably irresponsible and expensive on so many levels.
Don’t get me wrong, there are certainly programmers who are more risk-averse than I and whose systems cannot afford to fail. My point is just that many web developers have luxuries which allow them to be a little more cavalier than hardware engineers can typically afford to be. In the end, these luxuries allow for the buildup of bad habits for dealing with hardware.
What’s actually different?
Hardware and software happen at different speeds and require different skill sets. In a nutshell, hardware requires more caution, attention to detail, patience, and knowledge of a broader range of topics than software because most of the time, the building blocks are, admittedly, harder to assemble. The black boxes in hardware are less ideal than those you encounter in software because they exist physically in the real world (as opposed to merely as instances of ideas), and are therefore more sensitive to their neighbors.
A few choice examples come to mind:
- Things cost more money and time. Supply chains, fabrication time, shipping, and calibration all have very different definitions and consequences for hardware. Missteps as a result of any of these can destroy companies alltogether.
- More fundamentally and ironically, because computers start off as electrical systems, each of their operations happen on electrical timescales (the timescales of chemical reactions and light), while electrical systems begin their lives as mechanical systems, which necessarily move much more slowly.
- In hardware, debugging is not as easy as
console.log. Instead, it often requires additional equipment that can cost thousands of dollars and takes time to set up, adjust, and calibrate. Fractions of a millimeter and millionths of a second matter, often tremendously; sometimes electrical systems are so sensitive that measuring the system will change the way that it behaves.
- On top of all that, a thorough grasp of the system’s physics is often tremendously important, if not essential, to understanding its subtleties (read: pitfalls, failure modes, etc.). This may sound weird, but the simple fact that modern computers are treated as discrete and digital devices with well-defined interfaces is simultaneously one of their most valuable traits and largest liabilities. Because software typically assumes that we can draw hard lines that place things firmly in one of two states, we rarely account for the fact that physical systems are actually analog and asynchronous. These assumptions are therefore implicitly built upon approximations rather than absolutes. …And without getting too meta, the crux of the issue is that problems typically arise due to the approximations we make at the intersections between digital and analog.
We’ve done our best with Tessel to make sure that you don’t need to do or worry too much about any of the really nasty hardware bits, but you’ll still need to come the last 10%. Understand that the consequences are more real than they are with software if you don’t read the documentation and/or do something careless with the product.
Think about what you want to build, understand your system’s requirements, and set specifications that are both physically possible and sensible. Do research into what goes into anything you build, and ask lots of questions on the forums. I promise we’ll do our best to answer them.
Last but not least, come to terms with the cost of developing embedded systems in JS: performance. Fundamentally, you’re working with an interpreted language (JS) that has been transpiled to another (Lua), which is being interpreted by something other than V8, which is running on a 180 MHz processor. Tessel is certainly no iPhone, but we’re confident that it’s more powerful and more versatile than similar products which run JS because it’s node-compatible and doesn’t need a lifeline to the PC. You’ll be fine so long as you don’t try to stream video, run intensive algorithms, load 14 different node modules, or demand that your loops run at 100Hz.
Call to action
…So what I ask of you is actually pretty simple. Appreciate that Tessel has been about a year in the making and that in order to use it properly you may need to learn a little bit about what goes on under the hood. Together we can make hardware prototyping easier, but doing so will require that we do more than admire electrical systems when they walk by (guilty parties typically include “LED all the things!” and “OMG quadcopters!”). Read our documentation before you run into trouble, then look up anything that continues to misbehave.
Once your projects take you to the edge of what our modules can do, I hope you’ll take the plunge and try your hand at building hardware, and in doing so start to see why the people on my side of the table have the habits we do.
Most importantly, I hope you learn a lot and have a lot of fun, so get out there and start building!