X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wellesley.edu; s=gmail; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=J3O6DWbotT1YUbtshCKuWjOosvMFwZgIVgOEGk0WSlM=; b=SPsNkV8p6qKom5/xyT91AUjpRQiIQQ7EvhcwiyEHTY3KhqD3pZcwlFf+D2ID7eK8AK dNCmYZi6RYwHKyncAqFD0GpGefhn7oMnb/OcFeQ8K6l+a0HU6UWLjTaX9WfdQqP9qAnK tNjngqnVe5SnCDkNSj8idvYsJnXScwRDsYGTeYukxG3CaIVHLFWPr4u6O4mQe4qjsk/z ds4bu9vFNnBy6BFLgt+ztx/e/fIgAWyNw6i4nGIqJeOQwfYIRBKOSTjqZWTsA/V2VTWX Af52GQ7h5AFDlH1R8kCCEUTxsY4fwEbCKPWBchxNwqfGgLZt6vcPKhBKvXvF0dLjnyLj 15bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=J3O6DWbotT1YUbtshCKuWjOosvMFwZgIVgOEGk0WSlM=; b=SnkSkEyY2Jmn0CvLDz/78BFkBmHTuML/eqA82CoWxU0PKYXU+ZQqrRF74eNr6ejSgo kLvnVsGpOlAsaX+7z4iwyCH0VpUMPEdbw3ZRW6dUTU2KBQWoQ+MdGoU+3L9MqupD7Nxk Jrw+UCnYinHpr7g0u+vAy52KJQImWd/p6Mw/wbKZEH17N3xowzAliQfiZPBK75lKl0HT pjAWIZz7glJnipMDo2OFKLwWjAReoceeAxgAs34XuNLqo1p7xuCDji92Z9WH50cZ/JCr VXl9vDUYPXDxgQPrLvAoXDefp+HkAQgLyoRBR0hTwn1rnTp1srSaTGmJj22GDXqqsrST sInA== X-Gm-Message-State: AODbwcBuWQ3wuKF7OpYtqcclA8+fEVoLX6EaS29TCuy9TedEp9zaviv3 CFHnPYlBsI1u+9cCfGK1PQ== X-Received: by 10.200.50.216 with SMTP id a24mr23881901qtb.91.1496160705579; Tue, 30 May 2017 09:11:45 -0700 (PDT) Subject: Re: [geda-user] [pcb-rnd] up next: subcircuits (a.k.a. footprint model redesign) To: geda-user AT delorie DOT com References: From: "James Battat (jbattat AT wellesley DOT edu) [via geda-user AT delorie DOT com]" Message-ID: Date: Tue, 30 May 2017 12:11:44 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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 Igor2, all, I'd be very happy to provide testing for any improvements on how to specify and re-use a layout for a collection of footprints. Specific example: say I'm designing a board that reads out 24 temperature sensors (RTDs). Each RTD channel has a pair of op-amps and surrounding circuitry, with identical layout. Can I specify/layout a single channel, and then tell pcb-rnd to repeat this layout for the other 23 channels? (without manually updating the REFDES for each component in channels 2-24)? This may already be possible, but I don't know how to do it... James On 5/30/17 2:21 AM, gedau AT igor2 DOT repo DOT hu wrote: > Hi all, > > now that pcb-rnd 1.2.3 is out, it's time to celebr^W focus on the next > big chunk of work. > > A few months back we made a feature poll among pcb-rnd users about > which feature was the most wanted. The result was: > > 1st: editable layers (just released) > > 2nd: subcricuits (see below) > > 3rd: pad stacks and blind/buried vias (with the lowest score possible > - seems to be a lower priority task with no real user demand, > postponed for a later date) > > So next big chunk is subcircuits: footprint model redesign. > > Current situation: pcb elements > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > There are a lot of feature requests out there about extending the > footprint model. A few random example: > > - polygon in footprint, 2009, 2010 > http://archives.seul.org/geda/user/Sep-2010/msg00619.html > http://archives.seul.org/geda/user/Jun-2009/msg00370.html > > - arc in footprint, 2010: > http://archives.seul.org/geda/user/Apr-2010/msg00613.html > > - how to work around missing mask editing feature in footprints, 2004: > https://www.mail-archive.com/search?l=geda-user AT seul DOT org&q=subject:%22Re%3A+gEDA-user%3A+PCB%3A+how+to+clear+soldermask+from+entire+footprint%22&o=newest&f=1 > > > It would be possible to add code just for these cases. However, each > such example would introduce a new set of special cases in the code > base, and these cases will always interact with almost all other such > specil cases. Which means an exponential growth in special case vs. > sepcial case interaction that would be rather hard to maintain long > term. This is not the route we take in pcb-rnd. > > Generally speaking, the problem is that our footprint model is a bag > of special cases: footprints can have the special objects, for example: > > - element-line, but that's only lines drawn on silk > > - (smd) pad, which can't have arbitrary shape and must be on top or > bottom copper > > - pin, which is basically just an "element-via", with some pin number > and pin name attached; mostly code dup of via plus code dup from smd > pads for the number/name > > - exactly 3 silk text objects, from which only 1 can be dispalyed at > any given time (refdes, footprint description, value) > > - a bunch of automatic side effects, like mask and paste on smd pads > > There are some clever hacks to work around some of the limitations, > usually by combining pads and pins. But this is not building from > pure, orthogonal bricks, but building from fuzzy haystacks, mainly > trying to combine and cancel side effects. I know this "works", I know > we do this since forever, but this is far from the optimal solution. > > > Future: subcircuits > ~~~~~~~~~~~~~~~~~~~ > I am going to slowly replace this old mechanism in pcb-rnd with a new > system called "subcircuits". From the user's point of view, a > subcircuit takes the same role as a "footprint" (... in a lib, or > "element", when placed on a board - as of gEDA/pcb terminology). > > A subcircuit does not have special objects like "pins", "pads" or > "element-lines". Instead, it has the same objects that the layout has: > lines, arcs, polygons, text and vias. (In fact I am going to use the > same C struct that the board uses, which is pcb_data_t in pcb-rnd). > > Trick #1: flexible layer handling > > Just like a board, a subcircuit also has a layer stack. When the > subcircuit is a footprint, this layer stack is not a particular > physical stack, rather a recipe. E.g. instead of fixed layer numbers, > this stack would contain patterns like "this layer should be in the > top copper physical layer on the board". It could indirectly reference > any physical layer: copper, silk, mask, paste, outline; top, bottom or > even inner layers. Once the subcircuit is placed on a board with an > actual physicla layer stack, the layer binding is performed: with or > without interactive user intervention, using the layer stack recipe, > each layer the subcircuit uses is boud to one of the actual layers of > the board. > > Trick #2: flexible terminal handling > > Just like in tEDAx, pins/pads are no special objects but plain drawing > primitives tagged for a given terminal. Terminal is the "pin number, > pin name" concept. A multiple vias, lines, arcs, polygons or even text > objects can be tagged to be part of a terminal. The netlist sees > terminals only. > > Result: > > In practice this means our new footprints will be capable of hosting: > > - arbitrary shaped pads drawn as lines and polygons > > - arbitrary shaped copper objects not being pads; a.k.a. pcb antenne; > but this includes copper text or mask cutout text too; your company > logo can really be a footprint > > - arbitrary mask cutouts, mask cutouts that are not derived from pads > > - arbitrary placement of paste; want a grid of paste blobbs on the > center pad of your largish qfn? no need t emulate it with 10 pads, > just draw them on the paste layer > > - slots or other cutouts/edge-contour-patterns; even the whole board > shape can be a footprint > > - text and polygon on silk > > > Schedule > ~~~~~~~~ > > This will probably take a long time, spanning multiple development > cyclces, just like the layer rewrite did. > > Stage 1: > > We will start implementing it in the current cycle and will make it > gradually grow until it reaches its full featured, final form. We will > make sure that at every intermediate release subcircuits are usable > and alreayd provide extra features over footprints. We will keep the > original footprints in place during this process. > > Lihata board v3 will have support for subcircuits. The subcircuit > subtree will also be avaialble as a subcircuit file format for sharing > footprints. > > While we are in this stage, we'll encourage users to use subcricuits > instead of footprints, and always save in lihata board v3 instead of > other formats. However, the code will still be able to use the old > footprints in parallel. > > Stage 2: > > At some point in time subcircuits will be capable enough to replace > footprints. At this point we will remove footprints, pins, pads, > element-lines, element-arcs. We will also need to rewrite import code > to convert old elements to subcricuits on load and rewrite export code > to convert subcircuits back to elements for old formats. > > Stage 3: > > We'll convert pcblib from the old, element based .fp files to lihata > subcircuit files. We'll rewrite the parametric footprint scripts to > generate lihata subcircuits instead of pcb elements. This will include > extending some of the parametrics with features that was not possible > with pcb elements because of the limitaiton of the model/format. > > (This also means our parametric footprints won't be available for pcb > mainline without a conversion or without mainline upgraded to lihata > formats and the subcircuit model) > > > > What you can do to help > ~~~~~~~~~~~~~~~~~~~~~~~ > > Most wanted: testers. We are again going to change a critical part of > the system, we need all sort of testing. Testers with even only a few > hours a week are very valuable for getting such new features stable. > > Second most wanted: contributors on non-coding material (e.g. docs, > tutorials, test files) > > Production users: people who use the stable version of pcb-rnd for > actual production boards and report bugs. Especially those who are > willing to try out new features that are already labelled stable by > developers. > > Programmers: we have a growing number of developers and contributors, > but there's always more work than resources, obviously. Anyone is > welcome if they have some free time and willing to accept the pcb-rnd > ways of doing things. Be part of one of the most dynamic projects of > gEDA! > > Regards, > > Igor2