Hello, Augusto!
Your ideas regarding multiplexed I/Os are good, but might only be sufficient for small to medium-complex CPUs/FPGAs/modules/circuits. If you follow the latest developments, you will notice that there are even bigger things coming up and it will get more and more difficult to visually represent the huge amount of varying I/Os and to solve dependencies and restraints. So, in the long term, I suggest to have a look at some even more flexible methods as i.e. (database-) tabled based design entry.
This means that a design tool (here KiCad) IMO needs to polish it's interfaces to the outside world to import/export pin lists and netlists on request.
Some tools can work with lists/.CSVs, but seem to lack automation (forward/backward annotation). I am working a lot with databases and use my own glue (sql-scripts) to import/export generated pin lists to/from the Pin-Multiplexing software and to/from the design. Version managment is also mandatory.
You might have a look at i.e. the Altera Pin Planner, Xilinx IO Planning or the Pins Tool from NXP to get an idea where we are heading to:
https://www.nxp.com/pages/pins-tool-for-i.mx-application-processors:PINS-TOOL-IMX
Regards,
Clemens
On 2018-01-30 16:01, Augusto Fraga Giachero wrote:
Hi,
I've been designing schematics with some stm32 parts using the standard
Kicad libraries, and a lot of these microcontrollers has 10+ functions
multiplexed in each I/O pin. In the standard library the symbols
displays all possible configurations available to each pin, I understand
the motivation of this choice (not having to refer to the datasheet
every time you want choose an I/O for some specific functionality), but
this results in very large symbols occupying the page.
I've come with a idea (which probably isn't new) to deal with this problem:
* You can select what functions you will use from a list for each pin
and only that will be displayed in the schematic;
* You can then resize the symbol accordingly directly in the schematic;
* While this wouldn't require any modification to the library symbol
file format as the description string of each pin already carries all
the necessary information, the .sch file format would probably be
changed and would not have backwards compatibility.
This may not be easy to implement as with the way eeschema handles
symbols today and the issues I've cited above, I would like hear about
your suggestions.
Thanks,
Augusto Fraga Giachero.
_______________________________________________
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
_______________________________________________
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
