Great write-up from perspective of a non-hardware guy. A few things in the write-up also reinforce how important it is for reliability or security engineers mitigating hardware issues to have a thorough understanding of analog and RF. Especially how the components that look separate or just one-way at a logical level are actually interacting at an electrical level with currents moving in multiple directions. The abstractions we operate on at a system or software level, maybe even the digital level, are effectively convenient lies. Things are really messy underneath.
Those skills seem harder to learn, too. Resources are either math/theory-heavy or tinkering in the dark. Only one in the middle I found was people recommending Gammel’s Contextual Electronics. I might try it in the future when I have time but I imagine learning analog & PCB’s will take plenty of time and money. Although on hold for now, I got NAND2Tetris to get my foot in the door of hardware. If I can learn digital, I figure I can just pay an honest engineer to do the analog and RF since it’s a tiny part of overall design.
Hardware Engineering is not so hard….
It’s exactly like Software Engineering.
Except all the basic primitives were devised by satan.
Things that shouldn’t leak, leak, things that take no current do, connections are dodgy, zero resistance connections have impedance, things behave quantum mechanically at high frequencies, you need to understand clocking and clock domains, everything emits, everything receives, everything has resonant frequencies…..
Apart from that it’s “Just Programming”.
Maybe Flow-based, Distributed Programming on a Heterogenous Network-on-a-Chip of probabilistic, limited-precision CPU’s and custom ASIC’s. ;)
Yeah I’m totally new to a lot of this myself and regularly feel imposter syndrome in a big way. I’m just glad I’m trying to make things easier for people who haven’t put their first foot on the ladder yet.
I’m definitely going to take a look at Contextual Electronics, thanks for the link. We’re filling out our docs site, which (if you swap some of the pin references) works just as well on Arduino if you feel like having a go.
I found Practical Electronics for Inventors a handy reference, and Forrest Mims books are really good for examples of analogue circuits.
Appreciate the tips. Far as CA, reviewers said it gradually builds up your knowledge with a project at a time mixing theory and practice. I dont know anything else as Im unqualified to judge.
Great resource, steve (I’m not the target audience but I think there is a large segment of people who are, and they’ll appreciate it.)
Are you interested in suggestions for ways to make the example schematic from the post easier to read and understand?
Definitely. Although we’re selling the boards, this is very much a side hustle with the goal of funding better docs to help people get into electronics rather than a quest for millions. The Eagle CAD files are up on Github, and any thoughts/wisdom/help would be gratefully received.
Awesome! Well, a few things sprang to mind (I’ve drawn quite a few schematics so this is applying my “internal checklist” to this one):
Philosophically I think about schematics similarly to the quote about “programs must be written for people to read, and only incidentally for machines to execute.” View the schematic as primarily for showing people how the circuit behaves, it just happens to double as machine-readable representation for creating a PCB.
With this in mind, schematic is a language for communication. And like programming languages, it’s partially about clear expression and partially about using familiar and consistent conventions.
In the same way reading code makes a better programmer, reading schematics can make you a better schematic author. If you ever get a chance to read the schematic for something like a mobile phone, these are super interesting (mostly because they’re so simply laid out with tons of labels and basically no point-to-point lines.) Ditto for anything old where the schematic was drawn by hand (some of these are works of art with heaps of lines!)
Learning to read bad schematics is also a really good skill, though. Especially in data sheets and app notes you often come across schematics that almost seem to intentionally obfuscate what the circuit is supposed to do! And the schematic in your post is certainly not “bad” at all by that standard! :)