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.