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>
	<alpine DOT DEB DOT 2 DOT 20 DOT 1709121647020 DOT 5445 AT nimbus>
From:	"Barry Jackson (zen25000 AT zen DOT co DOT uk) [via geda-user AT delorie DOT com]" <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:	<alpine.DEB.2.20.1709121647020.5445@nimbus>
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

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

- Raw text -