Schematic component creation: handling pin naming with lots of aux functions

[AlfBaz]

I'm creating a new component for an MCU and was tempted to simply name the pins as PA1, PA2 etc. However this hides information in the schematic as to the actual pin function.

By the same token naming the pin with all the available alternate functions also hides the pins true purpose, plus the symbol then has to be very wide to accommodate the long pin  names.

I was considering the PXY format and then placing the pins actual function as a net name on the exiting wire but this feels a bit convoluted also.

I've also tried messing around with adding parameters but have yet to come across a method that doesn't involve doubling the pin spacing between pins

What do you guys do? Do I just bite the bullet and name the pin with all the functions or is there another way?

[Rerouter]

So far the most complex thing i have played with is an atmel sam3xe, on that, the datasheet gave short names for most of the functions, e.g. PA2/CANTX0/TX0/ADC9, arguably I only faced a 4 deep tree at most, but i made my symbol list everything as i will likely use the same chip down the line,

If i recall from the altium promotional videos they have a way to dynamically reassign pin mappings built in somewhere,

[AlfBaz]

So far the most complex thing i have played with is an atmel sam3xe, on that, the datasheet gave short names for most of the functions, e.g. PA2/CANTX0/TX0/ADC9, arguably I only faced a 4 deep tree at most, but i made my symbol list everything as i will likely use the same chip down the line,

This is pretty much what I have done until now and it hasn't been that bad, but...
STM32F429 the pin with the most
TIM3_CH2, I2C1_SMBA, SPI1_MOSI, SPI3_MOSI/I2S3_SD, CAN2_RX, OTG_HS_ULPI_D7, ETH_PPS_OUT, FMC_SDCKE1, DCMI_D10, EVENTOUT
I'm gonna need a 50" monitor just to see the mcu! Not to mention the pin naming clutter on the pcb screen

If i recall from the altium promotional videos they have a way to dynamically reassign pin mappings built in somewhere,

It's been a while but I used this functionality in the past when routing out an FPGA to DDR and a host of other stuff. The pin names stay the same but you assign swap data to them so when you are routing you can re-arrange the functionality of the pins so they route nicer. If I remember correctly the pin swapping at PCB level propagated all the way back to the VHDL code... very nice but unfortunately not a solution for this pin naming problem

[AlfBaz]

I've recently been stung by a bad work practice of mine on the software development side. One library linked to many projects. Changes to my lib over time caused me lot of wasted time when I revisited an old project. This bad habit probably stems from the "old days" of limited disk space. I now have in a project directory a copy of the complete library for each project.

Perhaps I should move to doing the same with my PCB projects. Create INTLIB from pcb and modify the components to suit. I can store all the auxiliary function names in a parameter in the original library and when I have a new project, copy the function name I need to the pin name to save looking up the data sheet and save that to the project specific library

[ajb]

There's the description text for each pin, but I don't think that's really visible anywhere in the software other than in the pin properties.  Would be nice if that showed up in the tooltip when you hover over a pin in SchDoc, but that doesn't seem to happen.

With something like an AVR that has at most 4-5 easily abbreviated functions on each pin, I might include those in the pin name.  For anything more complex, like any sort of ARM, I just use the pin name ("PA1") except for special system functions that get used in almost all designs: Reset, SWD, XTAL, that sort of thing--eg, "PA14/SWCLK".  Trying to reflect all of the functionality on any pin on a typical ARM in its label is never going to end well.

On the symbol for an STM32F334 I just made this morning I tried something a little different.  The pin names that have special functions just have a slash after them ("PF0/") and then below that I have a text object with the alt function name.  This keeps labels from running into each other, particularly when doing a symbol that reflects the physical layout of the chip.

As far as allocating the pins and peripherals in a project, I have a pin planner spreadsheet I use that does a crap load of conditional formatting to make it easy to see which peripherals are available on each pin and which ones have already been used.  That, plus a symbol that reflects the physical layout of the pins (see attachment) make it relatively easy (if tedious) to get a nicely optimized pin layout.  The spreadsheet is kinda clunky and a bit fragile, so I've been meaning to come up with something better--unfortunately I have very little desktop programming experience, so that's not exactly gonna be done tomorrow.

