[v6] MCU_*

[chschlue]

• [ ] add alternate pin types

[myfreescalewebpage]

@KiCad/librarians not sure, but I think alternate pin type definition need first to go on v6, isn't it ?

[chschlue]

Yes.

[myfreescalewebpage]

Probably the best way to handle MCU is to script them. I mean, if it is possible, one script for all manufacturers. Will be easier to ensure the largest consistency across the lib.

Will try to think about that

[chschlue]

We have the STM32 generator Perhaps that can serve as a starting point.

[cpresser]

One feature I would love is drop-in compatible symbols for parts of the same series. An example for that is here: https://github.com/KiCad/kicad-symbols/pull/2336

[myfreescalewebpage]

@chschlue yes I know the STM32 generator, but it is based on the usage of (xml?) file from STM workbench (as far as I know). Which is not useful for the other manufacturers

[cpresser]

I am pretty sure we need to devise our own format.

• The STM .xml files need to be converted to it.
• Microchip provide bxl files that might have some information. https://github.com/KiCad/kicad-symbols/issues/2098
• For quite a lot of manufacturers we might need to manually write those files.
• Perhaps we can add a workflow for *.BDSL files
• At least some information needs to be added manually anyway (GNDStacks, Layout).
• We could also use that generator for other parts. FPGA_* comes to mind.

WIP yaml format.

• This is just a rough sketch!
• The idea of group is that all parts in one group share the same layout. The script looks at all parts, merges their pin-groups to find the common pins, then skips the pins that are not part of the specific symbol.
• the multiple-pin-functions feature of v6 is modeled in this proposed .yaml format.
• Aliases with different footprints could also be added, but right now I have no clue how that works

group: SAMD21
  name: ATSAMD21E18A
  description: foo
  keywords: bar
  aliases:
    ATSAMD21E17A:
      - description: foo2
      - keywords: bar17
  footprint: gnorfrogl
  footprint-filters:
   - abc
   - def
  pingroups:
    portA:
      position: right
      pins:
        # pin numbers as keys, since they are unique
        14:
          # list of functions 
          - PA14: Bidir
          - AN0: Input
          - TMR0OUT: Output
        15:
          - PA15: Bidir
          - AN1: Input
          - SERCOM2[0]: Bidir
    portB:
      pins:
        32:
          - PA02: Bidir
  supply:
    # we need GND stacks and stuff, so a different format for supply pins
    - GND:
      # on explicit position for GND, some heuristic can take care of that.
      - pins:
        - 7
        - 22
        - 41
    - GNDANA: 26
    # placing of those
    - VDDCORE:
      - position: top 
      - pins: 27 # just the number of the pin, pinlist if multiple pins

[myfreescalewebpage]

@cpresser I think this first proposition is clearly not bad. STM32 file should then be converted to the yaml format and we are ok. Joel

[Werni2A]

This sounds like an interesting topic. If there is something that I could help you with please let me know. I'm happy to give you a hand.

[cpresser]

@Werni2A Feel free to start with an implementation. The ATSAMD21 parts in the current lib are a good reference. They are well made and have all the features a generator should take care of. I personally won't have time to start working on this in the next weeks/months since my focus is on footprints and CI.

@chschlue BTW, what is the idea of the v6-dead label?

[chschlue]

It's supposed to mean "probably not feasible". I didn't expect so many people to leap at it. Feel free to change it.

[herostrat]

There is a PR for Symbol Generation of Xilinx FPGAs: https://github.com/KiCad/kicad-symbols/pull/1799

Imho this also is very promising and could be used as a reference?

[Werni2A]

Great, I will take a look at both scripts and start a first generator implementation that can be discussed. Is there some deadline I need to keep in mind?

[chschlue]

6.0-rc1 is planned for Dec 31 and while it would be great to have a (more or less) universal generator in place before then, well, we're all volunteers around here and things are done when they're done, so don't stress yourself. Another "deadline" is v6 file format freeze on Sep 30, meaning symbol files could theoretically still change until then.

[myfreescalewebpage]

Yes no specific deadline, if this is later it's not so important. The current libraries will be migrated to v6 format so we don't lose anything.

[Werni2A]

I tried to parse the Yaml file with the yaml package and directly process the values but I think this makes the script kind of unreadable and error prone. Do only I feel like this about "nested" dictionaries? My current idea is to write a class where all values from the Yaml file are written into. With this approach I can add some easy error handling and presetting values that are not specified in the Yaml file. But before writing this class I wanted to check if you think it's a good idea or way too much overhead. Maybe I'm just missing the right methods from the yaml package.

[myfreescalewebpage]

@Werni2A I'm not a python/yaml expert, but your comment let me thinking to the SOIC/QFN/etc/etc packages which are script generated. They have optional configuration keys and they handle various configuration possibilities so I suggest this is a good start to understand how they are working in details. This may help for this subject.