Is there a way to have a long/short pin name?

Schematic
1

So TL;DR - is there a way on microcontrollers and other parts that have overloading on pin functions to show a short and/or long version of a pin’s name. E.g.: a short name that is normally displayed on the schematic, but if I click on the schematic pin or do a mouseover, it shows the full list of pin functions?

So this is something that’s bugged me for years, using Eagle. Most modern microcontrollers have pins with huge, overloaded lists of pin functions. E.g.: I’m working with the ESP32 and some of the pins have 9 different functions associated with them.

The problem is how do I represent that?

On one hand, I can just mark the example pin as GPIO12 and call it a day. If I want to know what alternate pin functions it has, I can look it up in the datasheet. The problem is that’s slow - I have to open up the PDF, scroll to the pin assignment tables and look up the function. When I’m designing a schematic, with a chip where various functional blocks are scattered all around the chip, that can be very slow and error-prone. I’ve made the mistake of mixing up two similarly named pin functions while going to and from the datasheet and then ending up with coaster PCBs.

Alternately, I could concatenate the pin functions onto the pin name and give the pin a name like IO12/ADC2_5/TOUCH5/RTC_IO15/MTDI/HSPIQ/HS2_DATA/SD_DATA2/EMAC_TXD3. That’s really informative and I can just look at the schematic and at a glance see where, say, the HSPI block is on the pins. It saves a trip to the datasheet and is much faster. But it gives ridiculous schematic parts that eat up half the sheet in order to accommodate the giant pin names.

Both of these solutions are non-ideal. What I would love is to be able to name the pin IO12 and then to have a long_name field for the pin that has the whole ridiculous IO12/ADC2_5/TOUCH5/RTC_IO15/MTDI/HSPIQ/HS2_DATA/SD_DATA2/EMAC_TXD3 name in it. That full name can be shown in properties or in a notes field or in a popup if I click on the pin or do a mouseover, etc.

So, my question is there a way to do this? My guess is that the answer is ‘no’. However, it does seem like something that would be quite useful to have.

1 Like
2

With the current state of the schematic editor, I think the answer is no. But, since a complete overhaul of the schematic libraries and schematic editor graphics engine is on the roadmap, you could file a bug report on https://bugs.launchpad.net/kicad and mark it as a wishlist item.

4

Ah, glad to hear that it’s at least in discussion.

I’ve been thinking a bit more of how one could implement such a system.

A long/short name implementation is obviously the simplest, in both terms of coding and updating the libraries but probably the least useful in terms of handling very complicated ICs like FPGAs.

What you are talking about is a far more useful system. Having some sort of key:value store that you can populate for each pin would be very nice. That would mean that you have a ton of flexibility on how to display the pins. However, I still see it being a bit to constrained. Simply having a list of alternate names limits one’s ability to display those names based on functionality. If the pin format is going to be redone, it should be redone in a way that maximizes flexibility and minimized the amount of hard-coding.

Right now, it’s very hardcoded and inflexible - a pin name and pin number field. The pun number field is the only one that really should be hardcoded, as it’s basically a UID for the pin. Everything else should be flexible and extensible.

Let’s say you want to display the pins data associated with all analog pin types. Or all UART or a specific UART bank. That’s only really possible if you incorporate some sort of schema and meta-descriptor info. For example, the schema could describe a number of nested functional levels of categories.

e.g. with some psuedoJSON for an example (just written up on the fly, don’t expect it to be particularly well thought out):

Pin: {
  UIDNumber: 18,
  GPIO:{
    type: digital,
    groupType: none,
    ID: 31,
    LogicState: tristate
  },
  UART:{  //descriptor for UART/Serial/bank 2/RXD
    groupType: functionalBlock,
    type: digital,
    keywords: {communication},
    Serial:{  //inherits digital and communication from UART
      groupType: functionalBlock,
      bank_2:{
        groupType: functionalSubBlock,
        RXD:{
          longName: Receive,
          logicState: input
        }
      }          
    },
    SPI: { //inherits digital, communication from UART
      groupType: functionalBlock,
      type:digital,
      bank_0:{
        groupType: functionalSubBlock,
        CLK:{
          longName: Clock,
          logicState: output
        }
      },
      bank_3:{ //this IC has overlapping SPI pin definitions, terrible design!
        groupType: functionalSubBlock,
        MISO:{
          longName: Master In Slave Out,
          logicState: input
        }
      }
    }
  },
  ADC:{  ADC, bank 1, pin 3
    groupType: functionalBlock,
    type: analog,
    bank_1:{
      groupType: functionalSubBlock,
      pin_3:{
        logicState: input
      }
    }
  }
}

As you can see, this gives a ton of flexibility. You can have UI display elements based on things like functional blocks at differing levels, keywords, analog/digital, etc.

This lets the UI give the user the ability to display the info they need. Let’s say I’m working with an FPGA and only care about GPIO and ADC pins. I can use some sort of selector dialog to filter the names and other display options to just those. The UI can scan the functional blocks to match names against GPIO and ADC and only parse that info per pin.

The parse is smart enough to know that top-level functional groups like ADC, UART, SPI are things that the user is going to want to select based on what sort of thing they do. Functional sub blocks represent things like banks and can be something that the user can optionally select from once they chose a top-level selector. When the user makes choices, the parse can just walk the tree, grabbing up all the descriptors down to the leaf-level.

Then, with that info, you can change pin graphics, color, names, put colored blocks behind things, etc. Its all decoupled and up to the particular UI implementation, mode, user input, etc. There’s very little that’s hard coded, just things like functional blocks, sub blocks, individual pin info, etc. All the UI is be able to parse that and then let the user pick out what they want.

Thoughts?