Hi Clemens,

Yes, this idea would only work for small and medium sized ICs, but would be nice to not depend on external tools besides Kicad and its symbol libraries to do it.
Anyway, a tabled based entry might be a good solution.

I'm glad to see that this issue is a concern among Kicad devs.

Thanks,
Augusto Fraga Giachero.

On 30-01-2018 21:37, Clemens Koller wrote:
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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

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


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

Reply via email to