MIME-Version: 1.0
In-Reply-To: <51E5B2AD.1020402@sonic.net>
References: <51E5B2AD DOT 1020402 AT sonic DOT net>
Date: Tue, 16 Jul 2013 21:37:38 -0400
Message-ID: <CACPio-6aur2ZGM4h-eExHgOQxOi6bwsqt0eOD-_ksXZ-3xGS2g@mail.gmail.com>
Subject: Re: [geda-user] Should uCtlr symbols have mutable attributes
 reflecting pinmux? Discuss.
From: Nathan Stewart <therealnathanstewart AT gmail DOT com>
To: geda-user AT delorie DOT com
Content-Type: multipart/alternative; boundary=047d7bb04b4086476f04e1ab237e
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
Precedence: bulk

--047d7bb04b4086476f04e1ab237e
Content-Type: text/plain; charset=ISO-8859-1

I really hate to discourage it, because I do like the idea. But my need for
this is lessened by per project symbols. I got into this for revision
control, but now it just makes stuff like this a non issue.  I just modify
my local copy of the symbol to reflect usage.
On Jul 16, 2013 4:58 PM, "Dave Curtis" <davecurtis AT sonic DOT net> wrote:

> Modern microcontrollers typically have several functions that can be
> brought out to each pin, under control of some pin routing registers.
> Typically, I've used a pinlabel such as:
>
> pinlabel=PD5 (PCINT21/OC0B/T1)
>
> which shows the canonical GPIO name, plus other possible functions in
> parens afterwards.
>
> A few days ago I was showing a friend (a KiCAD user) the output from the
> symbol generator that I am working on, and he asked if there was a way to
> make the pinlabel reflect the actual pin function as deployed in the
> application, and lose all the other stuff. (Apparently, part of his
> motivation is to drive some flavor of rule checker that KiCAD has... but I
> don't know much about that).  My first reaction to his idea was, and I
> quote: "Oooooh... that seems like a really baaaad idea."  I'm not so sure
> I'm a fan of dancing symbols.
>
> After thinking about it for a while, though, I can see some benefits.
>  Here is one possible implementation that I have thought of, using the
> above pin as an example:
>
> 1. Let the pinlabel be the canonical GPIO name: pinlabel=PD5
> 2. Add another attribute at the symbol level, not the pin level, that
> reflects the assigned mux function.  There will need to be an attribute
> name per pin, since this is at the symbol level. For instance:
> pinfunc11=(PCINT21)
> 3. When constructing the symbol, let pinfuncXX default to: pinfuncXX=(GPIO)
> 4. Lay out the symbol so that pinfunc's display anchor is next to the
> pinlabel, so the net result looks the same as if the pinlabel were: PD5
> (GPIO)
> 5. Since pinfuncXX is attached to the symbol, not the pin, the user can
> edit pinfuncXX's to reflect the application.  Now the schematic symbol will
> look as if the pinlabel were: PD5 (PCINT21)
>
> This seems like a useful addition to the project documentation.  It does
> create a bunch more schematic editing work, though.  And a microcontroller
> with 88 mux'ed IO's will have 88 more attributes.
>
> One possible benefit is that you could easily write a simple script to
> sweep the .sch file for pinfuncXX attributes, and use the values to drive a
> C code generator that automatically created pin mux initialization code.
> Or, you could go the other way, extract pinmux information from the
> application and have a script set the pinfuncXX attributes.
>
> As with many questions involving symbols, much is a matter of taste and
> methodology.  I don't think there is any right or wrong answer here, but I
> throw the idea out for discussion.  I'm contemplating adding support for
> this in my symbol generator as an experiment.
>
> -dave
>
> P.S. Conceptually, this is parallel to slotting.  One could imagine direct
> support in gschem for well-known pin attributes something like
> "funclabel=PCINT21,OC0B,T1" in the symbol and "pinfunc=N" as an *editable*
> pin attribute, but that would require quite a bit of gschem's machinery to
> get re-wired, I suspect.
>
>

--047d7bb04b4086476f04e1ab237e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>I really hate to discourage it, because I do like the idea. But my need =
for this is lessened by per project symbols. I got into this for revision c=
ontrol, but now it just makes stuff like this a non issue.=A0 I just modify=
 my local copy of the symbol to reflect usage.</p>

<div class=3D"gmail_quote">On Jul 16, 2013 4:58 PM, &quot;Dave Curtis&quot;=
 &lt;<a href=3D"mailto:davecurtis AT sonic DOT net">davecurtis AT sonic DOT net</a>&gt; w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Modern microcontrollers typically have several functions that can be brough=
t out to each pin, under control of some pin routing registers. =A0 Typical=
ly, I&#39;ve used a pinlabel such as:<br>
<br>
pinlabel=3DPD5 (PCINT21/OC0B/T1)<br>
<br>
which shows the canonical GPIO name, plus other possible functions in paren=
s afterwards.<br>
<br>
A few days ago I was showing a friend (a KiCAD user) the output from the sy=
mbol generator that I am working on, and he asked if there was a way to mak=
e the pinlabel reflect the actual pin function as deployed in the applicati=
on, and lose all the other stuff. (Apparently, part of his motivation is to=
 drive some flavor of rule checker that KiCAD has... but I don&#39;t know m=
uch about that). =A0My first reaction to his idea was, and I quote: &quot;O=
ooooh... that seems like a really baaaad idea.&quot; =A0I&#39;m not so sure=
 I&#39;m a fan of dancing symbols.<br>

<br>
After thinking about it for a while, though, I can see some benefits. =A0He=
re is one possible implementation that I have thought of, using the above p=
in as an example:<br>
<br>
1. Let the pinlabel be the canonical GPIO name: pinlabel=3DPD5<br>
2. Add another attribute at the symbol level, not the pin level, that refle=
cts the assigned mux function. =A0There will need to be an attribute name p=
er pin, since this is at the symbol level. For instance: pinfunc11=3D(PCINT=
21)<br>

3. When constructing the symbol, let pinfuncXX default to: pinfuncXX=3D(GPI=
O)<br>
4. Lay out the symbol so that pinfunc&#39;s display anchor is next to the p=
inlabel, so the net result looks the same as if the pinlabel were: PD5 (GPI=
O)<br>
5. Since pinfuncXX is attached to the symbol, not the pin, the user can edi=
t pinfuncXX&#39;s to reflect the application. =A0Now the schematic symbol w=
ill look as if the pinlabel were: PD5 (PCINT21)<br>
<br>
This seems like a useful addition to the project documentation. =A0It does =
create a bunch more schematic editing work, though. =A0And a microcontrolle=
r with 88 mux&#39;ed IO&#39;s will have 88 more attributes.<br>
<br>
One possible benefit is that you could easily write a simple script to swee=
p the .sch file for pinfuncXX attributes, and use the values to drive a C c=
ode generator that automatically created pin mux initialization code. Or, y=
ou could go the other way, extract pinmux information from the application =
and have a script set the pinfuncXX attributes.<br>

<br>
As with many questions involving symbols, much is a matter of taste and met=
hodology. =A0I don&#39;t think there is any right or wrong answer here, but=
 I throw the idea out for discussion. =A0I&#39;m contemplating adding suppo=
rt for this in my symbol generator as an experiment.<br>

<br>
-dave<br>
<br>
P.S. Conceptually, this is parallel to slotting. =A0One could imagine direc=
t support in gschem for well-known pin attributes something like &quot;func=
label=3DPCINT21,OC0B,T1&quot; in the symbol and &quot;pinfunc=3DN&quot; as =
an *editable* pin attribute, but that would require quite a bit of gschem&#=
39;s machinery to get re-wired, I suspect.<br>

<br>
</blockquote></div>

--047d7bb04b4086476f04e1ab237e--