kicad-developers team mailing list archive

[Chris Pavlina <pavlina.chris@xxxxxxxxx>]

Has CERN began work on that yet?

On Fri, Nov 17, 2017 at 02:26:01PM +0000, Wayne Stambaugh wrote:
> 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
> > 
> 
> _______________________________________________
> 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