Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
Bert Timmerman wrote: > got cvs co working > Simply typing make barfs the following: > [snipped] Your OS is too modern. Install something that is at least 25 years obsolete and try again. 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 K&R 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 05:44 +, Michael Sokolov wrote: > Bert Timmerman 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 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: [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]$ 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 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 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
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 wrote: > > 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 is required. Kind regards, Bert Timmerman. [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) ___ 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 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: cylindrical SMT power resistor pad design: how to do a semi-circular cutout
On Sun, 28 Jun 2009 13:42:53 -0700, Steven Michalske wrote: > happy footprinting.You might want to make a script to calculate out > the semi circle points. If it is a one-shot, you might consider the GUI way: inkscape --> draw with real semicircle circle --> save as eps (uncheck "make bounding box around page") pstoedit -f pcb > footprint.pcb pcb --> File - load-layout-data-to-buffer --> edit to your needs (lines only, no polygons) --> select the buch of lines --> copy to buffer ( ctrl-c ) --> Buffer - convert-buffer-to-element --> Buffer - save-buffer-elements-to-file editor --> add the same pin number to all the little line snippets with search and replace ---<(kaimartin)>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=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
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
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
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
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: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 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
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 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 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
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
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
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: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
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
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 (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
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
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
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
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
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
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: cylindrical SMT power resistor pad design: how to do a semi-circular cutout
On Jun 27, 2009, at 4:26 AM, S. Aguinaga wrote: Do you fellows have some pointers for me to generate the semi-circular cut out? You will need to generate the semi circle with many small rectangles. Their recommended footprint looks like it is generated with 7 rectangles. <> If you make a pad with all of these rectangles with the same pad name they will be one pad, if you don't PCB will complain that the pads are shorted. If you want a semi circle you probably will need 20 segments or so, this one uses 5. now with outlines. the black semi circle is approximated by the inside rectangles, there are gaps and excesses, but you can see that you get your approximation, and on the scale your working on this is good enough, as shown in your data sheet. This footprint looks like it is designed to keep the part aligned with surface tension during reflow soldering <> happy footprinting.You might want to make a script to calculate out the semi circle points. 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)
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
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: slotting and power pins
Stefan Salewski wrote: > On Sun, 2009-06-28 at 09:18 -0700, Dave N6NZ wrote: >> Yes. IMHO, power pins clutter functional drawings. I like to isolate >> functional I/O from infrastructure I/O using two different symbols so >> that they can be placed on different sheets. > [...] >> I believe this style leads to the most readable schematics, and scales >> up well to larger designs. >> > > Please note this is not always true. > Power pins can be very important for functionality. I.E many different > supply voltages or filtering of supply for analog parts or routing of > supply. You give a great example for making my case. The more complex and/or important power is, the more important that it is on it's own symbol. If power management, filtering, etc, gets complex, it clearly deserves it's own sheet and should be logically separated from signal-path functionality. -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
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: slotting and power pins
> This can only fix the special case of slotted symbols with power pins. > However, the more general case that needs to be solved, is a component > that is associated with several different symbols. This is the case if > power pins are dealt with a separate symbol, or if a large component is > divided into several building blocks. I wonder if slotdef could point towards a symbol So, slotdef = 2:fpga_bank1.sym, etc. Although I think this has the potential to become very messy. ___ 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 (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: slotting and power pins
On Sun, 2009-06-28 at 09:18 -0700, Dave N6NZ wrote: > > Yes. IMHO, power pins clutter functional drawings. I like to isolate > functional I/O from infrastructure I/O using two different symbols so > that they can be placed on different sheets. [...] > > I believe this style leads to the most readable schematics, and scales > up well to larger designs. > Please note this is not always true. Power pins can be very important for functionality. I.E many different supply voltages or filtering of supply for analog parts or routing of supply. We need better support for multi-component symbols, but we need better support for visible/hidden power pins (of slotted symbols) too. Maybe a switch which can hide the pins. (And we need support for parts with multiple power pins -- some fast OpAmps have 4 pins for VCC and 4 for VEE -- internally connected.) ___ 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: slotting and power pins
Duncan Drennan wrote: > Currently the symbol slotting functionality struggles to handle power > pins well (at least that is what some brief googling showed). A > recurring theme with regards to slotting is that power pins show up on > all the slots, e.g. dual/quad opamp which has a single set of power > pins for each of the opamps - if the power pins are visible and not > embedded they show up on each slot. > > Some people have a problem with this from a "style" perspective Yes. IMHO, power pins clutter functional drawings. I like to isolate functional I/O from infrastructure I/O using two different symbols so that they can be placed on different sheets. That way, the functional symbol is used on the functional pages and the power supply isn't cluttering the functional drawing with extraneous confusing lines. On a small design, all the power supply connectivity often fits on a one or two sheets. So, for instance, take a 74xx00 part... I would have two symbols, the functional symbol has two logic inputs and one logic output, and slots very cleanly. The infrastructure symbol has two inputs, power and ground, and doesn't need to be slotted. I believe this style leads to the most readable schematics, and scales up well to larger designs. -dave ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: slotting and power pins
On Sun, 28 Jun 2009 15:32:14 +0200, Duncan Drennan wrote: > I had a thought which might solve both of these issues. If a special > character was defined for slotting which indicated that the pin should > be excluded from the schematic that character could be used in place of > the power pin slot. This can only fix the special case of slotted symbols with power pins. However, the more general case that needs to be solved, is a component that is associated with several different symbols. This is the case if power pins are dealt with a separate symbol, or if a large component is divided into several building blocks. With such multi-part symbol components order in the *.sch file is important. gnetlist only gets the footprint right if the footprint attribute is attached to the symbol of the component. Since the user usually has no control on the order in the file, this can lead to unexpected results. ---<(kaimartin)>--- -- Kai-Martin Knaak Öffentlicher PGP-Schlüssel: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: slotting and power pins
Currently the symbol slotting functionality struggles to handle power pins well (at least that is what some brief googling showed). A recurring theme with regards to slotting is that power pins show up on all the slots, e.g. dual/quad opamp which has a single set of power pins for each of the opamps - if the power pins are visible and not embedded they show up on each slot. Some people have a problem with this from a "style" perspective (it is visually different to other CAD packages). A slightly more important issue is that if the pins are left unconnected (for more readable schematics) it messes with the DRC checking, which expects all pins to be connected (and possibly with the netlister?). I had a thought which might solve both of these issues. If a special character was defined for slotting which indicated that the pin should be excluded from the schematic that character could be used in place of the power pin slot. So for a dual opamp with slots defined slotdef = 1:3,2,8,4,1 slotdef = 2:5,6,8,4,7 it would become slotdef = 1:3,2,8,4,1 slotdef = 2:5,6,N,N,7 if 'N' was the special character. The 'N' pins would then be ignored by the rendered, DRC, netlister, etc. Maybe even just slotdef = 2:5,6,,,7 would work too. Maybe this has already been done? I have absolutely no idea how the internals work for rendering the symbol and passing the info to the DRC and netlister. Just thought I'd share the idea in case anyone is interested. Regards, Duncan -- Turn ideas into products - http://www.engineersimplicity.com The Art of Engineering - http://blog.engineersimplicity.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: sdram board update
Just re-etched the outer layers. The last time, the traces ended up too thin and many of them etched through, yet other parts of the board had shorts. Go figure. After some testing, I got a setup that works (note that PNG has a "bloat" setting now too ;-). Results at the bottom of http://www.delorie.com/electronics/sdram/ So far, I've found only one defect - an easily repaired break in one of the traces on the MCU side. Yes, all those 6/6 serpentines etched correctly :-) Some close ups here: http://www.delorie.com/pcb/lab/ You can also see the results of a custom HID I wrote that sits between PCB and the PNG exporter. It checks connectivity on each of the four layers and adjusts the via patterns accordingly. For example, if I'm connecting layers 1 and 3, layer 2 has no copper and layer 4 has a target that means "drill out completely". If I'm connecting 1 and 2, layer 1 has an oval drill that means "drill bigger", layer 2 has no drill, and layers 3 and 4 have no copper. I'll pre-drill the outer layers, adhere the layers together, then drill all the through holes. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
