Various random stuff

The current MCU_ST_STM32.lib is a great set of symbols generated from data provided by ST. However, there seem to be practical issues, which is that the symbols are very large. This is partly because MCU pins have alternate functions shown and modern MCUs have a lot of alternates, but also because some of the package have a lot of pins, up to 240 for some high end variants.

Therefore I would like to rework the library to make the symbols a more manageable size, by only listing the primary function for each pin, and creating multiple units where the number of pins reaches some limit (I am working to max of 96). Additionally, power pins and special function pins are placed in a separate unit.

I have added several new parts from ST, and now the library is too big! There over 1000 parts, I think we need to think of some way to split the library up into smaller chunks. Any suggestions?

The following screenshots show some typical small and large packages for current library, and equivalent symbols after rework.

I’d like to hear your feedback.

3 Likes

I vote for keep primary (GPIO) and alternate functions excluding these with pin remaping (which may confuse some people). If you keep only GPIO: PA0, PA1 these symbols will be readable only by STM32 exerienced users. Many times I look for the alternate functions of MCU before choose it for the design.

Yes. Split by family: Cortex M0, M0+, M3, L0, L3, M4, etc. Just like I do for Microchip PIC MCU’s.

2 Likes

That’s what the datasheet is for.

The schematic symbol is there to work in a schematic not there to give advice for what you should buy.

1 Like

Sorry. I treat libraries as another - very compact - device catalogue. There is a ton of datasheets on vendors sites. Who likes to waste their time to browse and open many of them? I have a library where I can see at a glance which devices I should consider…

Think about libraries - especially symbol libraries - in a wider spectrum, not only as graphical representations.

I could argue either side of this topic. Which one do you want me to take? :wink:

Seriously, I see the advantage of breaking them up into logical units. Unit size? Why not leave them as is and let the user decide what to toss out and what to keep and then resize accordingly? The problem is that even if you run a poll you won’t get enough of the installed user base that actually cares about the topic to ever even see it.

The focus should be on readability. Sure a monolithic block of schematic part is the simplest form, but when it gets to that size, it is no longer a simple part. Breaking it up into a few key blocks is sensible and improves the viewer experience. Are there guidelines elsewhere regarding size and readability of schematic components?

I would tend to break a part into, power, GPIO, JTAG/SWD and then maybe specialised ports such as USB, etc. This is entirely dependant on the part itself.

EDIT: Isn’t this really just asking for some further clarification on how to manage large ICs and uCs with respect to the KLC? Perhaps the librarians might have some more general tips rather than just for the STM uCs

I would like it to be split by GPIO ports. STM has up to 16 pins per port. I would add alternate functions only if pin had one or two, but for instance STM32F43 has up to 9. Also JTAG is usable as GPIO and part of normal port so I think it should be together with other port pins. I would create one unit with power and special purpose pins that have no other purpose as BOOT etc.

We at the official lib already decided what path to take. See the nxp arm cpu libs. (@hackscribble cleaned that one up.)

Breaking them up into multi unit parts might really be a good idea for m3 and m4 mcu symbols. m0 symbols might be small enough for a single unit symbol.

This complicates things. I don’t think all jtag pins are part of the same port for them.
Example the STM32-F405RGT6 has jtag split between port A and B

2 Likes

This gets my vote.

I also agree with this but sometimes how a chip gets divided into units depends on which functions are used. Not a problem that can be solved generically so I think this would be a good starting point and users can then create their own symbols using these as a starting point.

They could be split either by processor family as @keruseykaryu suggested or by part name as ST does on their website (STM8, STM32, SPC56), perhaps the latter isn’t granular enough.

Just my $0.02, I don’t really have a preference.

3 Likes

The symbols in the libraries are just graphical representations. I think @bobc suggests a good starting point, of course it won’t suit everyone’s use case nor is it practical to try. In my opinion it is naive to think the libraries can be used in place of datasheets when choosing a part.

1 Like

I think you just brought tears to the librarians eyes and I don’t think it’s joy. :wink:

2 Likes

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

4 Likes

I suspect that @bobc knew that he will get all the workflows/use cases. So I’ll drop my own.

All of the above points from previous posters are valid we just have a different take on it.

