Once I had a functioning prototype, the next step was to convert it into a schematic. After that, you have to convert the schematic into a PCB. Now we are at two layers of translation, and at this step I made a mistake: I wanted to use SMD components to save money, and I found that the BC8xx transistors are the SMD equivalent of the BC5xx ones, so I used the footprint of the BC8xx transistors in my PCB, with no errors from KiCad.
As it turns out, the BC8xx footprint is not compatible with a BC5xx schematic! The pinout is different: the base is pin 1 instead of pin 2, so the components in my PCB that use transistors (crucially, the voltage controlled amplifier) didn't work. Unlike a bug, that mistake cost me $200 and weeks of development time, but after 10+ years of writing software I'm still happy to be making things that people can touch.
Mine was assuming that the stripe on tantalum SMD capacitors was the negative side. First prototype board came back from the fab and pick and place department (we had it in house). Immediately caught fire when I powered it up :)
Second lesson, start with current limit on your bench supply, not throw 10A into it :)
Shoutout to OSHpark's prototype service. Something like 5 bucks an inch and you only have to toss out 3 if you find a fault.
Printing the board outline and layers combined as well. And checking you used the correct footprints against actual parts helps.
Breadboards make me wince a little especially in a professional setting but I've made my peace with dev boards that come with DIP-style pins for them. Decent breadboards are so cheap now that every dev board get to live on its own permanent breadboard.
I think this is a key point. One could imagine three layers:
(1) NETLIST: a list of text-only descriptions, like "R1 1 0 1k", or even a sentence description "connect a 1k resistor between node 1 and node 0"
(2) SCHEMATIC: a 2D drawing with canonical symbols, straight lines for wires, and labels/notes
(3) LAYOUT: a 3D (or multi-layer 2D) physical representation for PCB, or in this case breadboarding
All three layers are useful. (Obviously you need layout to make a PCB, and you need a netlist for simulation.)
But for most humans, where we have 2D visual representations baked in, if you're trying to understand or communicate what's going on:
- It's really really hard to keep track of a bunch of text sentences like a netlist and node numbers/names for all but the simplest circuits -- maybe 3-5 elements?
- It's really really hard to follow a 3D layout of PCB tracks that leads to pads, and then having to remember pin orders etc.
- It's easiest to follow a schematic diagram. It's browsable. It contains "idioms", as you say, about signal flow, logical block groupings, etc.: purpose and intent and functionality, in a way that netlists and physical layouts don't.
FYI, for medium-large digital circuits, I don't think this is true: probably just reading VHDL/Verilog, like reading source code, makes more sense. This is closer to the "netlist" level. I think that's because you'd name modules and inputs/outputs in a way similar to how you'd name functions and arguments in software, which doesn't really apply to "Resistor" or "Capacitor" as primitives.
But for a pretty big practical range of mixed-mode and analog things, I'd argue that schematics really are the easiest level for our brains.
(Disclosure: I'm one of the founders of CircuitLab https://www.circuitlab.com/ (YC W13) where we've been building an online circuit simulator & schematic editor for a long time. Although I'm mostly on the simulation engine / netlist side. My cofounder and other teammates have done most of the schematic GUI work.)
IMHO solderless breadboards still have their place for prototyping some slow circuits, ballpark maybe < 1 MHz signals, if you're aware of the extra capacitance and limitations. :)
I haven't done much HDL work so I don't have strong opinions there, but let's think about graphical representations source code and software intent for a moment. I like to see some block-level description of firmware even if it's just a few rectangles representing the main loop and each ISR other other process with text indicating what they do. I like to see statecharts. If someone has written an implicit flags-and-conditionals state machine, I'll draw the statechart and start probing for bugs and debugging from there. Tools like Scitools Understand are drastically underrated for figuring out other people's code, incidentally.
What kills me about the aforementioned style is that it eschews the schematic as a tool for thinking and implicitly sees schematic capture as a layer of friction you have to get through to get to layout. I suspect a lot of designs drawn that way were built up point-to-point on a breadboard and never sketched or even otherwise mentally visualized.
Maybe you can explain.
Are you saying in these cases often the physical PCB layout follows the geometry of the schematic?
Also usually totally implicit power routing. And no one that draws schematics that way has ever learned the value of drawing IC symbols to fit the circuit as opposed to the physical pinning of the device.