Hello, Tim! I agree that in the near future, the demand for (I'd call it) "Table Based Design Entry" will rise tremendously, when we reach pincounts in the high hundreds and thousands.
It is a lot of work to draw and maintain complex MCUs/SoCs/FPGAs in some schematic when pins can have 8 different functions which might change during product development. A current example: i.MX8 [1] with i.e. 625 pins. So, it might not even be sufficient to be able to import (and export) .CSVs. It might be a good idea to prepare for some automatism to be able to update and version control pin multiplexing changes! Regards, Clemens [1] https://www.nxp.com/docs/en/data-sheet/IMX8MDQLQIEC.pdf On 15/09/2019 15.29, Tim Hawkins wrote: > What about shunting the problem aside and have the ability to load a fixed > format csv file with the details of the pin map. The file could then be > bundled with the project. Ie define a dynamic component, that has a physical > form, but its schematic forms are dynamic, and depend on the contents of the > csv (speadsheet), each row is one physical pin, with bus groups, lables and > other elements defined in the ss. > > On Sun, Sep 15, 2019, 9:18 PM Strontium, <[email protected] > <mailto:[email protected]>> wrote: > > 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 : [email protected] >> <mailto:[email protected]> >> Unsubscribe : https://launchpad.net/~kicad-developers >> More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : [email protected] > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
