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=gmail.com; s=20120113;
	h=date:from:to:subject:message-id:in-reply-to:references:mime-version
	:content-type:content-transfer-encoding;
	bh=u3VPEALkce+8j7uO3lZgyPvdlViTk+iJnDS49iD0OkE=;
	b=zHOFnB2VfAgz4n8doOvRPvgYhw5eSTZuGWlBXYl/djxxDqYRtiW1dP8u/pN+u8LaDs
	7/LYQaqJho+MeIJjZzki42GaauItw6e36AQ5v56SkUd7ToJoD/EJL84WM1a3jLNU9pU5
	RdEu9mdUk/d/P6dAHzFpDVJR1zxbhr0HYeUbkk/SyBufzgVEba9z1JXXTsmJ7HpiLV1f
	m72odyOUf/8xtMg0Q14rFNMHj6wbmKhpYFgVnjUNPXZBGY4PlNnQoQPcYxNdASfSxwx0
	7Wf/V9F7YYPmPvzplsvL/zH9H86oThIFaCN1r4pVl8cYvPUzUYL5daTfU5lO4Ck5CyKi
	jeAw==
X-Received:	by 10.194.134.197 with SMTP id pm5mr29533300wjb.118.1445203809282;
	Sun, 18 Oct 2015 14:30:09 -0700 (PDT)
Date:	Sun, 18 Oct 2015 23:30:04 +0200
From:	"Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Pin mapping (separate symbols from mappings)
Message-Id:	<20151018233004.78db1f9df1b1e68325c8639e@gmail.com>
In-Reply-To:	<201510181843.t9IIhmWo025346@envy.delorie.com>
References:	<20151018204010 DOT 9cce6a231dcc296256e187bd AT gmail DOT com>
	<201510181843 DOT t9IIhmWo025346 AT envy DOT delorie DOT com>
X-Mailer:	Sylpheed 3.5.0beta1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
Mime-Version:	1.0
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

> > I think it would be rather good to separate symbols from pin mapping
> > and in such case symbols would have symbolic information only.
> 
> I agree, I wrote something up about this a while ago:

I agree about the pin mapping "pinseq" and "pinnumber" should not be necessary and pins should be indentified by "pinlabel". Then is the question if there should be an attribute to select pin mapping or external storage. For ICs i think mapping could be selected by heuristics by the value for many cases.


> http://www.delorie.com/pcb/pin-mapping.html
> 
> It assumed there was a new tool that used various heruistics and rules
> to "heavify" a symbol, including adding a pin map:
> 
> http://www.delorie.com/pcb/component-dbs.html

From the link below. I would say heuristic for most components is value and footprint. I say the BOM generator store this in a separate file, it may also remember decisions. Main reason is it would not be necessary to update schematic if manufacturer part number is changed.


My idea is to have a third repository of information, which contains the difference between a light and a heavy symbol. This extra database, which I'll call the component database or "partdb" (because "componentdb" just doesn't roll off the tongue), contains all the info needed to turn a light (generic) symbol into a heavy (specific) symbol. For example, if your schematic called for a 3.3uF 16v capacitor, the database would let you find all the manufacturers who make such a part, what the available packages are, and what PCB footprints they'd use. Based on some heuristics, a specific component would be chosen to be used, and the additional information added to the symbol and element.

There's a couple of issues that come up when you design such a database:

    What are the heuristics?
    How is the database stored?
    When the user changes the criteria for choosing a component, what happens?
    Where is the extra information stored?

- Raw text -