kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

Hey Jon,

There is currently a CERN work order for improving bus handing which
would almost certainly clash with anything you are working on so you may
want to hold off until that is implemented.

On 11/16/2017 09:24 PM, Jon Evans wrote:
> 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.

The NETLIST_OBJECT is where this should be done.  Keeping it synched
with schematic changes could be expensive because the current design
doesn't really support incremental updates.  I'm not even sure that is
possible or practical.  It may be necessary to create a different object
for this purpose but I would rather not.  On my todo list is a unified
SCHEMATIC object that would handle updating the NETLIST_OBJECT when new
objects are added to the schematic that change the netlist.  When I have
time to get around to that is anyone's guess at this point.  I'm hoping
find time to work on it once the new schematic file formats are complete.

Cheers,

Wayne

> 
> 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
> 
> 
> _______________________________________________
> 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
>