Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Hi Michael, On Mon, 2009-06-29 at 05:44 +, Michael Sokolov wrote: Bert Timmerman bert.timmer...@xs4all.nl wrote: cvs -d anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda [...] copy-pasting the cvs command to a Bourne shell on my workstation gives that a password other than Enter is required. Oops, forgot the :pserver: part; try the following: cvs -d :pserver:anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user got cvs co working Simply typing make barfs the following: logged output [MySandbox]$ cd ueda [ueda]$ make cd libueda; make make[1]: Entering directory `/users/users/bert/MySandbox/ueda/libueda' cc -O -c -o readmcl.o readmcl.c readmcl.c: In function ‘read_MCL’: readmcl.c:41: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c:58: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c:74: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c:84: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c:90: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c:96: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c: At top level: readmcl.c:112: error: static declaration of ‘setup_partdef’ follows non-static declaration readmcl.c:50: error: previous implicit declaration of ‘setup_partdef’ was here readmcl.c: In function ‘setup_partdef’: readmcl.c:122: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c:128: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c: At top level: readmcl.c:140: error: static declaration of ‘parse_refdes_list’ follows non-static declaration readmcl.c:53: error: previous implicit declaration of ‘parse_refdes_list’ was here readmcl.c: In function ‘parse_refdes_list’: readmcl.c:149: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c: At top level: readmcl.c:168: error: static declaration of ‘finish_component’ follows non-static declaration readmcl.c:49: error: previous implicit declaration of ‘finish_component’ was here readmcl.c:184: error: static declaration of ‘clone_component’ follows non-static declaration readmcl.c:179: error: previous implicit declaration of ‘clone_component’ was here readmcl.c: In function ‘clone_component’: readmcl.c:192: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c: At top level: readmcl.c:203: error: static declaration of ‘handle_part_ref’ follows non-static declaration readmcl.c:103: error: previous implicit declaration of ‘handle_part_ref’ was here readmcl.c: In function ‘handle_part_ref’: readmcl.c:212: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c:236: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c:241: warning: incompatible implicit declaration of built-in function ‘exit’ readmcl.c: At top level: readmcl.c:246: error: static declaration of ‘getline’ follows non-static declaration readmcl.c:44: error: previous implicit declaration of ‘getline’ was here make[1]: *** [readmcl.o] Error 1 make[1]: Leaving directory `/users/users/bert/MySandbox/ueda/libueda' make: *** [libueda] Error 2 [ueda]$ /logged output Hope this helps in any way :) Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Bert Timmerman bert.timmer...@xs4all.nl wrote: got cvs co working Simply typing make barfs the following: [snipped] smart ass mode Your OS is too modern. Install something that is at least 25 years obsolete and try again. /smart ass mode Seriously though, Ineiev has already told me that ultra-modern versions of gcc refuse to compile uEDA as distributed by me. So you need to apply some local patches of your own to port it to your modern OS. uEDA is developed on/under/for 4.3BSD-Quasijarus, my own version of UNIX that very faithfully maintains the traditions of UNIX Version 7 and Berkeley VAX UNIX. The C compiler maintains strict compatibility with the KR C standard aka C78. uEDA does however compile OK under Slackware 10.2 and RHEL 4. Lots of warnings, but no fatal errors, so I just ignore them. MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Hi Michael, On Mon, 2009-06-29 at 06:23 +, Michael Sokolov wrote: Bert Timmerman bert.timmer...@xs4all.nl wrote: got cvs co working Simply typing make barfs the following: [snipped] smart ass mode Your OS is too modern. Install something that is at least 25 years obsolete and try again. /smart ass mode Seriously though, Ineiev has already told me that ultra-modern versions of gcc refuse to compile uEDA as distributed by me. So you need to apply some local patches of your own to port it to your modern OS. uEDA is developed on/under/for 4.3BSD-Quasijarus, my own version of UNIX that very faithfully maintains the traditions of UNIX Version 7 and Berkeley VAX UNIX. The C compiler maintains strict compatibility with the KR C standard aka C78. uEDA does however compile OK under Slackware 10.2 and RHEL 4. Lots of warnings, but no fatal errors, so I just ignore them. MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user I'm still running FC5 (which is declared dead for over 2 years now, EOLT June 2007) on my devel box, have some old i486/i586 boxes on RH6.1 in the garage, so porting to RH6.1 maybe something funny for after the holidays. I hope to install FC11 on a new box soon, as my gtk version is too old to compile gEDA and pcb ;-( Kind regards, Bert Timmerman. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Dave N6NZ wrote: I believe this style leads to the most readable schematics, and scales up well to larger designs. Agreed. At least until you do like me, and forget to put down the power symbol once (or twice). :) At the risk of going OT, I'll add that as I get better at following the above strategy--- which is particularly helpful with more complex parts like microcontrollers--- I get really frustrated at gschem's strong association between pin numbers on the symbol, and pin numbers on the footprint. That's just... wrong. It would be nice if there was an additional layer of abstraction somewhere between the symbol and footprint, such that actual pin assignments weren't made until the footprint (and slot, if necessary) were specified. Until that point, it doesn't really matter anyway. For example, I once merely changed the footprint= parameter in a MOSFET symbol, from to92 to sot23, and found out the Hard Way that doesn't work. I think it should. As a mostly software guy, I think about schematic capture the way I think about C code: it's a specification for signal/data/control flow only, and the underlying details about how the physical machine implements that specification take place later. When you tie physical pin numbers into the symbol, however, you lose the advantage that a schematic capture exercise is supposed to provide you in the first place: the ability to think at a level above the hardware. The solution might be to get rid of physical pin numbers in symbols entirely, and replace them with virtual pin numbers that map to physical pin numbers in some intermediate processing step. For example, a 7400 symbol might have pin numbers A, B, and Y, and then our DIP16 footprint would have pin numbers A.1, B.1, and Y.1, A.2, B.2, Y.2, etc. When the user specified the footprint=DIP16 and slot=2, then an intermediate step could bind the pins from the symbol to the pins on the footprint automatically. (And once that binding took place, gschem could report the physical pin numbers on the schematic as an option). Later on, if I swapped the 7400LS/DIP16 package out for a LittleLogic/SOT5, that footprint would also have A.1/B.1/Y.1 pin numbers, so gaf would know how to re-bind the virtual pins from the symbol to the right places. Ok, if you have been paying attention so far, you'd probably be getting ready to say that all the above isn't really the right solution to the problem either. But if you've followed me this far--- and I thank you for doing so!--- then you'll get where I'm going next and why. :) Packages like SOT5 and DIP16 are used everywhere, not just for LittleLogic and 7400. So just going to a virtual pin naming convention that's 7400-specific, like I just described, doesn't really solve any problems--- it just moves them around a bit. What is REALLY needed is for footprints to use physical pin numbers as they do today, and then use a table (probably carried with the symbol) that does the ABY-pin mapping on a per-footprint basis. Something like this: footprint=DIP14 vpinppin A.1 1 B.1 2 Y.1 3 A.2 4 B.2 5 Y.2 6 GND 7 ... VCC 14 footprint=SOT6 vpin ppin A.1 1 B.1 2 Y.1 4 GND 3 VCC 5 The above would likely be highly-redundant, at least for 7400-series parts, so maybe they could be placed in a footprinttable=7400.fpm file, or something. When there were exceptions, then the table provided with the symbol would overrule. A side-effect of the above is that it lets you have exactly one NAND symbol, regardless of the footprint of the device the user ultimately chooses. It also lets you have only one DIP16 footprint for all users of that footprint. And one ATtiny44 in-circuit-programming connector symbol that works with all the different footprints that microcontroller comes in, even though the pin assignments are different--- because the tools can sort out where the wires should go once you indicate the footprint to use. And MOSFETS... and so on. I think the above solution is pretty compelling, and it isn't a big step away from what we have today. It's just an additional layer of abstraction above/replacing the slotdef= parameter. I'm hardly the guy to talk about how hard it would be to implement, but it doesn't seem THAT hard... :) b.g. -- Bill Gatliff b...@billgatliff.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Bill - On Sun, Jun 28, 2009 at 12:26:10PM -0500, Bill Gatliff wrote: [greatly trimmed] It would be nice if there was an additional layer of abstraction somewhere between the symbol and footprint, such that actual pin assignments weren't made until the footprint (and slot, if necessary) were specified. It's just an additional layer of abstraction above/replacing the slotdef= parameter. I basically agree with the argument. The final trick that would make a larger audience happy is the ability to back-annotate the schematic with the physical pins -- and presumably a switch for whether to display the physical or virtual pin IDs -- so that the engineer can print out (for the field technician) a schematic that has physical pins on it. Even the original design engineer wants such a printout when bringing the board up for the first time. - Larry ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
On Jun 28, 2009, at 11:26 AM, Bill Gatliff wrote: At the risk of going OT, I'll add that as I get better at following the above strategy--- which is particularly helpful with more complex parts like microcontrollers--- I get really frustrated at gschem's strong association between pin numbers on the symbol, and pin numbers on the footprint. gEDA has no such strong association. It's a product of the way you *use* gEDA. That's just... wrong. It would be nice if there was an additional layer of abstraction somewhere between the symbol and footprint, such that actual pin assignments weren't made until the footprint (and slot, if necessary) were specified. Until that point, it doesn't really matter anyway. When first drawing the circuit that needs a low noise opamp, copy one of the opamp symbol files into your project symbol directory under the name low_noise_opamp.sym. Place that. As its pin numbers, attributes, etc. become clear, edit it (Hs) to suit. Or replace the symbol file with something else. gEDA uses a powerful, hyper flexible association mechanism that other packages can't match: your computer's file system. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
On Jun 28, 2009, at 10:26 AM, Bill Gatliff wrote:
As a mostly software guy,
Taking this as you can code some scripts up..
Here is one approach for you to try.
pick a small set of some chips you care about. lets say a large
family of the AVR series.
To the symbol:
Add a virtual pin attribute
Add the pin map file attribute.
example
snippet from a symbol.
T 3000 9800 8 10 1 1 0 6 1
refdes=U?
T 400 9950 8 10 0 0 0 0 1
device=ATmega16
T 400 10150 8 10 0 0 0 0 1
footprint=TQFP44_10
T 400 10400 8 10 0 0 0 0 1
pinmap=ATmega16.fpm
P 2600 100 2600 300 1 0 0
{
T 2650 200 5 8 1 1 0 0 1
pinnumber=?
T 2650 200 5 8 0 1 0 2 1
pinseq=1
T 2600 450 9 8 1 1 0 3 1
pinlabel=Reset
T 2600 600 5 8 0 1 0 3 1
pintype=in
T 2600 850 5 8 0 1 0 3 1
virtualpin=reset
}
snippet from pinmap. oops the examples weren't different.. :-P
so I faked data DON'T make a part with this fakery!
device=ATmega16
footprint=TQFP44_10
{
# virtual pin, footprint pin [, pin type]
reset, 4
xtal2, 7
AD10, 35
..
}
footprint=MLF44
{
# virtual pin, footprint pin[, pin type]
reset, 4
xtal2, 10
..
}
#fake
footprint=TQFP64
{
reset, 6
xtal2, 10
AD10, 35
?, 44, nc # Here pin 44 has no name, and is a no connect pin.
...
}
footprint=PDIP28
{
reset, 2
xtal2, 4
AD10, ?, na# here ADC 10 was ommited from this part to fit it in
the smaller package
...
}
Now with this groundwork you can run a script that will update the
schematic page's symbols with mapped pins.
To do this you will probably need to embed the symbols into the
schematic first. Then map the pin numbers from ? to the real pin
numbers.
We would probably need to add the pintypes of nc for no connect and na
for not available, to allow for parts that have fewer pin packages,
and no connects in larger packages.
Got some code game?
Steve
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Bill Gatliff b...@billgatliff.com wrote: At the risk of going OT, I'll add that as I get better at following the above strategy--- which is particularly helpful with more complex parts like microcontrollers--- I get really frustrated at gschem's strong association between pin numbers on the symbol, and pin numbers on the footprint. That's just... wrong. It would be nice if there was an additional layer of abstraction somewhere between the symbol and footprint, such that actual pin assignments weren't made until the footprint (and slot, if necessary) were specified. Until that point, it doesn't really matter anyway. That's exactly how I've implemented it in uEDA. As a mostly software guy, I think about schematic capture the way I think about C code: Ditto! The solution might be to get rid of physical pin numbers in symbols entirely, and replace them with virtual pin numbers that map to physical pin numbers in some intermediate processing step. For example, a 7400 symbol might have pin numbers A, B, and Y, and then our DIP16 footprint would have pin numbers A.1, B.1, and Y.1, A.2, B.2, Y.2, etc. Wow, just like in uEDA, except that you chose '.' as the separator character and I chose ':' in uEDA for that purpose. A.1 1 B.1 2 Y.1 3 A.2 4 B.2 5 Y.2 6 GND 7 ... VCC 14 Even your proposed table format is *exactly* the pinout mapping file format used by uEDA except for the slot separator character. Is someone reimplementing uEDA here? How about the other way around? Anyone feel like porting the gschem GUI to operate on the uschem file format? That's the only remaining piece that's missing from the uEDA solution. cvs -d anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda The documentation is still incomplete though. MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Hi Michael, On Mon, 2009-06-29 at 03:20 +, Michael Sokolov wrote: Bill Gatliff b...@billgatliff.com wrote: deleted stuff was here Is someone reimplementing uEDA here? How about the other way around? Anyone feel like porting the gschem GUI to operate on the uschem file format? That's the only remaining piece that's missing from the uEDA solution. cvs -d anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda The documentation is still incomplete though. MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user copy-pasting the cvs command to a Bourne shell on my workstation gives that a password other than Enter is required. Kind regards, Bert Timmerman. logged output [MySandbox]$ cvs -d anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co u eda The authenticity of host 'ifctfvax.harhan.org (208.221.139.2)' can't be established. RSA1 key fingerprint is 57:9b:73:ce:db:67:96:3b:e8:40:c1:1f:35:a6:82:29. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'ifctfvax.harhan.org,208.221.139.2' (RSA1) to the list of known hosts. anon...@ifctfvax.harhan.org's password: anon...@ifctfvax.harhan.org's password: Permission denied, please try again. anon...@ifctfvax.harhan.org's password: Permission denied, please try again. Permission denied. cvs [checkout aborted]: end of file from server (consult above messages if any) /logged output ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Bert Timmerman bert.timmer...@xs4all.nl wrote: cvs -d anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda [...] copy-pasting the cvs command to a Bourne shell on my workstation gives that a password other than Enter is required. Oops, forgot the :pserver: part; try the following: cvs -d :pserver:anon...@ifctfvax.harhan.org:/fs1/IFCTF-cvs co ueda MS ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
