X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Thu, 19 Feb 2015 05:10:46 +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? (intconn) In-Reply-To: <54E4F42D.2090600@ecosensory.com> Message-ID: References: <1502170242 DOT AA18887 AT ivan DOT Harhan DOT ORG> <54E354D4 DOT 3040509 AT ecosensory DOT com> <54E4D15E DOT 4000202 AT ecosensory DOT com> <54E4F42D DOT 2090600 AT ecosensory DOT com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-85233039-1424319046=:7324" 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-85233039-1424319046=:7324 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 18 Feb 2015, John Griessen wrote: > On 02/18/2015 12:05 PM, gedau AT igor2 DOT repo DOT hu wrote: >> That would result in separate copper pads that find.c thinks are magically >> connected but are not connected in reality (unless you >> soldered a component or wire on them that realizes the "internal >> connection"). > > I was thinking of a large pad in the center that connects them with copper. > So that the footprint itself is > the component. That's one pad extra. I think it would work without an extra pad, but the idea is otherwise the same. > > On 02/18/2015 03:26 AM, gedau AT igor2 DOT repo DOT hu wrote:> >> My proposal makes this more explicit because the non-overlapping parts of > the pads would be sticking out, like bristles of a >> hedgehog and there is an 1:1, visible connection between a pad and nets. > Just like with connectors now. > > How to do like that? I guess intconn does not do it, I've also been confusing > it too. As I said, intconn can not do this. There are two different problems. One is the star connection, which is not solved by intconn, and the other is the classic "smd 0 ohm jumper" problem which is solved by intconn. The confusing part is that the two features are doing similar thing at a level. I will try to clarify this at the bottom of this mail. > > The description of how to create a star connection component could be: > > The "Star connection point" has one more pin than the number of nets desired > to connect > as one physical net with branches that star outward from the star point. > > The pins around the edges pass drc by spacing apart from each other, but > overlap a central pad > that connects them all. > > DRC rules allow a short to go unreported in a radius from the center of the > "Star connection point". > > One pin has an attribute "highest_name" whose value could be VCC or GND or > XXX. The others lack that > attribute, and might have netnames like VCC-A1 VCC-D1 VCC-D2... > > > Netlisting creates a netlist with the "highest_name" value on all of the nets > attached to all the pins > of the "Star connection point". PCB would be able to highlight or associate > netname with paths and pads, > and optionally associate of highlight or match netlist to "highest_name" and > all that touch it through > the star point. > I think my proposal #3 was simpler and does not depend on a radius, nor does it require introducing an extra pad. It also doesn't require any change in the netlist. Below I will try to explain the two concepts from all aspects I can think of. Sorry, it's a wall of text. Note: it was long ago I did intconn so some details in the following explanation may be wrong (e.g. whether it goes depth-first or not). Please ignore such mistakes, the important aspect does not depend on these details. What find.c did before the intconn patch was this (described in an oversimplified way): 0. There is a starting object and the task is to list everything that's (galvanically (copper) or logically (rat)) connected to it on the current design. Set the current object to the starting object and mark it found. Clear the mark from all objects on the design. Make an empty object list called the "open list". 1. Check all non-marked traces, find the first that touches the current object. If found, mark it, put it on the open list, go to 1, else go to 2. 2. Check all non-marked polygons, find the first that touches the current object. If found, mark it, put it on the open list, go to 1, else go to 3. 3. Do the same with vias, pins, pads, arcs, rats, etc., you get the point. 4. If we got here, we finished mapping/marking/listing all objects that is in direct contact with our current object. Throw away the current object. If the open list is not empty, take the first object from the open list and make it the current object and go to 1, else go to 5. 5. If we got here, the open list is empty, we finished mapping all connected objects. Run this from a trace for example. You will soon or later hit a pad. If the pad is not connected to any other objects, it is a dead-end and, the search ends there. This is the most common case on a finished design. The intconn patch adds this to the above, to the points where pad and pin connections are considered: 3a. if it is a pin or a pad, also check whether it has intconn() set. If it does, imply a _logical_ connection between the current pin/pad and all the pins/pads that are connected: mark those pins/pads, put them on the open list. In other words: some pins/pads are connected in reality even if they are not connected on the PCB, and find.c must be able to follow those "non-existent" connections as well. NOTE: intconn() must be a property of the pad as there may be multiple groups of independent internal connections in an element. The star patch which we need works on the same spot, but does the opposite: 3b. if the current object is a pad/pin (let's call it A) and the next non-marked object is also a pad/pin (call it B), and the two pads are part of the same element and the element is marked as "pads don't short", do _not_ mark B. In other words: althoug there is an explicit, visible physical connection on copper between your pads, just ignore it! NOTE: the "pads don't short" could be a property of the whole element (easy support for stars) or a per-pad property. For the star, we need the second feature. The first feature (intconn) would leave us with: - a set of pads not physically connected - while pcb thinks they are connected (assuming you solder some component on them that will connect them) So it is useful in _adding_ "find.c connections" where there is no physical connection. It is a permission for find.c to jump to a seemingly unconnected pad. The second feature ("pads don't short") sets it up so we have: - a set of pads connected physically by thick copper - still pcb thinks they are totally separated pads with no connection - ... unless you connect them by traces elsewhere (this would indicate shorts other than in the middle of the star component) - each pad is connected to it's dedicated network So it is useful in _removing_ a "find.c connection" where there's real copper connection on the design. It is a logical blocker or barrier for find.c so it won't jump from one pad to another inside a star element. I think the confusion comes from the fact that the two features differ only in "sign" on this level, adding or removing a find.c jump. Attached are two examples of how I imagine a star footprint. PCB is not very good in displaying pin numbers, so the upper pad's numbers are not visible (could be tweaked by mirroring the pads I guess). Regards, Igor2 --0-85233039-1424319046=:7324 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=star1.fp Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=star1.fp DQpFbGVtZW50WyIiICIiICIiICIiIDE2MDAwMCAxNDI1MDAgMCAwIDAgMTAw ICIiXQ0KKA0KCVBhZFswIC0xMjUwMCAwIDAgNTAwMCA1MDAwIDc1MDAgIiIg IjEiICJzcXVhcmUiXQ0KCVBhZFstMTI1MDAgMCAwIDAgNTAwMCA1MDAwIDc1 MDAgIiIgIjIiICJzcXVhcmUiXQ0KCVBhZFswIDAgMCAxMjUwMCA1MDAwIDUw MDAgNzUwMCAiIiAiMyIgInNxdWFyZSxlZGdlMiJdDQoJUGFkWzAgMCAxMjUw MCAwIDUwMDAgNTAwMCA3NTAwICIiICI0IiAic3F1YXJlLGVkZ2UyIl0NCg0K CSkNCg== --0-85233039-1424319046=:7324 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=star2.fp Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=star2.fp DQpFbGVtZW50WyIiICIiICIiICIiIDIwMDAwMCAxMjc1MDAgMCAwIDAgMTAw ICIiXQ0KKA0KCVBhZFswIDAgMCAxMjUwMCA1MDAwIDUwMDAgNzUwMCAiIiAi MSIgInNxdWFyZSJdDQoJUGFkWzc1MDAgMCA3NTAwIDEyNTAwIDUwMDAgNTAw MCA3NTAwICIiICIyIiAic3F1YXJlIl0NCglQYWRbMTUwMDAgMCAxNTAwMCAx MjUwMCA1MDAwIDUwMDAgNzUwMCAiIiAiMyIgInNxdWFyZSJdDQoJUGFkWzIy NTAwIDAgMjI1MDAgMTI1MDAgNTAwMCA1MDAwIDc1MDAgIiIgIjQiICJzcXVh cmUiXQ0KCVBhZFswIDIwMDAwIDAgMzI1MDAgNTAwMCA1MDAwIDc1MDAgIiIg IjUiICJzcXVhcmUsZWRnZTIiXQ0KCVBhZFs3NTAwIDIwMDAwIDc1MDAgMzI1 MDAgNTAwMCA1MDAwIDc1MDAgIiIgIjYiICJzcXVhcmUsZWRnZTIiXQ0KCVBh ZFsxNTAwMCAyMDAwMCAxNTAwMCAzMjUwMCA1MDAwIDUwMDAgNzUwMCAiIiAi NyIgInNxdWFyZSxlZGdlMiJdDQoJUGFkWzIyNTAwIDIwMDAwIDIyNTAwIDMy NTAwIDUwMDAgNTAwMCA3NTAwICIiICI4IiAic3F1YXJlLGVkZ2UyIl0NCglQ YWRbLTYyNTAgMTYyNTAgMTEyNTAgMTYyNTAgNzUwMCA1MDAwIDEwMDAwICIi ICI5IiAic3F1YXJlIl0NCglQYWRbMTYyNTAgMTYyNTAgMzEyNTAgMTYyNTAg NzUwMCA1MDAwIDEwMDAwICIiICIxMCIgInNxdWFyZSxlZGdlMiJdDQoNCgkp DQo= --0-85233039-1424319046=:7324--