X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <51E5B2AD.1020402@sonic.net> Date: Tue, 16 Jul 2013 13:53:01 -0700 From: Dave Curtis User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: geda-user AT delorie DOT com Subject: [geda-user] Should uCtlr symbols have mutable attributes reflecting pinmux? Discuss. Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: geda-user AT delorie DOT com 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.