Mail Archives: geda-user/2013/07/16/21:38:25
X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f
|
X-Recipient: | geda-user AT delorie DOT com
|
DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed;
|
| d=gmail.com; s=20120113;
|
| h=mime-version:in-reply-to:references:date:message-id:subject:from:to
|
| :content-type;
|
| bh=rF9ju1VkI/qZlnsaSm2SXLoj2eyOnAIHc7q1Kb4WWig=;
|
| b=sqSEOMSmEL3AmjGLpiPaA9RaX1w55V7JFn7vvi7A3GNBZTu11MB3n9dp2Kev/djQL1
|
| GkSPtsCDHPS1n6PuAA71IcUvQLeSgDfPnr9Irx5kylxW4ihUsl/0LW4/IHQHheu4EfBi
|
| WQ+gkMIR+JE2VEn6sBGfCdcViMME4F5Mty6EWkbcZ18i7UpVtAtLrS8sPq0UnIcUoFjf
|
| YaMGw08DkIcJxCGqqQBGWYIKbklv8EcKxesvxilFE5OjUKD+e1niE5vgcQEQWMdZ1hdl
|
| enipz1zM8dYYQxKuoksrPTtHsxZlveuR1h65ZoieheKMjce3wIbvuFgXB4M9qgpEQ0V6
|
| ITQg==
|
MIME-Version: | 1.0
|
X-Received: | by 10.195.12.202 with SMTP id es10mr3227994wjd.17.1374025058500;
|
| Tue, 16 Jul 2013 18:37:38 -0700 (PDT)
|
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
|
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
|
--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, "Dave Curtis"=
<<a href=3D"mailto:davecurtis AT sonic DOT net">davecurtis AT sonic DOT net</a>> 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'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't know m=
uch about that). =A0My first reaction to his idea was, and I quote: "O=
ooooh... that seems like a really baaaad idea." =A0I'm not so sure=
I'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'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'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'ed IO'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't think there is any right or wrong answer here, but=
I throw the idea out for discussion. =A0I'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 "func=
label=3DPCINT21,OC0B,T1" in the symbol and "pinfunc=3DN" 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--
- Raw text -