Mail Archives: geda-user/2013/07/16/16:56:08
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.
- Raw text -