← Back to team overview

kicad-developers team mailing list archive

Re: [RFC] Symbols and Pin mapping in v6 - Proposal

 

Hello Ajith,

I admit i skimmed your proposal, but i think it looks like it has merit, and that work can be done to improve symbols and pin mapping.

I always struggle with multi use pins like on MCUs.  Its tedious to keep drawing boxes with pins, just to support a layout of pins that suits the pinmuxing your using, and the a decent layout of the schematic.

I think a complex component like an MCU or FPGA could work like a sub-sheet.  It doesn't have a shape or symbol, per-se.  Its JUST a list of pins.  You then drop one of that component (which is a resizeable box like a sub-sheet), and like a sub-sheet import pins from it and place wherever you want in the box boundary.  Want to break your MCU into functional units, just drop another box with the same reference, import the pins you want into there.  It would be a lot easier to manage, i think.  And would reduce redundancy in part definitions for complex MCUs, and make those parts a lot easier to define in the process.  But I also think its probably a lot of work to do, and I don't know how it would break the file formats.

However this would also allow one to choose the mux function/s which could set the appropriate pin attribute for that pin, input/output/open drain, etc.  Making DRC sane again.  The schematic would be neater and would also tell you more about what is intended than:

I2C2_CLK/SPI1_MISO/ADC3_CH6/CLK_OUT/UART3_TX/UART2_TX/TIMER2_A/SCLK | 10 -----

Does.  Which is how a lot of MCU's end up getting defined.  Instead the designer says, this pin is the I2C2_CLK and the pin then looks like this in the schematic:

I2C2_CLK | 10 -----

doesn't suit layout, right click on pin and change it to the I2C2_CLK on pin 239:

I2C2_CLK | 239 -----

Don't have to copy the component, move pins around, reimport the changed symbol, etc etc.

For simple components, like diodes, transistors, buffers, LDOs, opamps, etc etc.  Then a symbolic representation is definitely the way to go.  And your proposal would make that even nicer.  I like the list of pins example you gave for the transistor.  Much clearer from a schematic perspective.

Steven

On 12/9/19 11:36 am, Ajith N wrote:
Sorry the URL was mangled, here it is:
https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf


---- On Thu, 12 Sep 2019 12:30:26 +0800  ----

    Hi Developers,

    Requesting your attention to a proposal and discussion in the
    KiCad User Forum. The topic is symbols and pin mapping (for v6) as
    they relate to the data model.

    I took up a suggestion (by Rene Poeschl) to detail my proposal
    with diagrams, and have prepared some slides, which is at:

    https://gitel84.github.io/pdfs/kicad_syms_proposal.pdf    ; (PDF
    format)

    The background references are at the end.

    (I feared being unable to respond in a timely manner to potential
    questions which may arise in the course of discussions in the
    developers' list. Therefore, I have chosen to put more detail into
    the slides wherever possible. Hopefully that helps. The detail may
    be excessive for some readers though. If so please bear with me).

    I hope KiCad developers find this worth looking at for v6.

    Thanks for all the great work!

    P.S.
    I have been a happy user of KiCad for barely over a year now.
    KiCad to me is a very nice and open tool with nice features, has
    no lock-in, has an active community of users and is progressing in
    a good direction.





_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



Follow ups

References