1. 11

  2. 3

    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.

    1. 6

      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”.


      1. 1

        Maybe Flow-based, Distributed Programming on a Heterogenous Network-on-a-Chip of probabilistic, limited-precision CPU’s and custom ASIC’s. ;)

      2. 3

        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.

        1. 1

          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.

          1. 1

            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?

            1. 2

              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.

              1. 1

                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.

                • By convention, try to orient pins so that power (VCC, etc) points up and ground points down. This convention gets broken a lot, usually when there isn’t enough space. But you have plenty of spare space to move things around on this schematic.
                • When there are a lot of wires criss-crossing, use labels to make the connections instead. I’m looking in particular at the outputs coming from PB0..PB5 on the ATTiny. If this was programming, it’s the equivalent of naming unrelated variables “a0, a1, a2, a3” - you can’t see at a glance what any particular thing is for. Giving these “nets” names like “SW1”, “SW2”, “LED1”, “BREAK1”, “BREAK2”, etc. and then using the net name labels rather than wires to make their connections both makes it quicker to see what joins to what, and makes it easier to see what function that connection has. And when you’re asking yourself questions like “which GPIO is the LED, again?”, you can see that very quickly.
                • Even when you are doing point-to-point wires, labelling nets is a good habit to communicate the meaning of signals where you can.
                • Using labels can make it easier to keep VCC at the top and ground at the bottom. For example, if you use net labels to connect the switches & LED to the MCU then you can rearrange these parts so ground is at the bottom. This intuitively shows how the switches “pull down” to ground when closed.
                • As a rule of thumb, a lot of schematic authors try to avoid having places where two lines cross at right angles. This is because when the schematic is printed out it can be hard to see if there’s a little circle on the join or not. It’s a bit of an old fashioned “rule” but I find it’s useful, and usually when I rearrange a schematic to do this (by labelling & moving things or staggering four-way connections) I end up with a more readable schematic at the end.
                • Lay out the schematic to group things together logically, then label the groups. In this case the jumpers, breakouts, and mounting holes are all things that can be moved around and logically grouped together in the schematic, with a label for the group explaining what they are and maybe even a dividing set of lines drawn around it if necessary. Again, using labels for net names will give you the freedom to do this without having to worry about where the lines go.

                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! :)