Mail Archives: geda-user/2013/07/16/22:05:43
This is a multi-part message in MIME format.
--------------010301050500080703000906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Yup, that's certainly an option. But doesn't that lead to an explosion
of almost but not quite the same symbols? Do you think that helps or
hurts overall readability?
-dave
On 07/16/2013 06:37 PM, Nathan Stewart wrote:
>
> 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
> <mailto: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.
>
--------------010301050500080703000906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Yup, that's certainly an option. But
doesn't that lead to an explosion of almost but not quite the same
symbols? Do you think that helps or hurts overall readability?<br>
<br>
-dave<br>
<br>
On 07/16/2013 06:37 PM, Nathan Stewart wrote:<br>
</div>
<blockquote
cite="mid:CACPio-6aur2ZGM4h-eExHgOQxOi6bwsqt0eOD-_ksXZ-3xGS2g AT mail DOT gmail DOT com"
type="cite">
<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 control, but now it just makes stuff like this
a non issue. I just modify my local copy of the symbol to
reflect usage.</p>
<div class="gmail_quote">On Jul 16, 2013 4:58 PM, "Dave Curtis"
<<a moz-do-not-send="true" href="mailto:davecurtis AT sonic DOT net">davecurtis AT sonic DOT net</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
pinlabel=PD5 (PCINT21/OC0B/T1)<br>
<br>
which shows the canonical GPIO name, plus other possible
functions in parens afterwards.<br>
<br>
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.<br>
<br>
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:<br>
<br>
1. Let the pinlabel be the canonical GPIO name: pinlabel=PD5<br>
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)<br>
3. When constructing the symbol, let pinfuncXX default to:
pinfuncXX=(GPIO)<br>
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)<br>
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)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-dave<br>
<br>
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.<br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>
--------------010301050500080703000906--
- Raw text -