HI Bill. I loved the old transistor radio schematic (being British by extraction I still prefer Circuit Diagram even though it takes longer to say and write). Obviously from a coil manufacturer trying to sell his wares (note the list of trnasistor types you can use at the bottom!)
I think the nice thing about diagrams like this is that you have the power rails running along the top and the bottom and it's obvious what they are. Looking at the EDN one, one IC is supplying the other two ICs but It takes a bit of examination to find this.
The worst as you say are MCU diagrams where the tendency seems to be to put ICs in isolation with a funny shaped box on each pin with a cryptic signal name in each. Somewhere on the rest of the diagram is another box, going into another IC, with the same signal name. Look, Ma, no wires! :-) But to be fair some of those circuits would be very difficult to draw without looking like spaghetti.
I recently had to trace the circuit of a drill charger from its PCB. I ended up with a real rats nest on a piece of paper. I managed to draw it properly with only 2 crossovers. It made it obvious how the circuit worked. and I found the tidying-up process very satisfying.
Schematic styles are always an interesting thing to observe. Do you try and fit it all on 1 page or spread it among several pages where signal flow is not as easy to follow? Do you keep it architecturally flat or use the logical, but hard to follow, hierarchical design? Do you place critical components like decoupling capacitors near their respective integrated circuits, or show them all in a common area connected to supply rail? Do you make it clean looking by using wire stubs with node names for virtual connections, or make it easier to follow by showing complete lines of connectivity? Do you use descriptive net names to aid in understanding, communicating, and documenting degugging efforts? Do you include net name locators for on-sheet of off-sheet connections, or leave the user to search the schemtic to find them? How do you deal with multiple grounds?
One general observation I have made over the years is the folks responsible for implementing and debugging systems have a drastically different approach from folks whose primary design responsibility is ASICs or FPGAs.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...