[Andrew Greenberg] has some specific ideas for how open-source hardware hackers could do a better job with their KiCad schematics.
In his work with students at Portland State University, [Andrew] finds his students both reading and creating KiCad schematics, and often these schematics leave a little to be desired.
To help improve the situation he’s compiling a checklist of things to be cognisant of when developing schematics in KiCad, particularly if those schematics are going to be read by others, as is the hope with open-source hardware projects.
In the video and in his checklist he runs us through some of the considerations, covering: visual design best practices; using schematic symbols rather than packages; nominating part values; specific types of circuit gotchas; Design for Test; Design for Fail; electric rule checks (ERC); manufacturer (MFR), part number (MPN), and datasheet annotations for Bill of Materials (BOM); and things to check at the end of a design iteration, including updating the date and version number.
(Side note: in the video he refers to the book The Visual Display of Quantitative Information which we have definitely added to our reading list.)
Have some best practices of your own you would like to see on the checklist? Feel free to add your suggestions!
If you’re interested in KiCad you might like to read about what’s new in version 9 and how to customize your KiCad shortcut keys for productivity.
we definitely could use a Strunk & White of schematics.
my small ask of the world is that when schematics are rendered into pdf, please provide a monochrome rendering fromthecadpackage* (which knows what are marks and what are background). dithered colors on a laser printer are unreadable; all the more so reduced from a B-size schematic to A-size paper.