X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-UW-Orig-Sender: fpm AT homer02 DOT u DOT washington DOT edu
Date: Mon, 10 Feb 2014 08:11:33 -0800 (PST)
From: Frank Miles <fpm AT u DOT washington DOT edu>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] How to identify nc pads in tsym files
In-Reply-To: <CAD2FfiGyyumxy0CVdw7sCVwxhThJ4dGha3jLLyLobwNKP1xcXg@mail.gmail.com>
Message-ID: <alpine.LRH.2.01.1402100805360.15107@homer02.u.washington.edu>
References: <CAD2FfiGyyumxy0CVdw7sCVwxhThJ4dGha3jLLyLobwNKP1xcXg AT mail DOT gmail DOT com>
User-Agent: Alpine 2.01 (LRH 1217 2009-02-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.2.10.160017
X-PMX-Server: mxout12.cac.washington.edu
X-Uwash-Spam: Gauge=X, Probability=10%, Report='
 TO_IN_SUBJECT 0.5, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_1099 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, NO_URI_FOUND 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CT_TEXT_PLAIN 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TO_IN_SUBJECT 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __USER_AGENT 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
Precedence: bulk

On Mon, 10 Feb 2014, Richard Hughes wrote:

> Hi,
>
> I'm dealing with a QFN16 package where the middle "pin" is used as a
> signal. The only way to get to the middle pin is a via (not sure this
> is a good idea...), or I can trivially use an nc pin on the package to
> get to the center.

You have to be careful about 'NC' pins.  Sometimes these are truly not
connected; but for some chips these are connected to internals in ways
not fully revealed in the datasheet - so the pin is more of a "don't YOU
connect to this" than a truly "Not connected (anywhere)".

> In the tsym file I'm just commenting out the nc pins with a # at the
> start of the line, but this gives me a conflict when I check for
> unrouted signals in pcb. Should I be doing something different in the
> tsym file so that I notify pcb that the pin really is unconnected from
> anything internal and free to use for routing?

If you can confirm that it's really not connected, you could give the NC
pin the same pinlabel (hmmn... think that's the right parameter).

 	-F