You should concede this battle as “lost” before you even begin. Don’t stress over it, or bind your soul to the library you will eventually produce, because it will never truly satisfy more than a small minority of users.
In my view, the value of a microcontroller (uC) is all the built-in special-function units. With a uC I don’t need, for example, a separate UART, a stand-alone A/D converter, an I2C interface chip, a countdown timer, etc, etc. - they are already built into the uC. Since a pin could potentially perform so many different functions I find it difficult to identify the “primary” function. Unless, of course, you label it simply “PortA:4”, in which case you have emasculated that marvelous microcontroller into just some arithmetic processor.
I’ll go back to the concept that a schematic is (part of) how a designer communicates his design intent to a future reader. (The reader may, in fact, be the designer himself.) For sake of discussion, consider Microchip’s 10F220. It’s a 6-pin (!) microcontroller. Even so, except for the power pins, each pin has several possible functions. Here’s the symbol in KiCAD’s library:
That symbol is accurate and complete, but simply plunking it into a schematic will not efficiently communicate the designer’s intent for using this versatile uC in his project. At best, including all the possible pin functions clutters the documentation. At worst, somebody viewing the schematic can easily assume the wrong function for a pin. (Hopefully, there are other clues in the schematic that make it obvious how a pin is being used . . . or maybe he must read a separate “Design Description” document to figure it out.)
Here’s another version of the 10F220 symbol. The uC is being used to monitor a power rail, and alert an equipment user to anomalous conditions (overvoltage, undervoltage, ripple, etc) by how it illuminates a bi-color LED.
This symbol adheres to the gentleman’s agreement that inputs are on the left; outputs on the right. Pin 5 is an analog input; pins 3 and 4 are logic outputs . . . and all labeled accordingly. Including the pins’ other possible functions in the symbol would add only clutter and confusion. It is irrelevant that these pins could have other functions - in this particular design, the symbol makes their usage clear. One glance at the schematic and the firmware programmer can start to configure ports and initialize special-function units.
OK, that is a rather degenerate case. Even for this very simple uC, there is no way the person drafting the generic KiCAD symbol could have known how the device would be used in this design. Labeling each pin with its “primary” function would certainly miss the usage here; including ALL of a pin’s functions fails to tell an observer how they will be used.
In my view, @bobc is faced with a nearly impossible, thankless task. I’d suggest including all of the possible functions, and adding a note advising the designer to draft a custom, smaller, symbol containing only the functions actually used.
As for how to split and organize the library contents . . . . I’d consider doing it by pin-count. That’s often my first-cut method for selecting a microcontroller. I think, “Of course, there’s power and ground and Reset and oscillator, and I need so-many pins for the keypad matrix, plus so-many for the sensor inputs, plus 4 for the serial bus, plus so-many for panel indicators, plus . . . . hmmmm . . . . looks like this project needs a microcontroller with at least so-many pins.”
Dale