[AndyC_772]

I've struggled with this question too.

More than anything else, I feel that a library shape should be consistent and applicable to all designs that use that part. So, the worst possible thing you can do is create a part which shows only the specific usage of each pin in the first design that part was used on. Do this and you end up recreating the part's symbol each and every time you use it in a new design.

With PICs I tend to include every possible feature on each pin, which does result in a complex but re-usable symbol.

Then I started using ARM processors, and it all got a bit much. A hundred or more pins with half a dozen features per pin? No thanks. I name the pins PA0, PA1 and so on, and just accept that the symbol doesn't show all the detail.

I am, however, a strong believer in comments on a schematic. There's no reason at all why you shouldn't create a symbol which is generic, but then add a text label to each pin to show its usage if you need to.

In many cases, it may be obvious or unimportant. If, say, you have an SPI EEPROM connected to some CPU pins, they might be configured as GPIO or they might be a dedicated hardware SPI interface. From the schematic point of view, it really doesn't matter.

Perhaps, though, you have a digital input which is actually used to gate a timer, or to cause an event which triggers an AD conversion. Then it might make sense to label that this is how the pin is configured, because it's providing useful additional information about how the design works.

Bottom line: describe everything that's non-obvious. But not everything that's obvious.

[T3sl4co1l]

I pick the top three names/functions for a pin.

Common, annoying spam like PCINTxx doesn't add any info; you're better off noting which pins DON'T have pin change interrupts!

Also if they're all configurable (most MCUs don't do this, but FPGAs obviously do, except for some specialty built-in hardware), then who cares, GPIO is GPIO.  Even if the configurations are somewhat limited, chances are the permutations are too complex to relate by mere pin names.

If you have a subscription, it's very easy to locate the part (most of 'em are in there) and download the SchLib.  It's at least a good starting point, and yes, you probably want to trim down the stupendously long pin names first.

If you're using them for specific functions, you can always rename them once the part has been placed on the schematic.  Open the part properties dialog and press the button for pins.  Pins can be edited in name, number and property here.  (You can also unlock pins and drag them around freely... if you dare.)  Make sure not to update from library.

There are also "alternate" part views, but you'd probably just use that as a means of library-ifying such changes, since there are innumerable combinations you might use in practice.

Tim

[Philfreeze]

We usually have one symbol where we only show the generic name  (p + Port name + number; eg. PA0) and very often used functions which only this pin can handle (like reset, clock, on smaller mcus i2c or spi etc.)
Then we just create alternative versions in the same Schlib file for every project. In this alternative version we then add the name of the used function after the generic pin name.
This works pretty good because you can just always use the normal version to start your schematic and then later you create a new alternative version of the mcu and change the symbol on the schematic by updating it and selecting this alternative version.

[Jeroen3]

Yeah, modern chips where all of the signals can reach almost all of the IO are a pain.
But the convention I use is:
- The pin is named Pxy.
- The pin number is visible.
- The net is named PERIPHx_SIGNAL.
- An arrow is drawn on comment layer to indicate pin direction.

Nets that qualify for pin swapping are put in a bus during routing, you can easily highlight this bus to see which pins/nets have optimal route. These are miscellaneous gpio, pin swapping peripheral signals is too much work. Even with ST's tool.

We need a standard for this....

[D3f1ant]

When I create new library parts I use  simple short port name as per datasheet. All the generic reusable information is added to library, pcb footprint, supplier links, feeder width, temperature etc. ie a single nice detailed library part.

When doing the schematic design, I place the part and then edit the pin name by adding adding a suffux for the pin task and set pin type/direction.
('edit pins' in symbol properties)
I also unlock the pins and move them around the symbol to make for logical looking schematics. I'll sometimes hide unused pins if they make clutter, or hide those 100 ground pins after connecting them and add a text note to the schematic to say that's what's done. The design compiler works and when doing sanity checks later the clear labels make it easy to check against the datasheet.
Altium stores all the part information (except the actual PCB footprint) with the schematic, you can open it years later without needing a library. I don't quite understand why you would want a separate library for every project, but if you did, you can always create a custom library from the schematic with a few clicks.