What I've seen many times though in my career that awkwardly spans EE and CS is that people forget that you can still... write equations instead of doing everything in Simulink. As an example I was looking at a simplified model of an aircraft a couple months ago.
One of the things it needed to compute was the density of air at a given altitude. This is a somewhat complicated equation that is a function of altitude, temperature (which can be modelled as a function of altitude), and some other stuff. These are, despite being a bit complicated, straightforward equations. The person who had made this model didn't write the equations, though, they instead made a Simulink sub-model for it with a bunch of addition, multiplication, and division blocks in a ratsnest.
I think the Simulink approach should be used when it brings clarity to the problem, and should be abandoned when it obscures the problem. In this case it took a ton of mental energy to reassemble all of the blocks back into a simple closed-form equation and then further re-arranging to verify that it matched the textbook equation.
A related phenomenon seems to be people who don't want to "wire up" schematics but attach named nets to every component and then draw boxes around them.
Lol there are a few things that I am highly intolerant of and this is one of them. The only place where I'm generally ok with that approach is at the input connectors, the microcontroller, and the output connectors. Same philosophy as I said before though: "if it brings clarity draw it as a wired up schematic; if it turns into a ratsnest use net labels to jump somewhere else". Having every component in a separate box with net labels will generally obscure what's going on and just turns it into an easter egg hunt.
Here’s an example that I think takes it too far: https://cdn.sparkfun.com/datasheets/Dev/LilyPad/LilyPad-MP3-...
- The audio jack (line level) could have just sat to the right of the codec and been directly connected to it to make it clear that it’s just a direct output
- the speaker amplifier could be directly connected to the audio jack as well. I spent a lot of time looking around to figure out where it actually connects to; I figured it would have its input connected to the MP3 codec and didn’t realize that it would be connected through the micro switches inside the headphone jack (which makes sense now that I see it)
- the SD card slot could either be connected directly to the codec or could have better names on the nets. When I see MOSI, MISO, and SCK I assume that they’re connected to the main MCU. Even more confusing, there’s an SD-CS that is connected to the MCU but not the rest of the SPI pins
Overall I’d probably give this one a B. It’s by no means the most egregious I’ve seen but it also obscures the signal flow pretty badly.
Other things I would probably consider doing:
- better clustering of pins on the MCU by function. The switch inputs and LED outputs that connect to the rotary encoder are all over the place. Most tools allow you to move the pins on microcontrollers around at will
- the FTDI block could move onto the first page. The DTR pin could use a bit of explanation that it’s tied to the reset circuit. Not their fault in this one but the naming inconsistency between FTDI-RXI and TRIG4/TXO is confusing until you figure out that the pin is meant to be either a GPIO or a UART pin. The name doesn’t make it clear that it goes to the FTDI chip because it’s inconsistent with the rest of the FTDI-xxx names but that’s because most ECAD programs handle net names poorly anyway
Edit: one more thing that really bugs me about this schematic: the Vbatt net leaving J1. It’s labelled but not with any kind of flag or loose/unterminated line that would indicate that it’s connected to the net leaving U2. And further with that, the fact that VIN on U2 comes only from the FTDI connector on the second page (I think…)
- Making the power routing completely implicit is another hallmark of the style and it drives me crazy too. The power, charging, and maybe FTDI boxes should all be together on one page. Now, I might change my mind about this in six months, but I am starting to warm to the idea of drawing a power tree for even pretty simple power schemes like this one. The power tree style in the Arduino documentation is pretty nice
- In the same vein, even modest designs usually benefit from a block diagram up front. You don't need to use hierarchical design functions - just boxes and arrows and text done with the drawing tools of the CAD program
- I like that they actually did put most of the "bookkeeping" connections on the left side of the micro. I'd move the UART pins over to that side too, and the programming port. The programming port belongs with the micro and nowhere else, would you put it on its own page?
- Audio signals flow right to left to down for no particularly good reason except to get all the other boxes to fit on the second page. All the audio could be on its own page
- Similarly, LED signals come in to the rotary encoder on the right and encoder signals come out on the left. Really?
- I like that they grouped the bypass capacitors with the ICs but for these modest numbers of bypass caps I prefer to see them shown connected to the pin pairs they'll be placed by
- OK, not a schematic point and not critical for a hobbyist product but powering the battery charger from USB is a potential issue. Low line by spec on USB is 4V at the connector, and you won't get 4.2V out of that with a linear charge controller. They might also be exceeding maximum effective capacitance on the USB power bus. Again, not critical for a low-volume "maker" product - it will always work except when it doesn't
- No off-page connectors for off-page connections. I like to see the pages called out that an off-page connector connects to, but I admit that's a pain to do by hand
- The pull-ups and pull-downs in the top right hand corner of the second page are typical of the style. Who ever heard of connecting these directly to the pin that needs them? Again, it looks like this was done to fit the subcircuit in the box
I'm laughing/crying right now because of a board I had to deal with last week at $JOB. Pretty beefy power distribution board with some... quirks related to load shedding etc. Details don't matter there. I ended up drawing the whole power graph (it's not a tree, there are two independent inputs that go through ideal diode controllers for some of the rails for redundancy). By carefully rearranging the nodes of the graph I managed to get it completely planar (no overlapping edges) except for one spot where a poorly-thought-out connector did require one edge overlap.
Laying that out as a planar graph dramatically simplified routing. It's a technique I hadn't explicitly used before and it sure worked out nicely.
I’m not a very visual thinker, though. If it were up to me schematics would just be written out in some kind of textual representation, but EDA tooling tends to make fiddling around with schematic diagrams the blessed path.
There are in fact ways that electronic media have changed schematic practice - it is extremely unlikely in 2024 that you will have a draftsman or CAD designer drawing your schematic from a sketch, though in some environments you might have a documentation team putting your work into a very strictly defined format, and it is pretty unlikely you will have a large-format plotter readily available. So the norm has shifted to multiple smaller pages, and there's little pain involved in adding another schematic page if you need one for clarity.
Note that sparkfun schematic was drawn for 8.5x11 paper even though the more natural size for full-size monitors is 11x17.
> Note that sparkfun schematic was drawn for 8.5x11 paper even though the more natural size for full-size monitors is 11x17.
Again a cultural issue. The tools assume by default that you want to produce a sheet of paper.
As documentation, in a production environment, your schematic will have a life beyond your EDA package. I've done sustaining work on designs that have outlasted the design packages they were done with. Without having to open them up, because there were schematics available in standard documentation formats. Eagle - as used in that lilypad design from 2013 - already has a sunset date. It's also a reality that EDA packages have poor backwards compatibility and even worse, their "import" functions rarely work at all well on non-trivial designs. That would be a fair criticism of the industry but for the most part redrawing a schematic and checking it against a netlist is not the end of the world. If you have one.
As an aside, it wouldn't shock me if lawyers print out source code, either. They print out everything else and store it on paper.
A move to open EDA formats is indeed long overdue. KiCad is a step in the right direction.
Take a system with multiple I2C devices - with each device on a different sheet, it becomes difficult to tell that you might have bus contention issues.
If everyone working on it has the software, they can count easily and accurately.
When I started and still sometimes today "just counting the number of devices" requires visiting each sheet of the schematic, then hoping you didn't miss one.
> That seems easier than if you had to follow a bunch of tangled lines.
Today's software will let you draw a single bus connection between all bus devices.
> That seems easier than if you had to follow a bunch of tangled lines.
The problem is generally that if you choose to put some things near each other, you're choosing to put other things further away. In many cases the I2C bus itself has little to do with what the I2C devices do, so by drawing a single I2C bus or pair connecting all the devices with splitting them up with a named bet, you're choosing to make those other things harder to show. This may or may not be appropriate for the design.
Any IC on the I2C bus will have pins labeled SCL and SDA, so you can easily just go through all the ICs and count how many have those pins. It might be slightly tedious with a paper schematic, but it's hardly impossible. It still strikes me as easier than doing the same thing with unlabeled pins that are connected directly in the schematic to the UC's I2C pins.
>In many cases the I2C bus itself has little to do with what the I2C devices do, so by drawing a single I2C bus or pair connecting all the devices with splitting them up with a named bet, you're choosing to make those other things harder to show.
I don't quite understand what you're saying here. Labelling a pin with SDA or SCL makes it clear that it's connected to the I2C bus. What I'm saying is that I don't see any value in drawing a line connecting the pin to all the other SDA/SCL lines. That's completely independent of how you lay the schematic out or split it into functional blocks.
What may only be slightly tedious for you will often be error-prone for someone else.
>I don't see any value in drawing a line connecting the pin to all the other SDA/SCL lines.
The value is that the entire bus is visible at a glance. All conflicts are visible, and contention sources understandable. Though, you can also put this information in a note/table.
>That's completely independent of how you lay the schematic out or split it into functional blocks.
What I mean is that it's often also valuable to split a schematic out along functions rather than busses. If you have an I2C ADC with a bunch of analog stuff connected to it, that might fit its own sheet better. But if your weather station I2C bus has several simple devices like Flash, ALS, humidity sensor, RTC, barometer, and thermometer, placing them together on one sheet may make sense. I just mean tidyness varies with the contents of the room.
You can split out all the components on the I2C bus onto a separate sheet (or not) regardless of whether you label or SDA and SCL lines or connect them with wires.
Imagine a home network diagram with a router, switches, and computers. You could draw each on their own sheet with names for each cable, but the purpose of each cable is clear from what it connects.
But once you -do- understand it's time to stick that in a reference file out of the way and write it again properly for actual use.
The quick gist is that Jupyter is frustrating for me because it's so easy to end up in a situation where you inadvertently end up with a cell higher up in your document that is using a value computed in a cell further down. It's all just one global namespace.
In the Julia world with Pluto they get around this by restricting what can go into cells a little bit (e.g. you have to do some gymnastics if you're going to try to assign more than one variable in a single cell); by doing it this way they can do much better dependency analysis and determine a valid ordering of your cells. It's just fine to move a bunch of calculation code to the end/appendix of your document and use the values higher up.
The idea I've been chewing on comes somewhat from using Obsidian and their whole infinite canvas idea. It seems like using ideas from Pluto around dependency analysis and being able to also determine whether the contents of a given cell are pure or not (i.e. whether they do IO or other syscalls, or will provide outputs that are solely a function of their inputs) should be able to make it easier to do something... notebook-like that benefits from cached computations while also having arbitrary computation graphs and kind of an infinite canvas of data analysis. Thinking like a circuit simulator, it should be possible to connect a "scope" onto the lines between cells to easily make plots on the fly to visualize what's happening.
Anyway, that's the quick brain dump. It's not well-formed at all yet. And honestly I would be delighted if someone reads this and steals the idea and builds it themselves so that I can just an off-the-shelf tool that doesn't frustrate me as much as Jupyter does :)
you could ditch explicit cells entirely, and implement your "scope" by selecting a (sub)expression and spying on the inputs/outputs.
I jest a bit, but there's a very rich ecosystem of really useful data analysis libraries with Python that do somewhat exist in other ecosystems (R, Julia, etc) but aren't nearly as... I would use the word polish, but a lot of the Python libraries have sharp edges as well. Well trodden might be a better word. My experience with doing heavy data analysis with Python and Julia is that both of them are often going to require some Googling to understand a weird pattern to accomplish something effectively but there's a much higher probability that you're going to find the answer quickly with Python.
I also don't really want to reinvent the universe on the first go.
It has occurred to me that it might be possible to do this in a style similar to org-mode though where it actually doesn't care what the underlying language is and you could just weave a bunch of languages together. Rust code interfacing with some hardware, C++ doing the Kalman filter, Python (via geopandas) doing geospatial computation, and R (via ggplot2) rendering the output. There's a data marshalling issue there of course, which I've also not spent too many cycles thinking about yet :)
Edit: I did copy and paste your comment into my notebook for chewing on while I'm travelling this weekend. Thanks for riffing with me!