kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #31679
Eeschema connectivity storage
Hi Wayne, JP, and others with lots of Eeschema knowledge,
I am working on a set of features to expand the capabilities of buses in
Eeschema (more details soon, but in short, extending the concept of a bus
beyond just a vector of signals with the same prefix, to an arbitrary
grouping of signals).
As I have looked in to this more, I have realized that it would be very
useful for the implementation of these features (as well as others I can
imagine) if the way that connectivity is managed were to be
refactored/expanded.
Right now, my understanding of the code is that connectivity between
objects is only calculated as part of creating a netlist --
in SCH_EDIT_FRAME::BuildNetListBase(). This information is not cached
anywhere or attached to the graphics objects, so it needs to be
recalculated every time it is requested (today mostly by the "Highlight
Net" feature).
Since some of the things that I am working on would benefit from having
easy access to the associated net/bus information for a graphical item, I
was thinking that it would be a good idea to store this information and
update it when the schematic is modified, rather than recalculating it
every time it is needed.
If I go down that path, then I start to think about how to store the data
-- right now we have NETLIST_OBJECT, but this class is mostly targeted at
ending up with a netlist suitable for ERC/transfer to PCB, and has some
behavior that doesn't really line up with what I want -- for example, it
"explodes" buses into individual objects for each bus member.
I could either expand/rework NETLIST_OBJECT to do what I want, or I could
leave it alone and build a different storage structure in parallel. The
latter option might result in some duplicated data, but would also somewhat
isolate these new features from the netlist generation code, which could
reduce risk of breaking something.
Do you have any input about this?
Thanks,
Jon
Follow ups