I'm kicking off a regular feature that digresses more than a little from the usual focus on programming as a vocation and a business.
I've been faffing about with Arduino since January of 2015 and failing my way into micro-controller programming every since. To date, I've done far more personal tinkering than professional work. And while I've learned whole new skills throughout the last seven years, the lesson that hit hardest was how the overlap between folks who understand circuitry and folks who can write code for micro-controllers is surprisingly thin.
That said, the RaspberryPi and, to a greater extent, Arduino (and the ecosystem it spawned) have been nothing short of game-changing. Correspondingly, an abundance of inexpensive, usually breadboard-friendly electronics (what I'm going to call "widgets" from here on out) has mushroomed. Which puts both those ecosystems into something of a virtuous cycle.
Mostly, I play for Team Arduino. My use-case for the RaspberryPi has largely involve running tiny, specialised web servers inside a network. In this context, I adore the Pi. But for what's generally known as "physical computing"? It's a sub-optimal form-factor. Now, for all I know, this might have changed with later models. But the earlier Pi iterations offered a laughably low amount of current to any 3rd party widgets connected to them. I'm talking about hooking up three 3mm LEDs and powering them at ~80% capacity. From a board that requests a 2-Amp power supply (enough to power 100 of these LEDs)? Yeah, laughable.
Additionally, my experience with the Pi (thus far) is that it's Global Thermonuclear Armageddon(TM) levels of overkill when it comes to the computing power it takes to process these widgets' input and output. Mainly because whatever's controlling the widget often only needs to know "Is it on or is it off right at this very microsecond/nanosecond?" Or, "Does this widget need to be on or off at this very nanosecond/millisecond?" Or, if we start to get fancy, "Is it outputting a current somewhere between 0V and 5V right now?"
For that purpose, the Arduino's 8-bit processor and trivial storage space are more than adequate. Face it: 8-bit computing ran the original Space Shuttles. And I'm more interested in the Space Shuttle, vs. the number-crunching IBM beasties that computed its trajectories/orbits Back In The Day(TM).
Now. For a 21st-century web programmer who takes 64-bit processing with gigabytes of memory/storage for granted, there was for sure some Getting-Used-To(TM) involved. But I was lucky enough to stumble into Programming School(TM) in the 1990s when C/C++ was still used to flush out the posers. (Hello, bit-shifting and bit-masking!) Then stuff like StackOverflow happened and embedded computing stopped being such a High Priesthood.
But as much as I manage to fumble and faff my way through circuit-diagrams, I will always, always see things through a coding lens. Alas, that's not the best perspective from which to learn - much less presume to coach anyone else in learning -- this topic. I personally know at least a half-dozen folks who have legit. forgotten more circuitry than I will ever know. But they come to me for code. And there lies the rub.
So on those occasions when I'm asked to teach Arduino, I am fully, cringingly, aware of the huge disservice I'm doing by skimming through the bare-bones concepts of, say, Ohm's law or how to calculate resistor values. Or what to look for in a datasheet. Yadayadayada.
Because the reality is that if you're already a programmer, learning the Arduino API is literally the least of your concerns. That's even true when you get bored with the API and branch out into the pure C/C++ code beneath the surface...or (gasp!) the snippets of Assembly language that can be spliced in when performance matters. No, it's the hardware (not to mention the electromagnetic branch of physics) that will hose you from Hell to breakfast and back again. So you'd better get used to the idea before you get cocky. There's coding for the hermetically-sealed walled garden of a web browser or smartphone. And then there's the messy real world. Where allllllllll sorts of things can go wrong.
The upshot is that, while I might have to screen-shot snippets of code from time to time, right now I really can't see needing anything like a Git repository. Maybe for the datasheets? I dunno -- I guess we're going to find out together.
Specifically, I will be focusing on electronics components that I have used -- or for which I have a designated project. In reality, a lot of this will be an exercise in me thinking out loud, to some degree organising a meandering reference manual for my own sweet sake. Documenting things, even things I already know, forces me to understand them at a deeper level. Writing, even as a moderately fast typist, slows me down. That's a good thing. I have no option but to question how, exactly, I actually came to know what I think I know. Sometimes that's a rude awakening. But again, this is a good thing.
Thus, this series/feature will start off pretty basic and hew fairly close to the proverbial metal: Elemental generic components to start, progressing to inexpensive, breadboard-friendly "breakout boards." Again, we can thank the Pi/Arduino ecosystems for the absolute embarrassment of riches we now enjoy here. Limor Fried's Adafruit (and similar businesses like Sparkfun) has reaped the dividends of the education they've sown (in tandem with making these boards affordable enough to take a lot of the risk out of tinkering). Explaining basic concepts like "What is a circuit?" "How are Current, Resistance, and Voltage related?" in a way that doesn't make anyone feel condescended-to is an invaluable service to beginners who might not have access to formal education.
Additionally, Adafruit and Sparkfun, like the Digikey-/Mouser-scale suppliers, are good about providing datasheets/specs. (WIDGET SHOPPING COMMANDMENT #1: Thou shalt not add a widget to thine cart without downloading its datasheet.) Datasheets exist to splash some cold reality on the idea you had in this morning's shower. E.g.: This widget won't (reliably) work if the ambient temperature is below the freezing point. Or: This widget operates at a different voltage than the microcontroller.
But, helpful as tutorials and datasheets both are -- and you always read them both, riiiiiiiiight??? -- someone stepping beyond the "Hello, World!" winky-blinky LED phase of embedded electronic development is left to fend for themselves on their first non-trivial project. That can leave a newbie on the proverbial horns of a dilemma:
- A widget's datasheet will tell you the min./max.voltages/currents/temperatures/etc. of where it will and won't work. But it's hardly inspiring.
- A project found on the web may have a given widget in its parts-list but give no clue about what makes that particular widget a good fit for that particular project. (So screw your project, amirite?)
"Widget Wednesday" aims to fill that gap. So when a given widget is profiled, the first thing covered is "What is it good for?" Then we'll address things like constraints, limitations, tolerances, reliability, etc.. Like I said, I've been doing this for several years; I have a few war-stories to share. Elsewhere, I've only been half-joking when I've said that the most toe-curling five words in the English Language are "Ask me how I know." Stick with me, and you'll find out.
Until next time, Tchein ton siault d'beluets!
