Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy
On Wed, 01 Jul 2009 00:22:08 -0400, evan foss wrote: And then offer a GUI to select from the list of footprints within gschem. It would be so cool if you could call pcb to render the footprint in a little window as a part of that GUI. This might make dependencies a mess though. It doesn't have to be rendered image. A list of preselected footprints associated with a symbol would go a long way. Why not support an attribute list-of-footprints in the symbol? This list could be tuned to fit the local combination of symbol and footprint lib. Protel98 provides this kind of preselected footprints. It was five entries maximum and we cursed Altium for this restriction. Consequently, I really miss this feature in gschem. ---(kaimartin)--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x6C0B9F53 ___ 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
Steven Michalske smichal...@gmail.com writes:
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.
pinmap=ATmega16.fpm
device=ATmega16
footprint=TQFP44_10
{
And then offer a GUI to select from the list of footprints within
gschem.
Stephan
___
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
On Tue, Jun 30, 2009 at 2:54 AM, Stephan
Boettcherboettc...@physik.uni-kiel.de wrote:
Steven Michalske smichal...@gmail.com writes:
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.
pinmap=ATmega16.fpm
device=ATmega16
footprint=TQFP44_10
{
And then offer a GUI to select from the list of footprints within
gschem.
It would be so cool if you could call pcb to render the footprint in a
little window as a part of that GUI. This might make dependencies a
mess though.
Stephan
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
--
http://www.coe.neu.edu/~efoss/
http://evanfoss.googlepages.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)
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
On Sun, Jun 28, 2009 at 9:46 PM, Dan McMahill [1]...@mcmahill.net wrote: For transistors and IC's, I have no problems with the enumerate them all approach I've taken. This is what I been doing too. All semiconductors are enumerated. Since all of the graphics are done by scripts there is a single copy of the graphics data. The script adds the appropriate attributes and pin numbering. (* jcl *) -- You can't create open hardware with closed EDA tools. [2]http://www.luciani.org References 1. mailto:d...@mcmahill.net 2. http://www.luciani.org/ ___ 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
Dan McMahill wrote: for things like transistors and IC's, I have already implemented exactly this for my own use. I have an ASCII file that associates a complete vendor part number (including package code) with a symbol template, a footprint, and a mapping from symbol pin to footprint pin. Then I have an awk script that reads in the database and produces a set of heavy symbols that have the correct pinout to match the footprint that goes with them. So on my schematic, I see the correct pin number. If I want to change from a part in a 16 pin DIP to a 20 pin PLCC, I pick the new part number with correct package code to instantiate. Oooh. Care to post them? Maybe create a gedasymbols page for yourself, and put it there? 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)
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
Larry Doolittle wrote: 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. Agreed. This 'trick' really is essential. 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
Bill Gatliff wrote: 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). :) Well, the netlist checker or some other DRC should whine about missing power. I always verify netlist connectivity manually anyway -- these days I do few designs that are so large I can't do it manually (although I recognize they exist.) 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. Agreed. I've felt that way since the beginning -- for the same reason that you mentioned: changing package. For me, it's pretty annoying to have to replace the schematic symbol to go from through-hole to surface mount just because the pin numbers are different. As a mostly software guy, Most of my opinions about schematic editing were formed as a logic designer on very large projects -- 30 to 60 logic designers (not counting circuit designers, techs, and CAD support). As a logic designer on large CPU projects, I never once thought about how to hook up power (except to keep under my budget of (say) 200A of -4.5V), and as far as clocks go, only the functionality, not distribution. (Although once I was assigned to the clock distribution team for a few weeks, and *all* I thought about was clocks.) Your comments about abstraction are right on -- correct partitioning and abstraction makes the design more manageable, both for a lone designer and for a large team. Adding an extra layer of pin mapping to gEDA, though, would be pretty difficult to do in an upward compatible way. While that's the right way, I'm not convinced enough of the ROI to make everyone redo their libraries. -dave ___ 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
Dave N6NZ wrote: Bill Gatliff wrote: 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). :) Well, the netlist checker or some other DRC should whine about missing power. I always verify netlist connectivity manually anyway -- these days I do few designs that are so large I can't do it manually (although I recognize they exist.) Yea, I need to explore that part of gaf more. I'm still kind of a newbie. Most of my opinions about schematic editing were formed as a logic designer on very large projects -- 30 to 60 logic designers (not counting circuit designers, techs, and CAD support). As a logic designer on large CPU projects, I never once thought about how to hook up power (except to keep under my budget of (say) 200A of -4.5V), and as far as clocks go, only the functionality, not distribution. (Although once I was assigned to the clock distribution team for a few weeks, and *all* I thought about was clocks.) If you powered up all of my designs that I've done over my entire career, the total probably wouldn't even approach 200A. You might not even get close if you got all the production units, too! :) Adding an extra layer of pin mapping to gEDA, though, would be pretty difficult to do in an upward compatible way. While that's the right way, I'm not convinced enough of the ROI to make everyone redo their libraries. I don't think the investment part is a large as it seems, because you'd be getting rid of redundancy in the existing symbol set. So you wouldn't have to rework EVERY symbol--- just one of each type. That's still a lot, I know... There's one minor point I hadn't accounted for, however, which is that a NAND symbol will go by lots of names like 7400, 4000, sn74ahc1g00, and so on, so the symbol library browser would need a little more smarts to place a symbol in multiple locations. I can imagine some wildcard-containing queries that would deal with that problem, but a basic directory structure won't deal with the problem I don't think. Hello, SQLlite. :) Are there cases where a device is so out-of-whack in its mapping between a NAND-type symbol that would properly represent it and the associated footprint pinout that we wouldn't be able to accomodate it without expressing it with its _own_ symbol and _own_ footprint? I don't think I've encountered such a part, but I don't have 200A of experience behind me. :) As far as being upwardly-compatible, could we leave the existing system in place for a few (forever) revisions? It's just a degenerate case where there's a 1-1 mapping between symbol pin name and footprint pin name. Seems like that could coexist peacefully with a few new attributes and logic. Finally, if there was better connection between a symbol repository like, say, gedasymbols.org and the gaf symbol/footprint browsers, then uptake of the new symbols would be greatly facilitated... :) :) 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)
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
John Doty wrote: 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. Oooh, please clarify! :) If there's an existing way to decouple pin numbers in symbols from pin numbers in footprints, such that I can get the Right Thing when merely switching footprints, I'd love to hear it. 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
John Doty wrote: 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. That sounds a lot like creating another symbol just to deal with a different footprint than the one the original symbol assumed. Which is the opposite of where I'm trying to go. 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
Dave N6NZ wrote: Agreed. I've felt that way since the beginning -- for the same reason that you mentioned: changing package. For me, it's pretty annoying to have to replace the schematic symbol to go from through-hole to surface mount just because the pin numbers are different. It just occurred to me that the problem is what a computer-science-type-guy would call one of namespace. Symbol pin numbers and footprint pin numbers come from the same namespace in gaf's implementation. They shouldn't. That is all. :) 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
On Jun 28, 2009, at 2:49 PM, Bill Gatliff wrote: John Doty wrote: 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. That sounds a lot like creating another symbol just to deal with a different footprint than the one the original symbol assumed. Which is the opposite of where I'm trying to go. Repeat after me: There are very few symbols distributed with gEDA that are perfectly suited to my project and my design flow. I understand you want to patch over this somehow. But whatever your patch is, it won't suit many (maybe most) flows. So the next person, with different needs, will require another patch. And so on. But customizing symbols in a project symbol repository preserves gEDA's flexibility. Keep gEDA simple. Use its flexibility rather than fight it. 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 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
On Jun 28, 2009, at 2:59 PM, Bill Gatliff wrote: Dave N6NZ wrote: Agreed. I've felt that way since the beginning -- for the same reason that you mentioned: changing package. For me, it's pretty annoying to have to replace the schematic symbol to go from through-hole to surface mount just because the pin numbers are different. It just occurred to me that the problem is what a computer-science-type-guy would call one of namespace. Symbol pin numbers and footprint pin numbers come from the same namespace in gaf's implementation. They shouldn't. There already is a separate namespace if you wish to use it: pinseq. But I think that is already confusing enough for most users. That is all. :) 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 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
John Doty wrote: Repeat after me: There are very few symbols distributed with gEDA that are perfectly suited to my project and my design flow. Agreed! I understand you want to patch over this somehow. Not so much patch over as to prevent duplication of work by every gEDA user out there reimplementing the same symbols and footprints over and over again. How many NAND symbols do we need? Right now, it's one for each different footprint that the symbol relates to. I think that's unacceptable. Yes, the core of gEDA is incredibly flexible and I don't have any desire to change that. I would just rather focus my CPU cycles on design, and not ridiculously redundant and error-prone junk like creating a half-dozen NAND symbols that only differ by one or two lines. That's grunt work that a silicon CPU should be doing, not me. 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)
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
Steven Michalske wrote: Taking this as you can code some scripts up.. Here is one approach for you to try. Aah, I hadn't even considered that possibility--- do it outside of gEDA instead of within it... D'oh! :) 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. I suppose I could even use the template to merely kick out a bunch of mostly-redundant .sym files, one for each footprint. That might be easier for me to start out with, rather than attacking a whole sch file at the same time... Got some code game? I just might! :) 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
On Jun 28, 2009, at 3:24 PM, Bill Gatliff wrote: John Doty wrote: Repeat after me: There are very few symbols distributed with gEDA that are perfectly suited to my project and my design flow. Agreed! I understand you want to patch over this somehow. Not so much patch over as to prevent duplication of work by every gEDA user out there reimplementing the same symbols and footprints over and over again. That's not what you do. You start with an existing symbol file, and just tweak it a little. Easy. How many NAND symbols do we need? Right now, it's one for each different footprint that the symbol relates to. I think that's unacceptable. How does your plan differ, except by making the process more complicated? You have to put the information *somewhere*. For maximum ease and flexibility, put it in your project's copy of the relevant symbol. You don't need to implement or learn *any* additional capability beyond what Hs gives you. Yes, the core of gEDA is incredibly flexible and I don't have any desire to change that. I would just rather focus my CPU cycles on design, and not ridiculously redundant and error-prone junk like creating a half-dozen NAND symbols that only differ by one or two lines. That's grunt work that a silicon CPU should be doing, not me. It is cannot any simpler or less error prone than editing the symbol file. The information has to come from *somewhere*, the computer cannot read your mind... 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 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
On Jun 28, 2009, at 2:30 PM, Bill Gatliff wrote: Steven Michalske wrote: Taking this as you can code some scripts up.. Here is one approach for you to try. Aah, I hadn't even considered that possibility--- do it outside of gEDA instead of within it... D'oh! :) The power of text based file formats :-) 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. I suppose I could even use the template to merely kick out a bunch of mostly-redundant .sym files, one for each footprint. That might be easier for me to start out with, rather than attacking a whole sch file at the same time... Hadn't thought of that. replace the symbol with a local copy with the modifications from the template. You can then even remove the unused pins Got some code game? I just might! :) ___ 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
John Doty wrote: How does your plan differ, except by making the process more complicated? You have to put the information *somewhere*. For maximum ease and flexibility, put it in your project's copy of the relevant symbol. You don't need to implement or learn *any* additional capability beyond what Hs gives you. But the information that's in *my* project will be identical to what's in everyone else's project. That's a waste. And it also makes it more labor-intensive to switch footprints, something that I think the tool should be able to deal with for me. Feel free to continue hand-crafting your own symbols. I'd rather a slightly different path. 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
On Jun 28, 2009, at 2:43 PM, Steven Michalske wrote: The power of text based file formats :-) The way I do connectors these days is that I have a connector symbol that's just a box with refes=, device=, and footprint=. I'll place that and draw a bus to it. Make the appropriate connections to the bus. Then, make a table of the pin connections and convert to a .sch file using the pins2gsch script I posted here last year. The pins2gsch output is humanly unreadable, but works fine with gnetlist as long as it comes after the real schematic on the command line (otherwise you run into the gnetlist only takes attributes from the first instance it sees bug). I think a table of pins is a much easier way to understand a big connector than a tangle of lines. The PC board layout guy I've been working with likes it also: he'll tweak the table to make his job easier, send it back to me... 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
This is an age old debate in EDA software. Where is the symbol weight stored? In each symbol, or in a database. ( Note when I say database, it can be a flat file or full blown relational SQL ) The Heavy vs. Light symbol debate. both answers are correct. let's build infrastructure for both. Unsurprisingly the very expensive software I use at work can't even do this... We use a heavy library. I'm ashamed about all of the screw ups with swapping identical parts, that I have seen, RHOS and Halogen free transitions were a pain.a light symbol could have automatically been mapped and the transition could have been reading a report for the automatically transitioned parts and verifying that they were identical, ONCE. not per project. I feel man WEEKS were wasted. 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
Stefan Salewski wrote: Currently we (may) have different symbol files for the the same device with different footprints. So we have the same graphics elements multiple times. This is redundancy, wast of storage area, and it makes it more work to modify the graphics. So it is not a perfect solution. And replacing a symbol in a schematic only because we want a different footprint is not a very natural way for me. Right. To me, the symbols in a schematic are strictly that--- symbols. Why should I switch to a visually-identical symbol, just because the pin assignments underneath have changed? Maybe we're philosophically disagreeing on what a schematic diagram represents. I don't think of them as wiring diagrams, but as signal flow diagrams. PCB's job is to turn that into a wiring diagram. Or something like that. Apparently to some, schematics are also wiring diagrams. Cool. So put wiring information into your symbols. All of them. 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
On Jun 28, 2009, at 2:58 PM, John Doty wrote: On Jun 28, 2009, at 2:43 PM, Steven Michalske wrote: The power of text based file formats :-) The way I do connectors these days is that I have a connector symbol that's just a box with refes=, device=, and footprint=. I'll place that and draw a bus to it. Make the appropriate connections to the bus. Then, make a table of the pin connections and convert to a .sch file using the pins2gsch script I posted here last year. The pins2gsch output is humanly unreadable, but works fine with gnetlist as long as it comes after the real schematic on the command line (otherwise you run into the gnetlist only takes attributes from the first instance it sees bug). I think a table of pins is a much easier way to understand a big connector than a tangle of lines. The PC board layout guy I've been working with likes it also: he'll tweak the table to make his job easier, send it back to me... This is fantastic example of scripted intermediate steps. Here is the message for those interested. http://archives.seul.org/geda/dev/Nov-2008/msg00069.html John did any bug fixes or features get introduced since then? Did you ever do or think about anything for mating connectors, or a graphical representation? Steve 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 ___ 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
On Jun 28, 2009, at 2:53 PM, Bill Gatliff wrote: John Doty wrote: How does your plan differ, except by making the process more complicated? You have to put the information *somewhere*. For maximum ease and flexibility, put it in your project's copy of the relevant symbol. You don't need to implement or learn *any* additional capability beyond what Hs gives you. But the information that's in *my* project will be identical to what's in everyone else's project. That's a waste. You're just entering it in a different layer. Creating a whole extra abstraction, for the same redundant information. That's a waste. And it also makes it more labor-intensive to switch footprints, Assuming I've already figured out the pin changes and edited a symbol to reflect them, or found somebody else's symbol that has the right pins: mv wherever/small_opamp.sym low_noise_opamp.sym Not so difficult. Of course, if the pin numbers don't change, it's merely a matter of changing footprint= in a single symbol file. In your scheme, you still have to tell the machine what the changes are: it can't read your mind. So it's no simpler. something that I think the tool should be able to deal with for me. The tool can't read your mind. Somebody has to enter the data. The tool already gives you an easy way to enter the data. So, there's nothing missing, nothing to improve. 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
On Jun 28, 2009, at 3:00 PM, Steven Michalske wrote: This is an age old debate in EDA software. Where is the symbol weight stored? In each symbol, or in a database. ( Note when I say database, it can be a flat file or full blown relational SQL ) The Heavy vs. Light symbol debate. both answers are correct. let's build infrastructure for both. It's not heavy versus light that matters. It's where you add the weight. The debate results from misunderstanding this. 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
On Sun, 2009-06-28 at 15:38 -0600, John Doty wrote: How many NAND symbols do we need? Right now, it's one for each different footprint that the symbol relates to. I think that's unacceptable. How does your plan differ, except by making the process more complicated? You have to put the information *somewhere*. For maximum ease and flexibility, put it in your project's copy of the relevant symbol. You don't need to implement or learn *any* additional capability beyond what Hs gives you. Currently we (may) have different symbol files for the the same device with different footprints. So we have the same graphics elements multiple times. This is redundancy, wast of storage area, and it makes it more work to modify the graphics. So it is not a perfect solution. And replacing a symbol in a schematic only because we want a different footprint is not a very natural way for me. Best regards Stefan Salewski ___ 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
On Jun 28, 2009, at 3:36 PM, Steven Michalske wrote: On Jun 28, 2009, at 2:58 PM, John Doty wrote: On Jun 28, 2009, at 2:43 PM, Steven Michalske wrote: The power of text based file formats :-) The way I do connectors these days is that I have a connector symbol that's just a box with refes=, device=, and footprint=. I'll place that and draw a bus to it. Make the appropriate connections to the bus. Then, make a table of the pin connections and convert to a .sch file using the pins2gsch script I posted here last year. The pins2gsch output is humanly unreadable, but works fine with gnetlist as long as it comes after the real schematic on the command line (otherwise you run into the gnetlist only takes attributes from the first instance it sees bug). I think a table of pins is a much easier way to understand a big connector than a tangle of lines. The PC board layout guy I've been working with likes it also: he'll tweak the table to make his job easier, send it back to me... This is fantastic example of scripted intermediate steps. Here is the message for those interested. http://archives.seul.org/geda/dev/Nov-2008/msg00069.html John did any bug fixes or features get introduced since then? Nope. What I posted there is identical to what I'm using except for some CVS boilerplate comments. I keep thinking I should wrap a shell script around it but I haven't gotten the proverbial round tuit. Did you ever do or think about anything for mating connectors, I just use the same table for both connectors. In the graphical schematic, the box representing the connector gets the appropriate device= and footprint= for its gender. Convert the table to .sch, include that .sch in the input to gnetlist for both boards. The designs I've used this for employ stacking connectors. If you lay out the most difficult board in the stack first, you can adjust its connector pinouts to reduce the difficulty and then propagate those to the other boards trivially this way. or a graphical representation? Nope. Steve 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 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user 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
On Jun 28, 2009, at 3:23 PM, Bill Gatliff wrote: Stefan Salewski wrote: Currently we (may) have different symbol files for the the same device with different footprints. So we have the same graphics elements multiple times. This is redundancy, wast of storage area, and it makes it more work to modify the graphics. So it is not a perfect solution. And replacing a symbol in a schematic only because we want a different footprint is not a very natural way for me. Right. To me, the symbols in a schematic are strictly that--- symbols. Why should I switch to a visually-identical symbol, just because the pin assignments underneath have changed? Why are you hung up on the form the container of the information takes? If the symbol file contains the same graphics, isn't that the same symbol from a graphical point of view? Why do you consider it different? Maybe we're philosophically disagreeing on what a schematic diagram represents. I don't think of them as wiring diagrams, but as signal flow diagrams. They represent topology. That's the *substance* (you cannot deduce signal flow from a schematic without extra knowledge: that's part of the reason DRC doesn't work very well). Now, use the native capabilities of gEDA and your OS to create that substance, rather than fighting them. PCB's job is to turn that into a wiring diagram. Or something like that. Apparently to some, schematics are also wiring diagrams. To me, they're topology. The same schematic imported into projects with different symbol files thus may wind up representing different wiring. That's part of the power of the project symbol approach. A directory full of symbols is a pretty decent database. Cool. So put wiring information into your symbols. All of them. 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 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
On Jun 28, 2009, at 3:11 PM, Stefan Salewski wrote: Currently we (may) have different symbol files for the the same device with different footprints. Not a lot, I think. It's easier to find examples of the same device with different graphics. So we have the same graphics elements multiple times. This is redundancy, wast of storage area, On my little netbook, the whole distributed symbol library takes up ~0.1% of the file system. And I don't think there's really a whole lot of redundancy of the kind you're talking about. and it makes it more work to modify the graphics. In the published symbols, the graphics rarely need modification, I think. So it is not a perfect solution. Nothing's perfect. But is is simple, flexible, and pretty transparent. Those are virtues one should not take for granted. 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
John Doty wrote: Why are you hung up on the form the container of the information takes? If the symbol file contains the same graphics, isn't that the same symbol from a graphical point of view? Why do you consider it different? I guess it's because I'm a control freak. :) I want it to be convenient to dictate that all NAND symbols will look like this, and then if I change my mind, there's just one file to go edit to make them look like something else. That mentality prevents my NAND symbol for a SOT6 chip from looking different from the 74LS00/DIP16 one, because the same symbol data would be used for both. They represent topology. That's the *substance* (you cannot deduce signal flow from a schematic without extra knowledge: that's part of the reason DRC doesn't work very well). Now, use the native capabilities of gEDA and your OS to create that substance, rather than fighting them. I can see your point. Maybe the problem that I'm complaining about is that the standard set of gEDA symbols is just so small, that all those personalized symbols that people are making aren't finding their way back upstream, to prevent others from reinventing them. To me, they're topology. The same schematic imported into projects with different symbol files thus may wind up representing different wiring. That's part of the power of the project symbol approach. A directory full of symbols is a pretty decent database. Agreed. Maybe I'm staying too focused on the small, trivial symbols since those are the ones I have the most current experience with. /me shrugs. 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
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. That's just... wrong. It would be nice if there was an agreed. 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: 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... :) for things like transistors and IC's, I have already implemented exactly this for my own use. I have an ASCII file that associates a complete vendor part number (including package code) with a symbol template, a footprint, and a mapping from symbol pin to footprint pin. Then I have an awk script that reads in the database and produces a set of heavy symbols that have the correct pinout to match the footprint that goes with them. So on my schematic, I see the correct pin number. If I want to change from a part in a 16 pin DIP to a 20 pin PLCC, I pick the new part number with correct package code to instantiate. The awk program is all of 64 lines long if you strip out comment and blank lines. If you keep the whole thing its only 84 lines long. Seems to work like a champ. I've been able to very quickly fill out some familes of parts and transistors are trivial. Plus I no longer worry about the SOT-23 problem (the one where different vendors number the physical pins differently. The place where I'm not so happy is for things like standard resistors. There I really don't want to create a massive pile of heavy symbols. I'd rather have a symbol that points to some callback code (probably in scheme since you'd want it loadable at run time) and it knows that once you pick a tolerance, you get to pick from a predefined list of values and you also get a predefined list of packages. For transistors and IC's, I have no problems with the enumerate them all approach I've taken. -Dan ___ 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
