X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Tue, 17 Feb 2015 05:33:24 +0100 (CET) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] Star connection points in PCB? In-Reply-To: <1502170242.AA18887@ivan.Harhan.ORG> Message-ID: References: <1502170242 DOT AA18887 AT ivan DOT Harhan DOT ORG> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 17 Feb 2015, Spacefalcon the Outlaw wrote: > 2. I wanted to make people aware that the oft-seen "solution" of > putting physical jumpers, resistors or inductors on the board > instead of layout starpoints can have its own serious problems, > Openmoko's infamous bug #1024 being a glaring example. Cool, I've been working around this problem in a similar fashion but this made me pondering. > > Now as far as actually implementing starpoint support in PCB, I'm > thinking of the following approach: find the code that checks for > shorts, and work the hack in there: teach the code that for certain > pairs of nets declared in some way, having exactly *one* short is > fine, but having two or more shorts is bad - and having no short at > all is bad too for those special nets. But I might be totally off- > base here, not having looked at the code at all yet. Anyone familiar > with PCB's handling of shorts who is reading this - is my idea on the > right track or totally off-base? I played around with this part of code for the mincut patch in my fork. The code is not small nor trivial, but not terribly hard to deal with either. find.c, about 4500 lines in my fork. I think your proposed solution is not the best, tho: suppose there are more than 2 nets need to be connected at a single point A and soem of them have a short at another point B, while another bunch have a short at point C. You have 3 hot spots then, from which the user intention was "connect everythting at A", but PCB may not be able to chose wisely. Of course we could always highlight all shorts or highlight something randomly, but imho this causes UI that won't help the user. Actually this was the very reason for my mincut effort: the original way shorts are displayed is tehcnically correct, but not helpful. What I'd rather have is something more explicit. Proposal 1 An explicit multi-pin device on the netlist, all nets connected to that on separate pins. It can be drawn as a circle or a star or a poly with evenly spaced pins on the schematics. Now the hard part: get PCB to support sort of auto-poly-element: the element is a single polygon, explicitly marked to be that element, and whatever else touches it an implicit pin is created, automatically. If the connection between (the explicit-on-netlist) element and (the explicit-on-netlist) network is identified, pin number is set from the netlist, else it's an invalid connection (short). Incoming nets are separate nets, any short elsewhere is an error clearly identified and shown there. This is a hackish approach that perhaps requires a lot of new code, probably doesn't fit in pcbs current model of the board and I think solves only this one problem (not an universal flexible tool). Proposal 2 use my mincut hack, make the starpoint explicit at least in pcb and say: it is a valid short if it is in the R mils radius of the explicit starpoint. This introduces a special starpoint object (might be a special flag on a line segment or a polygon or a pin or via) which basically has the magic ability to cancel the effect of shorts, as long as: - the short is R mils near to it's center (or outline?) - even better, if the short is somehow marked valid between this object and that net on the netlist Hackish thing, sounds a bit dangerous and probably requires extra support in the netlist (to describe the second condition) Proposal 3 Add a component flag in pcb that tells "there is no short between the pads of this component, even if they overlap!", then draw the actual star out of pads. The starpoint is an explicit component in pcb and an explicit symbol on the schematics. Each net has its own dedicated pin, No short anywhere, so won't interfere much with find.c, except that flag, which should be relatvely easy to implement (saying that after intconn, a patch f mine doing the opposite). Drawbacks: - the same pin numbering and back-annotation problem that you have with connectors - the star symbol/footprint will have explicit number of pins, you may end up unused pins or will have to replace with the next bigger if more nets are to be connected To be honest I don't really like any of these three, but if I had to chose, I'd go for the third. Regards, Igor2