I had an intern do something similar with an electromechanical machine. I'd all but written the equations out for him but he found drawing it out in Simulink in the most fundamental, primitive blocks to help him understand what was going on . I don't get it either.

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.

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

Also, part of the style seems to be to contort any actual schematic to fit in the box. I like to ask "if you wouldn't put it on its own page so you could draw it clearly, why did you draw a box around it?".

I don't really get this point of view. Take an I2C bus, for example. Isn't it easier to read the schematic if all the components on the bus have two pins connected to wires labeled 'SDA' and 'SCL'?

Sometimes, and it depends what you're trying to convey.

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.

Is it? You can just count the number of devices connected to the I2C bus. That seems easier than if you had to follow a bunch of tangled lines.

> You can just count the number of devices connected to the I2C bus

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.

>If everyone working on it has the software, they can count easily and accurately.

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.

> It might be slightly tedious with a paper schematic, but it's hardly impossible.

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.

I am not really understanding the "at a glance" part. If there are no labels then you have to follow the wires. That seems more difficult, not easier.

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.

If the complexity of the attached subsystem is low enough, the wires can be used as a feature not a bug, like a map.

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.

Yeah, there’s a balance here. There are common nets like SDA, SCL, GND, VCC that make sense to have as global nets. And then there’s actual circuits where it makes more sense (for understandability) to not do it like that.

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…)

I guess I would see a schematic like this in the context of an EDA tool which would make most of these issues moot. E.g. it is easy to find out what other nodes a specific node connects to. If for some reason you have to work from a paper or PDF schematic then I can see why these things would matter - but hopefully you don’t!

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.

100% I am working with paper schematics. I do a fair bit of field work in dirty environments (agriculture). When something isn’t working I want to be able to trace from the power input to the fuses to the regulators to the control signals to the output connectors. It’s much much easier when that all fits on a sheet of paper or two (or a screen or two) and it clearly flows from left to right.

Ok, fair enough, but you don't have to use a paper schematic for the LilyPad-MP3 thing. The Eagle sch file is here: https://github.com/sparkfun/LilyPad_MP3_Player/blob/master/h... It seems fine to me for schematics to adapt to new media. We don't worry about how easy it is to navigate our source code when it's printed on a teletype.

That's fine if you're the only person that will ever use the schematic. As the kids say, "you do you". But a schematic for a product has a life beyond your desk - it will be used by technicians, test engineers, firmware engineers, sustaining engineers, purchasing, quality, manufacturing (including fab houses and CMs), legal, compliance, the list goes on. Many of those people will not have a schematic capture tool installed on their computer and limited time to learn one - or in some cases, several. You will absolutely have to provide them PDF schematics and you should care if they are clear and follow common conventions. If you're thinking of a schematic as source code, maybe as data entry for layout, you're already making a category error. They are different in kind.

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.

To me it seems like a process failure if people are reading paper (or PDF) schematics in 2024. EDA in general seems to be behind the times compared to software engineering in terms of tooling culture. If you saw a software engineering process that involved people reading print outs of source code you’d just say: “That’s insane! Stop doing that.” You wouldn’t bother to critique the formatting of the print outs.

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

A schematic is a drawing, not source code. Of course you're going to want to print it out and mark up the paper. You're making a severe category error. There is a visual language for communicating design intent in schematics that is not just formatting, or making things pretty (you can make a "pretty" but unclear schematic) or entering wiring connections into a computer. If you follow it, other engineers will be able to understand your work more quickly and with fewer questions for you. If you don't care, you will look like someone who doesn't care. It is the difference, say, between writing individual words or short declarative sentences as opposed to building complex sentences, paragraphs, a short report, etc.

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.

Of course a schematic is a drawing, but there is particular need these days for it to be a non-interactive drawing laid out for printing on a sheet of paper. Equally, source code is text, but that doesn’t mean that in 2024 we have to worry about how well suited our source code is for printing on a teletype. I am not saying that no care should be taken when creating schematics, only that the conventions that made sense when schematics were static printed documents will not necessarily make sense now that a schematic is created, viewed and manipulated via an EDA tool. In a similar way, version control, interactive editors and IDE tooling have given rise to rather different coding conventions than the ones that predominated when people entered numbered lines of BASIC, or assembled machine code by hand on sheets of paper.

A move to open EDA formats is indeed long overdue. KiCad is a step in the right direction.

All good points. By the way, yes, if you have one peripheral device on an i2c bus, and your design is small enough that you're drawing the device on the same page as your microcontroller, you should make the connection explicit. My two cents:

- 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 am starting to warm to the idea of drawing a power tree for even pretty simple power schemes like this one

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.

The other technique that comes in handy in that kind of situation, if you have multiple power/voltage/current domains that require spacing or other isolation from each other, or multiple ground references, is an isolation or insulation diagram. I don't have a great example; if you search you'll find a style that will meet medical device requirements and can be adapted for other use.

I think using the drawing it out process to understand initially is ... not how my brain would do it, but seems like a perfectly valid approach.

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.

One cool thing about, for instance, density altitude calculations or runway length calculations, is that you can break the parts of the algorithm down graphically do pilots can trace through datapoints to get an answer without even having a calculator. See many pilot operating handbooks for examples.

Also works for power/moment data on marine freight, in fact I used to have a job at a shipyard drawing those.

Where can I read about your project or hear your tangent?

I'm hoping at a minimum get my thoughts written out while I'm flying this weekend!

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

This is all making me think... this could be a good use case for propagators: https://dthompson.us/posts/functional-reactive-user-interfac...

Yeah, definitely inspiration coming out of the FRP world as well here. Great link, thanks!

it sounds like the ideal solution would be something functional (so you have a computation graph), pure (so you can cache results) and lazy (so order of expressions doesn't matter.) why not Haskell? or even a pure/lazy subset/variant of Julia, if you want to ditch the baggage of Haskell's type bondage?

you could ditch explicit cells entirely, and implement your "scope" by selecting a (sub)expression and spying on the inputs/outputs.

I've thought about that and have written some fun Haskell code in the past but... the other goal is to actually have users :D. I've also considered Lisp, Scheme, and friends to have really easily parseable ASTs.

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!

Elixir livebook does this

Interesting! I do love Elixir! Thanks for the recommendation, I'll take a look!