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 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 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
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: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
On Jun 28, 2009, at 10:26 AM, Bill Gatliff wrote:
> As a "mostly software" guy,
Taking this as you can code some scripts up..
Here is one approach for you to try.
pick a small set of some chips you care about. lets say a large
family of the AVR series.
To the symbol:
Add a virtual pin attribute
Add the pin map file attribute.
example
snippet from a symbol.
T 3000 9800 8 10 1 1 0 6 1
refdes=U?
T 400 9950 8 10 0 0 0 0 1
device=ATmega16
T 400 10150 8 10 0 0 0 0 1
footprint=TQFP44_10
T 400 10400 8 10 0 0 0 0 1
pinmap=ATmega16.fpm
P 2600 100 2600 300 1 0 0
{
T 2650 200 5 8 1 1 0 0 1
pinnumber=?
T 2650 200 5 8 0 1 0 2 1
pinseq=1
T 2600 450 9 8 1 1 0 3 1
pinlabel=Reset
T 2600 600 5 8 0 1 0 3 1
pintype=in
T 2600 850 5 8 0 1 0 3 1
virtualpin=reset
}
snippet from pinmap. oops the examples weren't different.. :-P
so I faked data DON'T make a part with this fakery!
device=ATmega16
footprint=TQFP44_10
{
# virtual pin, footprint pin [, pin type]
reset, 4
xtal2, 7
AD10, 35
..
}
footprint=MLF44
{
# virtual pin, footprint pin[, pin type]
reset, 4
xtal2, 10
..
}
#fake
footprint=TQFP64
{
reset, 6
xtal2, 10
AD10, 35
?, 44, nc # Here pin 44 has no name, and is a no connect pin.
...
}
footprint=PDIP28
{
reset, 2
xtal2, 4
AD10, ?, na# here ADC 10 was ommited from this part to fit it in
the smaller package
...
}
Now with this groundwork you can run a script that will update the
schematic page's symbols with mapped pins.
To do this you will probably need to embed the symbols into the
schematic first. Then map the pin numbers from ? to the real pin
numbers.
We would probably need to add the pintypes of nc for no connect and na
for not available, to allow for parts that have fewer pin packages,
and no connects in larger packages.
Got some code game?
Steve
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
On Jun 28, 2009, at 11:26 AM, Bill Gatliff wrote:
> At the risk of going OT, I'll add that as I get better at following
> the
> above strategy--- which is particularly helpful with more complex
> parts
> like microcontrollers--- I get really frustrated at gschem's strong
> association between pin numbers on the symbol, and pin numbers on the
> footprint.
gEDA has no such strong association. It's a product of the way you
*use* gEDA.
> That's just... wrong. It would be nice if there was an
> additional "layer of abstraction" somewhere between the symbol and
> footprint, such that actual pin assignments weren't made until the
> footprint (and slot, if necessary) were specified. Until that
> point, it
> doesn't really matter anyway.
When first drawing the circuit that needs a low noise opamp, copy one
of the opamp symbol files into your project symbol directory under
the name "low_noise_opamp.sym". Place that. As its pin numbers,
attributes, etc. become clear, edit it ("Hs") to suit. Or replace the
symbol file with something else.
gEDA uses a powerful, hyper flexible association mechanism that other
packages can't match: your computer's file system.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
j...@noqsi.com
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy (was: Re: slotting and power pins)
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
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