I used to have the symbols where pin names included each and every possible function. but lately with pin multiplexes going in double digit values I only keep the port name (e.g. GPIOA1). In order to communicate my intent (as I think this is a very smart thing to do) I label the net coming out of the pin (PWM, SCI_TX, …). Sometimes I even add multiplexer configuration (e.g. PWM:MUX=15). Why? Because when doing the schematics, you have to look at the datasheet of the device and while I am at it I also look at the multiplexer table and I write down the setting. This way I don’t have to go through the datasheet once more when writing the firmware.

Those paying attention figured out that I mostly deal with one man band projects, so those in bigger teams have a different take on it.

So I would only put the port name in the symbol. And if symbol needs to be split across units I would split them first across functionality: supply, internal use (reset, xtal, internal ldo/switcher, dedicated debug port (JTAG, …), dedicated boot pins, analog, digital). I would keep the analog supply pins with analog unit. If any of the internal use functions is multiplexed with digital pins (boot pins, jtag, xtal) I would keep the primary functionality (digital GPIO) and leave it up to the designer to produce a schematics that makes this clear. You will never be able to untangle the mess that manufacturer created.

3 Likes

I think this depends a lot on the MCU in question. The chips that are the starting point for this thread are pretty crazy with very large number of alternate pin names.

But once one get into chips with peripheral pin select, it looks much more reasonable as the the listing in the manufacturers data sheet is shorter and is a good starting point for the planning when laying out things. For instance a number of higher pin count PIC24, dsPIC33 and PIC32 MCUs have this feature. It would be a great loss if only the port name was shown; the RP/ RPI numbers are absolutely essential for the planning and when writing the firmware. What I do to make the actually used function clear is to label every pin I use on the MCU with a net name; thereby I know what the pin is used for. [In the example below I also temporarily use a text label to easily spot which pins are RP (capable of input and output), as for instance a peripheral port like MOSI cannot be used on an RPI (input only) pin, and the RP pins are limited in numbers.]

1 Like

This is part of the specification for the new file format. So it will first need a working implantation of the new file format.

Actually that is a very elegant solution. Hopefully it is easy to implement because otherwise I wouldn’t want to see a lot of development time going to it instead of a few other things people seem to think would be a higher priority. Like I’ve pointed out though, libraries do seem to be the honeypot of EEcad solutions when it comes to the new users that are the life blood to open source projects.

The multi-use pins are a pain. My thought was to split into functional parts. For example, a part for SPI0 or SPI1, etc… I never got around to see if a pin can appear in different parts. Can a pin be in two parts of a chip?

Yes plenty. For instance in the DSPIC33EP512MU810 in my example above there are hardly any peripheral that has a fixed location. Almost all can be moved to whatever RP/RPI pins are desired. In addition a very large number of Microchip MCUs that do not have peripheral pin select have alternate locations on different ports of for instance UART1, programming pins etc.

Here is a screenshot of the DSPIC33EP512MU810 symbol I made with pin names fully following the data sheet; a lot simpler than the ones in the start of this thread thanks to the peripheral pin select feature (symbol can be shared in due time once the KiCad libraries stabilize and I can figure out the git procedure for upload…).

Thanks for your comments everyone.

Ideally the user would be able to customise symbols by selecting pin function from a drop down etc. I would also like to be able to drag and drop pins from one unit to another, to create my own groupings. And for really blue sky stuff, a method to call a “pin configuration wizard” script, which allow the user to configure the MCU pins and understands any constraints.

But all that is future stuff. For now, it seems to be librarians’ policy to list pin primary functions only. It would be really useful for contributors if that sort of policy decision was written into the KLC, rather than discovering it by accident.

There doesn’t seem to be much consensus on splitting the larger packages into multiple units, or how the pins should be allocated to units, so I will start with splitting the parts by family, and primary functions only. I think the current port layout is odd (clockwise from top right??) but for packages <=100 pins I will leave the current layout, so that there is some compatibility with existing symbols.

There are 11 families identified by ST, which gives a manageable number of parts in each library

Number of devices : 711
Family, # devices
STM32F0 88
STM32F1 58
STM32F2 16
STM32F3 50
STM32F4 115
STM32F7 80
STM32H7 16
STM32L0 92
STM32L1 87
STM32L4 83
STM32L4+ 26

3 Likes

You are right about that. But remember the KLC is written mainly written by @SchrodingersGat alone with a bit of support by us other lib maintainers. And while we work on the KLC we still need to do the other tasks required by us maintainers. (=check contributions)

The earliest we can do another larger rework of the lib to include such things is after our lib transfer for the v5 release is done.

2 Likes