X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Subject: Re: [geda-user] gshem 1.8.2 Bug? Slotting fails for a custom BPX85 photo-transistor array To: geda-user AT delorie DOT com References: <7b205135-7b91-e8f0-a5d8-efc4cb0b787d AT zen DOT co DOT uk> From: "Barry Jackson (zen25000 AT zen DOT co DOT uk) [via geda-user AT delorie DOT com]" Message-ID: <78fbcc25-16e6-c0d4-cecd-d236e5e0de9b@zen.co.uk> Date: Wed, 13 Sep 2017 12:07:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by delorie.com id v8DB7iWn011153 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 12/09/17 16:00, Roland Lutz wrote: > pinnumber= and pinseq= are entirely different concepts. > > Normally, you'd want to use the pinnumber= attribute; there's no reason > to add a pinseq= attribute unless you need it.  The pinseq= attribute is > only used in two situations: slotted components and some simulation > backends. > > In a slotted component, each pin with a pinseq= attribute is assigned a > pinnumber= attribute from the slot definition.  The original pinnumber= > attribute is ignored; in fact, there's no reason to add one in the first > place.  The pinseq= attribute specifies which of the numbers in the slot > definition is used for this pin. > > So, in your example, the correct attributes are: > > Component: >   slot=1 >   slotdef=1:1,10 >   slotdef=2:2,9 >   slotdef=3:3,8 >   slotdef=4:4,7 >   slotdef=5:5,6 > > First pin: >   pinseq=1 >   (pintype and pinlabel as appropriate, if needed) > > Second pin: >   pinseq=2 >   (pintype and pinlabel as appropriate, if needed) > > If you wanted, you could list the pins in the slot definition in reverse > order (10,1; 9,2; and so on) and swap the pinseq= attributes; this would > have the same effect. > > Thanks Roland, that now makes much more sense to me. I could see that virtually all the information needed for a slotted device was contained in the slotdef= attributes so I could not understand why all the docs I have read on symbol creation state that each pin MUST have pintype, pinnumber, pinlabel and pinseq attributes, which is apparently just plain wrong according to your explanation. Cheers Barry