Re: gEDA-user: blue sky ideas - written down finally
Steven Michalske wrote: >> >>> [(A,B),Y]=[1,2,3], [4,5,6], [9,10,8], [12,13,11] >>> >>> I think that this simplified down to the required parts. >>> >> I suppose some of the syntax can be defined as "optional" and implied, >> if we can guarantee that it's deterministic. >> >> I can imagine cases where pins can be swapped on some of the gates, >> but not all, for example an FPGA where some pins are input only, or an >> MCU where some UARTs are less configurable than others. Let's define >> the swappability as a property of the chip, not the symbol, so parens >> on the left are migrated to the corresponding pins on the right - then >> if you have parens only on the right, you have the ability to define >> swappability on a per-gate basis. I.e. your example is changed to >> this internally: >> >> [A,B,Y]=[(1,2),3], [(4,5),6], [(9,10),8], [(12,13),11] >> Some software I have worked with (not EDA) uses a "compatible="-type syntax for such things. It can get kind of verbose when you have a really generic symbol that's compatible with pretty much everything, but that's what computers are for: slogging through all the grunt work. :) In this specific situation, you can't think just about swapping two pins, you have to be much more generic. In a microcontroller, for example, you might have whole banks of functionality that can move between groups of pins numbering to a dozen or so. If the syntax won't accommodate that, it's an opportunity lost. > A package is a footprint and a mapping, how will you cope with parts > with the same footprint and different pinouts? These parts exist, but > I don't have a particular example on the top of my head > That's similar to the "transistor problem", if not exactly it. The "pin numbers" on a symbol cannot be mapped directly to footprint pin numbers, except through a table of some kind. So the pin numbers on symbols cannot be actual pin numbers at all, as I mentioned in my post on this topic a month or two ago. 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: "Analog" books
Michael Kaalund wrote: >Hi Karl > >There is also this book, there is 6 >lesson [1]http://openbookproject.net//electricCircuits/ > >Hopes it helps > >Best regards > >Michael Kaalund > > References > >1. http://openbookproject.net//electricCircuits/ > Quick OT question about the format of this email, which I see used a lot on this list. Are you using an automated email filter to generate these references, or do you do it by hand? If the former, what is the name of the software? Thanks! 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: How to deal with single/dual parts?
Guys: I'd like to apologize on the record for this whole thread. It was a very simple question, after all. I had no idea. :) 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: Switch gschem to another scripting language?
Dave McGuire wrote: > >Scheme has been around for 35 years, and Lisp has been around for > more than half a century. Will Python, as nice as it is, really be > around in five decades? Three? I doubt it. And for the sake of the > overall health of the computer science world, I sure hope Perl isn't. > Another upside to Scheme/Lisp is that the interpreters are very low in complexity. So it's probably easier to incorporate those languages into a program that needs scripting than, say, Perl or Python. As I see it, the problem isn't with Scheme. It looks like the problem is that you can't get at the data you need to do really interesting things with Scheme in the rest of the gEDA tools, gschem in particular. That problem would probably still be there if you merely switched to Perl, Python, or whatever. But then again, I haven't tried to use any of gEDA's "scripting features". I'm currently just a point-and-grunt monkey. 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: Ideas for fixing slotting, methodology discussion, NOT implementation details!
Stefan Salewski wrote:
> On Fri, 2009-11-20 at 18:39 -0800, Steven Michalske wrote:
>
>
>> Specify what power domains are required for the part.
>> - e.g. level shifters and pins to power domains
>> - e.g. in a 3.3V and 5V system, which voltage is this symbol on
>> Specify what clock domain a symbol is in
>> - e.g. you can't move some parts across clock domains in VLSI
>>
>>
>
> A more general solution may be to specify Dev:Slot:Pin for each pin in a
> packages. I think I have seen this somewhere long time ago...
> Pins with same letter can be exchanged for each slot. Slots with same
> letter can be exchanged. If two devices have the same Dev-String slots
> can be exchanged between them.
>
> Dev:Slot:Pin
>
>
> X1 X2 X1 X2
> _|__|_ _|__|_
> \ A1 / \ A2 /
> \ / \ /
> \/ \/
>||
>Y1 Y1
>
>
> Dev:Two_Input_Nand_Gate_CMOS_3.3V
> Slot{X1,X2,Y1}:A1,A2
>
I like something a little more self-documenting, like the attribute=
format we're using today.
Also, if we constrain pin names then we can't make them match the
datasheets that are associated with the symbol's component-circuit.
Maybe we need a separate attribute that explains which pins are
interchangeable.
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: Ideas for fixing slotting, methodology discussion, NOT implementation details!
Stefan Salewski wrote: > > For the symbols: I think they should define text boxes (coordinates) for > refdes, name, value -- content may vary, but position is important for > visual appearance. > Yes. > Maybe one symbol file should be allowed to contain multiple graphics, > i.e. for -\/\/\- and -|===|- type of resistor symbol, for horizontal and > vertical symbols with aligned text boxes and for various sizes of the > same symbol. > PNG? SVG? Oh, and just because we're talking about multiple "files" here doesn't mean that implementation detail has to be exposed to the user. Our output file format could be CPIO or tar, so that gschem sees multiple input files (all still in a text format, of course), but they can be bundled together into a single file for convenience and configuration management. 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: Ideas for fixing slotting, methodology discussion, NOT implementation details!
Steven Michalske wrote: >In the lines of the one mans upsmanship >The extra data need not be a separate file, a table element in the >schematic may meet the needs. > It certainly could, but it might work against the expressed desires for having the same schematic serve for more than one fabrication. 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: Ideas for fixing slotting, methodology discussion, NOT implementation details!
Dave N6NZ wrote: > Ideally, I'd like to be able to use the same symbol for a through-hole > 20 pin part or the 24 pin SMD part and back-annotate the correct pin > numbers onto the schematic when the part is assigned. (I do that now > with two symbols that have identical pin out so that cut/paste sort of > gets me by, minus losing some attributes). Also, I'd like to do slot > and pin swapping during PCB layout and back-annotate the "as fabbed" pin > numbers back onto the schematic. > I'll go you one better. I want to draw discrete resistor symbols in my schematic diagram, and then during component selection satisfy their requirements from the circuits provided by a resistor network. I also want to draw discrete LED symbols in my schematic, and fabricate using dual- or triple-LED packages. Ditto for capacitors, transistors, etc. My thinking is that alongside the .sch file will be one or more additional files that collectively record the mapping between symbols, circuits, components and packages. When gschem sees that file, it has the information it needs to show actual pin numbers and will optionally do so. To achieve that, I bet we end up building some kind of in-memory database that we don't have today. 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: Ideas for fixing slotting, methodology discussion, NOT implementation details!
Steven Michalske wrote: > What do we need to define? > I will logically split a symbol and a component now, but we shouldn't > make the assumption that the will be split in the final implementation. > I don't think we'll be happy with things if we don't keep them logically split, since they are in fact two conceptually different entities. Mixing them is how we ended up with slots, at least from my perspective. > In a symbol: > Specify what part of a slot(s) this symbol represents/requires. > Specify what parts of a particular slot can be interchanged, e.g. pin > swapping > Specify what power domains are required for the part. > - e.g. level shifters and pins to power domains > - e.g. in a 3.3V and 5V system, which voltage is this symbol on > Specify what clock domain a symbol is in > - e.g. you can't move some parts across clock domains in VLSI > Ok, now I'm completely lost. :) A symbol is an abstract entity that expresses a requirement for a circuit. The symbol itself name can't match the circuit name, because I can see the likelihood that differently-named symbols might represent the same circuit (different ways to draw a NAND gate, for example). So maybe the symbol name is arbitrary, but each symbol must have a circuit= attribute that identifies the circuit that the symbol represents. (If it doesn't have this attribute, then it must be a graphical element and we can ignore it). The pin names for symbols live in their own namespace, and in fact need not be numeric. They can't be mapped to a pin number on a component package until you know which circuit of which component the symbol represents. That symbol-circuit-component association is roughly equivalent to what we're calling a "slot" today--- but I propose we deprecate that term altogether. I also think that symbol pin names shouldn't be numeric, so that they can't be confused with package pin names. Apart from a circuit= attribute and a unique identifier for each symbol instance, I can't think of any mandatory attributes that symbols would require. Additional attributes could capture the domain and other information you mention. As for pin swapping, I assume you are referring to two-terminal devices like resistors and nonpolarized capacitors. No ideas on how to deal with that. > In a component > Specify what slots this component provides. > No. A component merely provides a collection of named circuits. Those circuit names match the circuit= attributes that symbols use, and circuit pin names map to symbol pin names once you know which circuit a symbol is associated with. But the symbol and circuit pin names are not package pin numbers yet, and the circuit pin names probably shouldn't be numeric for that reason. Finally, for each package that a component is available in, you have to provide information that maps the pins of the component's circuit to package pins. I don't yet know what the best way to handle this information is, but your idea of components being named with a manufacturer's base part number and then the packages identified by suffixes seems at the outset to be a pretty good one. 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: How to deal with single/dual parts?
Stuart Brorson wrote: >> Would it make any sense to attempt to use Dia as an alternative gschem? >> > > Sorry to come out of hibernation just to rant. > > I've used dia many times over the years. It stinks to high heaven. Ok, I'll put you down as "not in favor of Dia". :) I fired up Dia for the first time in a long while just this morning, and it's still the same tool as it was several years ago. So I'm inclined to agree with you. It occurred to me just because it has a well-defined scripting backend that the tool itself makes extensive use of. That's all. > Gschem is light years ahead of dia. Gschem has been under development > for over 10 years and is very easy to use, IMO, once you learn the > keystrokes. The recent complaints I have seen on this list about > gschem seem to stem from the fact that it is simply a drawing program > without knoweldge of electronic concepts like "net", "component" and > so on. That is, gschem's basic datastructures are things like "lines", > "circles", "text", and so on. In the current architecture, it's up to > gnetlist to read the graphical rendition of the circuit, add in the > circuit knowledge, and create a netlist. > I know nothing of the internals of gschem. But Dia appears to treat its visual symbol objects as _objects_, and the scripting language works with them at that level (similar to how Visio works, which I am very familiar with). I don't think that gschem needs any awareness of electronic components--- in fact, I think that would be a Bad Idea. Rather, it might be easier to do some of what I'm thinking is necessary by allowing gschem to understand drawings in the same way that Dia does: as a network of interconnected symbols (a "net" is a form of symbol in my way of thinking), each of which may have one or more attributes associated with it that gschem merely has to provide to the scripting backend. Gschem may in fact work this way, for all I know. Maybe if things worked the way I describe, then backends could be produced to deal with the circuit-specific knowledge--- matching symbols with circuits provided by components, for example. > However, there is a large installed base of scheme Is there? Could we get a show of hands as to who is doing a significant quantity of scheme programming in their use of gEDA? Stuff that might get broken of gschem switched to another scripting language, I mean. 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: How to deal with single/dual parts?
Would it make any sense to attempt to use Dia as an alternative gschem? Obviously, there would need to be a lot of shape and script development, but it sure looks like the basic machinery that we need from gschem is there already. And as a bonus, Dia uses Python as its backend scripting language. Only downside is, it doesn't appear that Dia out-of-the-box lets you add arbitrary attributes to symbol instances. Only the ones defined by the upstream shape are available for modification. (Not sure this is entirely a bad thing, tho). 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: How to deal with single/dual parts?
Stephan Boettcher wrote: > Remotely related to this topic, I had this idea: > > Often, there are several choices for footprint, model, whatever > attribute that need to to chosen at some point in the flow. We have proposals > for a kind of database to support the options. > I envision a directory hiearchy of symbol definition, component definition, and footprint definition files, and the tool sweeps them at startup and then builds an in-memory database with sqlite to manage them at runtime. Or something like that. Keeping the data primitives separated until the last minute would make external scripting easier and more consistent, I think, especially if we offered a set of libraries to help with the common activities like understanding relationships between symbols, components, packages and footprints that all the various tools in a workflow (and custom workflows) could share. 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: How to deal with single/dual parts?
Peter TB Brett wrote: > The gschem/libgeda Scheme API: > > - Is completely inconsistent in naming and calling pattern. > > - Has no useful documentation. > > - Lacks the ability to do meaningful manipulation of schematics/symbols. > > - Fails dismally at coping with having multiple schematics/symbols open at > once. > > - Barely deserves to be described as an "API". > I know we're all pretty attached to gschem. I know I am! But, in the interest of brainstorming, is there another scriptable drawing tool that we could adopt as an alternative? Something like a GPL Visio-ish program that already knows how to do the visualization pretty well that we could co-opt so we could focus on the backend? If I were inventing one from scratch, the frontend would be just about visualization e.g. Visio, and then a boatload of backend plugins (written in Python, Scheme, or some other language I also don't know) would deal with the specific meanings in the context of schematic capture. But *man*, this kind of visualization is such a solved problem, it really feels like we're reinventing the wheel with gschem... > [1] I'm a grad student, and my time is relatively inexpensive. > Hmmm. I could kick in a few bucks next year. Google Summer of Code, perhaps? 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: How to deal with single/dual parts?
Dan McMahill wrote: > and this is exactly why the small library I have defines the component > in a simple ascii database and then awk reads that data and combines a > symbol template with a footprint and produces a .sym file that has the > footprint set along with the pin out. Wouldn't be too terribly hard to > do something similar for a different flow. > Yea, but I like the idea of having gschem do that merging on-the-fly if possible. That way, if I want a better NAND symbol then I don't have to repeat some kind of build process to generate the derivative, heavy symbol--- and I don't have the configuration management headache of tools depending on downstream build products rather than the upstream sources themselves. 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: How to deal with single/dual parts?
Greg Cunningham wrote: > > What would be nice here is a loose coupling between symbol and device to > the extent that symbols could be dynamically assigned to devices. Maybe > there could be a 'devices' panel (maybe even the assigned list from the > library). Each device in the panel exposes its used and available > slots. The designer can form a symbol-device association by dragging > the symbol onto a suitable device in the device panel to 'assign' the > symbol to an available slot. The drop fails if the symbol doesn't fit > the device, or if all slots for that symbol are taken. Also, I could > merely drag the symbol out of one devices slot and drop it in another > device that gives me better routing efficiency. > That sounds like another "me, too!" vote. :) For purposes of this thread of discussion, can we drop the term "slot"? It seems more helpful (at least to me) to think of chips as collections of circuits. The term "slot" is not well-defined for us right now... Based on Greg's comment, it sounds like we're pretty close to understanding as a group how we might re-factor our definitions of symbols, components, circuits, packages and footprints. I hardly think we're ready to think about how to implement it in a GUI, but he offers one suggestion and it doesn't sound too bad. I have some ideas of my own, but I'm still trying to come up with a mental model for how to deal with the data itself! OT, but wouldn't it be kind of cool if gschem's output could be fed into graphviz? :) But seriously, that tool offers fertile ground for ideas... 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: How to deal with single/dual parts?
Henry Von Bank wrote: >What I would propose would be to leave the slotting behavior alone for >the time being (option a), but hopefully mark it for deprecation in >some future version, as it can be confusing and is not well defined. > We could actually leave it alone almost indefinitely, because if the symbol doesn't do anything with slotting then the gaf tools don't care. And the symbols I envision wouldn't do anything with slotting. In fact, most of what I've been brainstorming on could be achieved with the existing tools as-is, plus some plugins and scripts. The future work would be to take the concept and make it less user-input-intensive, like have gschem show pin numbers and reference designators on some versions of the schematic, even though that information is not really part of a schematic as I define 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: How to deal with single/dual parts?
Kai-Martin Knaak wrote: > > > The two other EDA suites I worked (eagle and protel) with maintain the > notion of a "component" that contains all the info. In a way, this is a > very heavy symbol that knows about slots, possible footprints and which > schematic symbols are necessary to represent a complete component. > They carry the symbol along with the component though, right? So if the system doesn't know about a component in advance, it won't offer you a symbol. That's not what I want. I want the concepts of symbols and components to be completely separate, tied together only by meta-information that says "this circuit can be represented by this symbol", and "this component contains these circuits". 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: How to deal with single/dual parts?
Peter Clifton wrote: > Lets say I have a symbol: > > ---|\ > ---|/ > > > That might have 4 slots - IE.. I expect 4 of those nand gates in the > chip. > ... and I think that might be where the problem suddenly creeps in. The _component_ defines how many and what kinds of circuits it contains. It also defines what packages the component is available in, and how to map the pins of its composing circuits to the pins on the package. The _symbol_, on the other hand, just expresses the designer's _requirement_ for a circuit. The symbol itself doesn't care which _component_ satisfies that requirement, it's the developer's job to at some point identify which circuit of which component will satisfy that requirement. To give a concrete example, let's say my schematic diagram contains three nand symbols, which specifies a requirement for three nand circuits. Some other document would record that I will provide two 74ls00 components, which supplies the design with a bucket of eight nand circuits plus two power circuits. A tool that tries to correlate the two documents can detect that my requirements are being over-supplied, which means that my schematic diagram is missing symbols that correspond to the actual number of circuits I'm providing. Better fix that, because some of those circuits are the power supplies for the components and the other circuits won't work without them! I add the appropriate symbols to my schematic diagram until everything balances. So then I change my mind, and provide just one 74ls00 component. The same tool can detect that now there's an imbalance in the other direction, meaning that I need to get rid of one of the power symbols and a few of the unused nand symbols that I added previously. But otherwise, the schematic diagram is the same as it was before--- as I think it should be. Now I'm beginning to see the problems with slotting and symbols the way we're doing them now: they unnecessarily tie the concept of a symbol to the concept of a component, because the pin numbers that we currently record in our symbols are also the pin numbers that the component maps to the pins of the component's package. We have munged together the concepts of symbol and component in our "symbol" files, but can't seem to admit to that. That's the breakage, methinks. 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: How to deal with single/dual parts?
Peter TB Brett wrote: > And, furthermore, if I/we fixed it to work as designed, some users would be > up in arms -- because they have been using the mechanism in a way contrary > to its design, and fixing it to work as designed has broken their > schematics. > During the transition between the current state and the new, fixed version--- yes. But they also have the option of forking pre-fix or waiting around until things stabilize. > Note that this same point applies to several other aspects of gEDA. If, > when users state that they are taking advantage of bugs, we do not point > out that they *are* bugs and encourage them not to, then we lose the > ability to fix those bugs. Down that path lies Windows^Wmadness. > We don't lose the ability to fix those bugs. They lose the ability to continue exploiting those bugs. Another major point of Free Software is that if the users don't like the way things are developing, they have the option of taking their copy and going in another direction. I don't think we should focus on backward compatibility at the expense of forward progress. I say, break 'em. They have been warned. :) 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: How to deal with single/dual parts?
Peter Clifton wrote: > On Wed, 2009-11-18 at 14:31 -0600, Bill Gatliff wrote: > >> Steven Michalske wrote: >> > > >> * a schematic "symbol" represents some or all of a "component" >> * a "component" might satisfy the functionality indicated by more than >> one symbol >> * a "component" comes in one or more "footprints" >> > You're clearly thinking of PCB layout _^ > Yea, well :) > I would call any non-graphical entity a "circuit" with "Mports" (a > gnetman term). Symbols either represent sub-circuits defined logically > by more schematics, or instantiations of physical devices, VHDL > primitives, VHDL code, > > "Symbols" are a graphical representation of "circuits", such as to be > able to connect instances of those circuits using schematics. > I like this concept. The idea of a symbol actually being a circuit is so obvious, I'm ashamed it hadn't occurred to me before now. > NB: I don't just see gEDA useful for schematics / VHDL / IC design > though.. I draw all kinds of logical diagrams with it. Some make sense > represented as a hierarchy. > Indeed. And the converse is also true: gschem is really just a "smart diagrammer", somewhat like Visio used to be. If we could think along those functional primitives, maybe it would be easier to combine them to build up something that's on the one hand easy for beginners to grok and at the same time powerful enough for advanced use cases. Without us having to reinvent the wheel. 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: How to deal with single/dual parts?
Bill Gatliff wrote: > * a schematic "symbol" represents some or all of a "component" > * a "component" might satisfy the functionality indicated by more than > one symbol > * a "component" comes in one or more "footprints" > * "footprints" are used by more than one component > * schematic hierarchy symbols are just collections of "symbols" > More brainstorming. Looking at things from a different direction, a component "provides" one or more symbols depending on the component. Some of those symbols might meet a "requirement" described in a schematic diagram, in which case you can check both symbols off. Making a component selection means that _all_ the symbols come into your design, however, and if you forgot to deal with the power pins then they'll look like symbols with floating pins if you represent them in a schematic diagram. A symbol is just a graphical entity, and each one that appears in a schematic diagram defines a requirement that must be satisfied by a component. A symbol: two-input-nand.symbol: "symbol=two-input-nand" "input=A" "input=B" "output=C" (verbage to describe what the symbol looks like on the screen) A component supplies symbol instances to a design described by a schematic. They also have to provide enough information to associate the symbol's "pins" to pins on a footprint. Each time you specify a component, ALL of the component's symbols become a part of the machine-generated version of your schematic diagram: sn74x2x00.component: "component=sn74lvc2g00" "component=sn74lv2g00" "component=sn74act2g00" "symbol1=two-input-nand A:A1 B:B1 C:C1" "symbol2=two-input-nand A:A2 B:B2 C:C2" "symbol3=two-input-nand-power V:VCC G:GND" "footprint=soic8 A1:1 B1:2 C1:3 A2:4 B2:5 C2:6 VCC:7 GND:8" "footprint=dip8 A1:1 B1:2 C1:3 A2:4 B2:5 C2:6 VCC:8 GND:7" # swap VCC and GND pins, just for fun A "footprint" describes the physical layout of a footprint, along with information to map virtual component pins to physical pin locations: soic8.footprint: "footprint=soic8" (text that describes the physical footprint itself, and enumerates each pin) A schematic diagram would be just line after line of something like this: symbol=two-input-nand id=EA89-ab32-ifj2-ee89 # machine-generated, unique (uuid?) x=1 y=2 (other stuff to describe wires, etc.) symbol=two-input-nand id=2aef-789j-ie87-po73 x=100 y=200 (...) Now things get tricky. We want to tell the tool what chips we're going to use, and in some cases which "slot" of the component is utilized by a corresponding symbol. Ultimately, you'd produce a file that looks like this: component=sn74lcv2g00 refdes=U1 footprint=soic8 id.1=EA89-ab32-ifj2-ee89 id.2=2aef-789j-ie87-po73 The above says: * We have a sn74lvc2g00 with reference designator U1 and footprint "soic8" * U1's symbol1 is taken by the schematic symbol with id=2 * U1's symbol2 is taken by the schematic symbol with id=1 * Nobody took U1's symbol3 (now that they know the chip, they need to wire up the power) You'd feed your schematic file, component files and component list file to a tool that would correlate schematic symbols with component symbols, making sure that the tally for each was the same. If the two didn't balance, it would kick out a meta-schematic file with the unused symbols and then complain. Now you go wire up your power pins. Once the symbols and components balanced, a tool could take the above files and produce the same information that comes out of gsch2pcb today, methinks. In the above, I'm not proposing that we change the syntax of any of the existing gaf files. I'm just trying to describe the information itself. 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: How to deal with single/dual parts?
John Doty wrote:
> Let's not say "change the workflow". There are many workflows. Pin
> numbers and packages are already irrelevant to some.
>
Well, let's say "change MY workflow". :)
> Have a tool that translates schematics without pin numbers to
> schematics with them.
>
Actually, I kind of like the idea of something like a netlist file that
sits alongside the sch file. Maybe a script can meld them together for
current versions of gschem, but maybe future versions would not require
that.
> Well, I wouldn't want to have a backwards data flow that mucks with
> my source schematics. But having the tool output .sch format means
> you can print the version with pin numbers for documentation. I
> wouldn't edit such schematics. But you could if that's what you want.
>
Right. Like I said above, having a netlist-type file ("pinlist"?) as an
artifact of the workflow would be better.
> You can't select an opamp without knowing its requirements, and it's
> hard to know those without the schematic.
>
True. So when it comes time to select the actual component and
footprint, you'll pick one based on what the schematic and other
requirements say you need. That component-footprint selection then
would then stipulate a certain pin assignment or choice of assignments
if it was a multi-opamp part.
>
>> I don't really care that I chose a chip
>> with four NAND gates rather than four single-chip ones, the logical
>> signal flow is the same in both cases. But that change often requires
>> that I physically change from one symbol to another in gschem, even
>> when
>> the visual representations are identical.
>>
>> Of course, you have to deal with making sure that the four-gate
>> chip has
>> a decoupling capacitor vs. four caps for the four-chip solution, and a
>> convenient way to note that is on some power-related pages attached to
>> your schematic diagram.
>>
>
> A specialized tool to autogenerate such pages would be useful, too.
> But such functionality does not belong in gschem itself.
>
Agreed.
In a way, a schematic diagram is also an incomplete "requirements"
document, in that once you start selecting components, you might create
additional requirements for new decoupling capacitors and nets to
connect power pins together. But at a minimum, the layout has to
deliver at least the required functionality described in the schematic
diagram.
Ooh, that sounded like a layer of abstraction with some additional
indirection thrown in for good measure. Maybe I need to re-caffeinate. :)
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: How to deal with single/dual parts?
Steven Michalske wrote: > Your suggestion sounds like an implementation I would call a logical > hierarchy > > ( A hierarchy could be one level deep, and flat in the first place. ) > > workflow > logical hierarchy ---implement---> physical hierarchy ---flatten?---> > physical flat design. > > Then the physical flat design gets plumbed through the various other > workflows. > > The implement step could have things like > - The connector script I have seen flowing around, that makes tables > of nets and pins into a connector. > - A generic R and C converter ( a very simple light to heavy converter ) > - A light to heavy converter, connected to a parts database. > - Many other tools that can add the metadata of a design > Yea, I think I'm beginning to see that. Time for some brainstorming... * a schematic "symbol" represents some or all of a "component" * a "component" might satisfy the functionality indicated by more than one symbol * a "component" comes in one or more "footprints" * "footprints" are used by more than one component * schematic hierarchy symbols are just collections of "symbols" Man, the scripts to make all the above work just sound like a connect-the-dots type of exercise. But the computer scientist that isn't in me just isn't jumping up and down going "oooh, I know! I know!!" just yet. :) The good news is, perhaps, that implementing a workflow based on the above should be possible with the current gaf tools. It's really just an exercise in not using functionality in the existing tools that are trying to implement certain cases of the above already. Does any of this sound familiar to anyone? Solved problem anywhere we can look to for inspiration? 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: How to deal with single/dual parts?
Stephan Boettcher wrote: > I'd not call that abuse. The current sloting mechanism allows to change > pin numpers on a drawn component to switch to a different instance of the > component inside the same package. > > We also call for changing pin numbers when we replace one package type > with another. What is so bad proposing to generalize the existing > mechanism to cover both cases cleanly, instead of implementing another > mechanisem that does almost the same? > Not sure if this question is related, but... Why not change the workflow so that during schematic capture, there are no pin numbers anywhere? "Pins" on symbols get assigned a physical pin number during some some later step, at the same time that footprints are selected. And then a backwards data flow brings the pin assignments back to gschem for display? Of course, I really have little idea of the implications of what I'm saying... :) It has never made sense to me to do pin assignments during schematic capture. At that point, all I'm interested in is the signal flow through the symbols--- the pin assignments aren't a necessity until layout, and are subject to change during layout in ways that don't really affect the schematic. I don't really care that I chose a chip with four NAND gates rather than four single-chip ones, the logical signal flow is the same in both cases. But that change often requires that I physically change from one symbol to another in gschem, even when the visual representations are identical. Of course, you have to deal with making sure that the four-gate chip has a decoupling capacitor vs. four caps for the four-chip solution, and a convenient way to note that is on some power-related pages attached to your schematic diagram. But I find that almost everyone puts those on their own pages, so that they don't "pollute" the rest of their schematic. That suggests to me that other people view schematic diagrams as logical entities too, at least except for those power-related pages. Because of what I view the schematic capture process as being, stuff like slotting and footprint= don't really fit in with my mental model of what schematic symbols are. As I see it, those concepts exist only because we're trying trying to force part of the layout process upstream into schematic capture. I don't know how to fix the problem, but I think that's what it is. Obviously, you can't eliminate pin numbers altogether in a schematic diagram. How would I know where to put my oscilloscope probe? :) But a schematic diagram that features pin numbers is a subtly different document from one that doesn't--- it contains "markup" recording decisions made during layout. Just my $0.02. 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
gEDA-user: How to deal with single/dual parts?
Guys: I can get TI's LittleLogic NAND gates in single (SN74LVC1G00) and dual (SN74LVC2G00) varieties. At the schematic level, however, I'd prefer to just have a NAND symbol and a separate symbol for the power pins. One way to solve this problem is to have a symbol named sn74lvc1g00.sym for the single-gate case, and sn74lvc2g00-1.sym and sn74lvc2g00-2.sym for the two gates of the dual-gate part. Then just pick--- and re-pick--- the right one as I sort things out at layout time. (Add one symbol each for the power pins). At the moment, I really don't want to deal with much back-end scripting to make selection more automated. And the slotting feature has left a bad taste in my mouth in the past due to errors in the symbol. Given all that, is the three-symbol approach described above the most straightforward way to deal with my situation? Or am I missing something obvious? 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: symbol files
Kelvin Gardiner wrote: > Try to add something into current format. Why not a new symbol attribute containing a comma-separated list of alternate symbol files for the current symbol? If that attribute isn't found, then the GUI continues to work like it does today; if the attribute is there, then we come up with some way to indicate via the GUI that "there are two other symbols for this part that you might be interested in...". Presumably, each symbol file that contained this attribute would also contain footprint information for that symbol. If a symbol was compatible with more than one footprint as-is, then we could use another attribute to provide a comma-separated list of footprint options. Based on what (little) I know about gaf, the above approach seems to be minimally-invasive. 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: gEDA and pcb status and minigration from Eagle
Kai-Martin Knaak wrote: >> Just don't want to ride a dead horse and notice later that the projects >> freeze >> > > No way. There way too many independent core developers. Even if they all > were to quit coding, I am sure some power users would carry on the flag. > Some users already did forks for their own purpose... > Indeed. Given the proprietary nature of Eagle, you'd be far more screwed if they decided to kill the software than gEDA. I started out on Eagle, but quickly switched to gEDA because of their open file formats, and have never looked back. 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: symbol files
Peter TB Brett wrote: > On Thursday 12 November 2009 19:56:25 Kelvin Gardiner wrote: > >> Having a quick look at a symbol file it seems there is no way to define >> different pin positions and order for different packages. Which is what >> Peter implied in his reply. >> > > Correct. > > >> Is there any plans to work on this feature? >> >> > > Not that I am aware of. Feel free to submit patches though! > This is a potentially tricky feature, because for example some of the microcontrollers I have worked with have pins that aren't available on certain packages. There are also cases where the pin mapping is just... wierd. Consider even the lowly Atmel ATtiny45, which comes in DIP8 and MLF20. Yep, an 8-pin package and a 20-pin package. Guess which one has a bunch of no-connects? :) IOW, I think that in the general case it isn't possible to pick a symbol independent of its package. True, it works for a lot of devices, but not all of them... Maybe a better way to approach this problem would be to provide for a meta-comment field or attribute in the symbol file that could be used to refer the user to alternative symbols for the part. That would let you have one .sym file per component-footprint, but also provide for a GUI feature to guide the user to the list of available options. Hopefully, older versions of gaf would just ignore that attribute. For symbols that worked properly for all available footprints for the part (DIP8 vs. SOIC8, for example), maybe another attribute would trigger the GUI to let the user pick between those footprint names. Just a thought. 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: Purpose of this list
Stuart Brorson wrote: > > I am always pleased by the high level of electronics knowledge > displayed by the folks on this list. The contributions are very > interesting and educational. > Agreed. I'm both pleased and very, very grateful. > I vote to keep it. Besides the educational value, the great postings > about electronics on geda-user are archived and searchable via > Google. That means that folks who are searching on keywords related > to electronics will come across the gEDA project. The high level of > the disucssions on geda-user serve as great advertising for the > entire gEDA Project. > Agreed! All exposure is good exposure, and I'd be suspicious of a list that discussed EDA topics where there wasn't any discussion of electronics at a more general level at least occasionally! > FWIW, sci.electronics.* has become a cesspool of spammers and trolls. > Other electronics discussion sites tend towards basic electronics. > For example, sparkfun is a good site, but the discussions are largely > oriented to newbies. Nothing wrong with that, but I'm glad geda-user > serves the needs of newbies as well as experienced engineers. I'd > like to keep it that way. > Agreed (sorry for being redundant). Once you start laying down traces from your schematic, the line between "electronics" and "pcb tool" become kind of blurry because the two definitely interact. So there's no escaping the necessity for *some* electronics-related discussion here. And so long as things aren't getting totally off-topic for geda, I say those discussions are welcome here. Lately, I haven't seen anything inappropriate. I'm not aware of any non-cesspool sites where people experienced in electronics design *and* layout congregate. I learned a lot about electronics early on from sci.* newsgroups, but as NNTP has fallen out of favor, those neighborhoods have really gone downhill. Sad to see. 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: More eye-candy
Peter Clifton wrote: > Alternative methods would be to export something to an external > renderer, such as povray or blender. > That's probably the best approach. Leave the really hard stuff to tools that already know how to do it. > My time is a bit limited. > From the looks of things, you should lose your tools more often! :) 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: )(
Gareth Edwards wrote: > 2009/10/2 Bill Gatliff : > >> Cheating or not, all the examples he posted look _awesome_! :) >> >> Let's say the objective of the 3D effects/output in PCB were to test >> against a 3D model of the whole system--- not just to visualize the >> (populated) PCB. Would Blender be the right output format then? >> > > I guess it depends what your goal is. Kai-Martin's assumed goal was to > produce a (photo?-)realistic depiction of the layout/assembly. Blender > is extremely well suited to that. But... > > To me that's not as useful from an engineering perspective as, say, > being able to see your board, and, crucially, interact with both the > view of the board and maybe its mechanical location in the system, in > real time. This definitely does not need raytracing and is the kind of > application OpenGL is well suited to. > I guess in the ideal world, I would be able to interact with a 3D model of the board/mechanicals/etc. with the highest visual resolution that my impatience would allow, and then also be able to produce time-consuming, photorealistic output for display to the customer. The two objectives wouldn't necessarily need to use the same tools post-PCB. 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: )(
Kai-Martin Knaak wrote: > On Thu, 01 Oct 2009 23:58:52 +0100, Peter Clifton wrote: > > >> As an older (code no longer in existence) example, perspective like this >> is not hard to achieve: >> >> http://www2.eng.cam.ac.uk/~pcjc2/geda/gerbv_GL.png >> >> (That IIRC, is cairo-rendered onto a texture, then stretched onto a >> quad). >> > > IMHO, this is cheating. 3D objects would at least need ray tracing to > look half way real. If there is an urge to push 3D output of pcb layouts, > it would be wise not to reinvent the wheels. I'd suggest an export in a > 3D format and delegate rendering to a third party application like the > excellent blender. > Cheating or not, all the examples he posted look _awesome_! :) Let's say the objective of the 3D effects/output in PCB were to test against a 3D model of the whole system--- not just to visualize the (populated) PCB. Would Blender be the right output format then? 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: wave rig went down.
Peter Clifton wrote: > I might have to do some more theoretical PhD work though.. that will be > a shock after all that practical work. > Well, at least you won't have to figure out a way to make your data fit the theoretical models! :) 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: Using the power instead of fighting it
John Doty wrote: > > On the other hand, when you're putting together a project, you have > some idea of what those needs are, so that's the time to add > "weight". And for big projects, it's handy to have a set of heavy > symbols identified by role: "bypass_capacitor", "low_noise_opamp", > etc. Then, as your needs change, you can change a symbol and get all > similar parts changed automagically. Or you can import the schematic > page into a different project built around a different parts stock > and have it "just work". > The details on one or two of the above, among others, would be great additions to a "best practices" wiki. And if a person's symbols are in any way reusable, I highly recommend gedasymbols.org as a place to archive 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: Using the power instead of fighting it
Peter Clifton wrote: > Ok, stop it guys, this is just too painful. > > > I just lost a whole toolbox full of lovely (high quality) new tools. > > They were on board the wave-rig I've spent the last 3 years working on - > when it capsized last week... oops. (I was also on board some minutes > before it went over!). > Was it the Trident wave test rig? Regardless, I'm glad you weren't injured. I sincerely hope that there were no injuries or fatalities. > I'm looking on all of this in the context of how trivial gEDA/gaf is > compared to $real_world. A number of people (including myself) are lucky > to be alive and uninjured after the wave rig went down. > Completely agree. I've survived a pair of personal tragedies myself, of the life-changing kind. Makes it easier to not pay attention to geda-user when the ranting gets underway--- but unfortunately makes it easier to stay away long enough to not notice when the ranting is over. > Perhaps I'm still not that well adjusted on what matters though - I'm > still more brothered about my lost tools than $scary_experience. ;) > :) Beware, the adjustment may come upon you when you least expect it. I can say that from personal experience. 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: Blind and buried vias?
Kai-Martin Knaak wrote: > On Tue, 29 Sep 2009 17:01:23 +, Michael Sokolov wrote: > > >>> I'm told that the OMAP3430's Package-on-Package configuration requires >>> at least six layers to get all the signals out. Ugh. >>> >> OK, that explains the need for a lot of layers. But how does the need >> for blind/buried vias arise? >> > > The balls of the BGA occupy most of the real estate available on top > layer. If all vias penetrate the hole stack, this occupation maps to all > other layers too. > ... and then you've covered all the area that would otherwise be available to run traces through. With a blind via, you can drop down to the next layer and get a little room to navigate. I haven't come across a situation that required a buried via, so I can't comment on that. Can't even guess, actually. 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: Blind and buried vias?
Gabriel Paubert wrote: >> I'm asking out of plain curiosity - I hope that I never have to make a >> board with such vias as I've heard that they add a bit of sadomasochistic >> flavor to board bringup/debug efforts - but then I guess some boards are >> so cramped for space that you can't avoid them... >> > > Indeed. Although I have never needed them. > It isn't always that the board itself is cramped, though that can definitely be a reason. The latest generation of BGA parts have so many pins on the package, packed so tightly together, that it isn't possible to get all the signals out of the chip in two layers and still have the traces large enough to meet specs. A sophisticated chip in an 0.5mm-pitch BGA package, like the OMAP3430, is an example. I have never seen the underside of one of these guys, but I bet it's pretty scary. I haven't had to lay one of these boards out myself yet, thankfully! :) I'm told that the OMAP3430's Package-on-Package configuration requires at least six layers to get all the signals out. Ugh. 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: Blind and buried vias?
Martin Maney wrote: > > +1e6 - not that Scheme is my favorite scripting language, but if there > were a documented API it would be a viable option. > OT, but Gimp also uses Scheme. 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: Blind and buried vias?
Guys: >> And many who find "shortcomings" in gEDA don't want a toolkit. >> > > I have very mixed feelings about that, though the above has mostly come > down on one side. Is there a way to strike a balance like cURL did, which is to put a lot of the "guts" of the code into libraries that can be used as part of single-function, standalone tools or combined to produce an integrated runtime environment? 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: Blind and buried vias?
DJ Delorie wrote: > Status: "Not yet, want it, blue-sky plans available for rent." > > It's part of the "Upgrade of layer and design objects" item in the > Linux Fund work, number 4 of 5 tasks. > With the onslaught of cool chips in BGA packages that's happening lately, I'm hoping this task gets the attention it deserves. :) 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: Blind and buried vias?
John Doty wrote: > On Sep 25, 2009, at 10:09 AM, Bill Gatliff wrote: > > >> Guys: >> >> >> What's the current and planned state of support for blind and/or >> buried >> vias in the gEDA system? I got a few questions on that at the >> Embedded >> Systems Conference earlier this week... >> > > Well, of course that's a problem for the layout tool, so choose a > layout tool that supports them. "pcb" is only one of the tools gEDA > can export netlists to. Remember, "pcb" is a separate tool, not part > of gEDA. Probably very few pcb users capture schematics with anything > but gschem, but some (perhaps many) of us use gschem/gnetlist with > other back ends. > Can you suggest a GPL/BSD/equivalent layout tool that can do blind/buried vias? 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
gEDA-user: Blind and buried vias?
Guys: What's the current and planned state of support for blind and/or buried vias in the gEDA system? I got a few questions on that at the Embedded Systems Conference earlier this week... 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: PCB 20081128 undo bug
Ineiev wrote: > On 9/14/09, Kai-Martin Knaak wrote: > >> On Fri, 11 Sep 2009 15:41:54 +0200, Stefan Salewski wrote: >> >> >>> Indeed PCB version 20081128 (GTK) works very stable -- during the work >>> on my DSO layout I got only two crashes >>> >> A very stable application should _never_ crash for no apparent reason. >> > > Therefore, there _were_ apparent reasons. > Well, there were _reasons_, at least. Maybe not ones apparent to the user at the time of the crash! 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: PANGO FONTS MERGED: Call for testing
Peter Clifton wrote: > I tried (and failed) to find a vector format OpenOffice could paste. > Basically it will only accept its own format for vector drawing (even > WMF/EMF paste an image when accepted via the clipboard). The converters > I found to emit the required format were variously broken - mainly with > text handling. > I haven't tried to paste into OpenOffice, but I have had good luck merely exporting from gschem to a ps file, and then using gimp et. al to take it from there. I routinely convert to eps and then import into LaTeX, for example. 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: PANGO FONTS MERGED: Call for testing
Peter Clifton wrote: > On Tue, 2009-08-18 at 01:51 -0400, gene glick wrote: > >> ok, dumb question . . . pcb or gschem? Can you also give me the git >> commands? I'll try it out. >> > > gschem > > git clone git://git.gpleda.org/gaf.git > > cd gaf > ./autogen.sh > ./configure --prefix=/home//geda --with-xdgdatadir=/home//.local/share > > make > make install > > (NB: The above build procedure is from memory, and might need a little > tweaking!) > When I built it under Debian, I used the above commands except that I didn't seem to need the --with-xgdatadir. 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: PANGO FONTS MERGED: Call for testing
Peter Clifton wrote: > Hi guys, > > I just merged the pango font stuff to git HEAD. > > This is a call for testing, to note any unexpected / undesirable > behaviours which this might have introduced. > Built perfectly clean for me under Debian testing on amd64. I can't really abuse it at runtime, because I don't have any sophisticated schematics to throw at it or any outstanding bugs of my own to test for. But I can report the visuals are so clean and sharp, they almost give me a headache. :) 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: gEDA just hit SlashDotOrg
John Doty wrote: > On Aug 12, 2009, at 9:44 AM, DJ Delorie wrote: > > >>> If you try to use a chainsaw as if it was a hand saw it will seem >>> very clumsy. >>> >> As someone who uses a chainsaw often, I find that analogy stupid[*]. >> >> A chainsaw is a perfect example of what gEDA is *not*. Anyone >> familiar with chainsaws can pick up pretty much any chainsaw and do >> most of what you'd need to do with a chainsaw. Despite differences, >> it's easy to figure out how to prime and start it, what the safety and >> operational features are, and how to use it correctly. Assuming you >> know how to use chainsaws in general, of course. >> > > Yes, and that last sentence is my point. gEDA is a chainsaw in a > world of where most only know handsaws. > Waitaminit, how did we get into a discussion on power vs. hand tools? I thought this thread was about improving the out-of-the-box gEDA experience!? Gosh, miss a day and miss a lot... but I was only gone for eight hours... :) 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: gEDA just hit SlashDotOrg
DJ Delorie wrote: > So, can we ignore the "flexible" vs "easy" argument for now? I think > it's much more important to get the intermediate step first - giving > people an easier solution to *trying* gEDA to see if it fits their > needs. > Honest, I didn't read this post before writing one of my own that says the exact same thing. I don't know whether that's a good sign, or not. Perhaps it's for the best that DJ doesn't know me at all, so he can't decide whether it's a good thing or not that we think alike about something. :) 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: gEDA just hit SlashDotOrg
spuzzdawg wrote: >I think that this is basically an argument in usability vs >flexibility. One person's flexibility hinders another's usability. :) I think what's abundantly clear by this whole discussion is that there's a grave need for a recommended, introductory-level workflow--- and enough "glue" to make that workflow as simple as possible for a new user. A new user probably doesn't care initially about the gobs of cool stuff gEDA can potentially do, I bet they just want to get from schematic capture to fabricated board with as little effort as possible. Once they've completed that cycle once, if the experience is pleasant then they'll be motivated to try some of the more sophisticated workflows that gEDA's flexibility makes possible--- even if that means a higher investment in effort. If the initial experience is unpleasant, they won't come back and all that flexibility is wasted on them. I came to gEDA with no experience whatsoever, other than doing schematic "captures" with pencil and paper, and "fabrication" on a solderless breadboard. I'm three or four designs in now, but getting to where I was even competent with the tools hasn't been easy--- my first board run cost me $500 due to a footprint screwup that forced me to toss the whole lot in the bin. I don't like having to demand that level of effort from the new users that I recommend the tools to. A tool as powerful and important as gEDA needs an active user and contributor base, which is something I don't see reflected in the geda-user mailing list activity: the same few names come up over and over again. That's a bad sign. We can't grow a user base if we can't create a pleasant out-of-the-box experience that keeps the first-timers around for a second, third and successive designs. Even if their designs aren't substantial, and even if they don't require all the power that gEDA has to offer, we have to make sure that their efforts have a high probability of success if we're to keep them around to learn about all the better ways that gEDA can solve their problems. For the record, I don't think gEDA is *that* hard to use. By far the biggest obstacle to me to date has been a lack of clear direction on and support for an introductory-level workflow: a basic set of pre-existing symbols and footprints for some common parts, and end-to-end guidance on how to use them to get through to something you can submit to a board house. (In fact, it took me a while to even figure out HOW to submit to a board house). As it is now, most of my symbol and footprint library is basically junk because I totally didn't get the idea from the beginning about the kinds of information I need in my symbols vs. what I thought I needed. I'm not talking about a "heavy-vs.-light debate", I'm talking about "if you are going to do a heavy symbol, then do it like this...". I think the root of the Slashdot article poster's problem is gEDA's out-of-box experience, but we've let that discussion (de)evolve into the relative merits of flexibility vs. usability. I think we should go back to defining tasks that would improve the out-of-box experience without necessarily breaking gEDA's flexibility in situations where more than documentation is required to address the issue. Once we've worked down that list, we can decide at that point if the time we get back is best spent on abstract discussions or more tasks. :) 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: gEDA just hit SlashDotOrg
John Doty wrote: > > 1. pcb is not the only layout tool gEDA supports. > Can you suggest some others? 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: gEDA just hit SlashDotOrg
Jason Childs wrote: > On Sun, Aug 2, 2009 at 8:42 AM, John Doty wrote: > >> We're not a programming team implementing what Marketing wants. We're >> a bunch of computer-savvy users implementing what we intend to use. >> That's our strength. That's why gEDA is different. That's why gEDA is >> a sharp toolkit for the computer-savvy. >> > > So is this why my simple bsearch patch for hid's hasn't been > incorporated in 3 months? I have to apply it every time I do a pull > from pcb git so that it doesn't segfault. I'm sorry, but the tone as > of late on the mailing list has been "our way or the highway", at > least from what I've read and encountered on the mailing list. Heck > I've been afraid to post using gMail for fear of getting kicked from > the mailing list because of double posting or posting in RTF. Frankly > if you can't see the current problems within the geda community that's > ashame, because it's a reflection of the product too and why thing's > haven't advanced. I'm a relatively late arrival to the geda community, so I can't comment on any trends (and I come from the Linux kernel community, who is openly hostile towards pretty much everyone so I have an unusually thick skin). But I definitely sense a lot of resistance to change. I have a hunch that some of the ambivalence comes from, "It was hard enough to get things to this point!"-thinking. And it's also obvious that many members of the community have a substantial investment in the way geda works today that nobody wants to see invalidated. Tough spot to be in, methinks. :) And not one that someone with the skills and initiative would be able to challenge without making it a full-time assignment. And who can financially afford that? I'm a freelancer who uses a lot of the tools I write, I'd love a 1-man-year contract to clean up geda and pcb. But I bet I'm not the only one who would--- and that's the kind of effort we're talking about here. Any givers? > I thought when I converted the gaf source > from using noweb it would open up a whole new opportunity for actual > software developers to start contributing, and I now regret the time I > lost doing it. > I'm not familiar with your effort, but I'm certain it laid the groundwork for the refactoring that you desire. 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: gEDA just hit SlashDotOrg
Kai-Martin Knaak wrote: > On Sun, 02 Aug 2009 10:41:49 -0500, John Griessen wrote: > > >> http://www.edn.com/article/CA236.html?text=improving+on+pcb+design >> > > Somewhere in the interview they mention the use of spreadsheets to > manipulate symbols in a schematic. I guess, this is, what inspired > gattrib. However, to be really useful during schematic capture, the > spreadsheet needs to communicate more directly with the primary GUI. It > needs to be called from the GUI on selected parts only. And it must > prevent conflicts between the data in the spreadsheet and the data shown > in the schematic GUI. From the user point of view, it should be part of > the GUI just like the edit object dialog is. In a sense, it is and should > feel like a multi symbol attribute dialog. > That's exactly the kind of stuff that becomes possible--- but in a flexible way--- when you emulate what was done with the GNU debugger, gdb, a few years ago. The refactored to put their core functionality behind a layer that could be utilized by a GUI without that GUI being tightly coupled to the internals of the code. 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: gEDA just hit SlashDotOrg
John Doty wrote: > On Aug 2, 2009, at 7:45 AM, Kai-Martin Knaak wrote: > > >> On Sun, 02 Aug 2009 06:42:20 -0600, John Doty wrote: >> >> >>>> His judgement is pretty much dead on. Many people on this list are >>>> openly hostile to Windows users, >>>> >>> The only hostility I see is to the attitude: >>> >> Yet, the rest of your post is a perfect example for general windows >> hostility. >> > > Huh? It's not hostility to Windows, it's hostility to an approach to > software that isn't at all unique to Windows. Windows is a latecomer > to that approach. And, in fact, Windows doesn't force that approach > on the user. The barriers are in the users' minds, not in the system. > And that isn't unique to Windows, either. > > Here, the big difference here between Windows users and Mac users is > one person: Charles Lepple, who packages gEDA for MacOSX (hurray for > Charles!). So, there are no complaints that gEDA is unfriendly to Mac > users. That's all it takes. > > The integrated GUI approach has its uses: I'm typing this in Apple > Mail. But for less trivial jobs, it forces the user onto a low > productivity track. > > I'm hostile to bicycles with training wheels permanently attached. > > >> >>> We're not a programming team implementing what Marketing wants. >>> We're a >>> bunch of computer-savvy users implementing what we intend to use. >>> That's >>> our strength. That's why gEDA is different. That's why gEDA is a >>> sharp >>> toolkit for the computer-savvy. >>> >> It is remarkably blunt in certain aspects. Aspects, that are very >> relevant to EDA. Lack of backannotation >> > > Is there any tool that *really* does backannotation well? I used a > commercial one where the backannotation wasted more time than just > doing the job by hand. I've heard similar complaints from others. But > it's something we can work on. Dan's .eco file suggestion is a good > one, because it could come from anywhere. My pins2gsch script is an > effective backannotion tool when you don't need graphical > connections. Dan's .eco file suggestion is a good one, because it > could come from anywhere. For non-hierarchical schematics, attribute > backannotation looks pretty simple. But this is another place I wish > gnetlist was more transparent: if the back end could see the > hierarchy, making a map that would help a backannotation script find > the attributes would be trivial. > > But I probably wouldn't use full backannotion in my flows anyway. > Keep the "source files" clean, transform them into intermediates as > needed. Good tools could do it either way. > > >> and a more than stony interaction >> with simulation tools are just two of them. >> > > One problem is that the simulation tools don't play so nice. gEDA's > advantage, though, is that it can work with any one of them. > > Sounds like you want a schematic plug-in to gnucap. And then you'll > want a schematic plug-in to PCB. Those wouldn't be bad things, > especially if they used .sch format for the files. But let's keep > gEDA's modular, flexible kit modular and flexible (there's even room > for improvement here). A schematic plugin to bin/* is not the answer. > One of the ways that the gdb guys cracked this nut was to push a lot of their functionality into libraries, and create an HID-centric API for them. They include a command-line-interface implementation by default, but then others can take those same libraries and build their own GUIs around them. And drag in libraries from other places to add functionality that gdb doesn't itself provide. So now Eclipse, DDD, Insight, and many other frontends can all use the same gdb backend rather than inventing their own. Everybody wins. If the GUIs around gschem and pcb were not tightly coupled to the internal functionality (I don't know that they really are, I'm just saying...) then one could define and implement a clear division between what was GUI and what was core functionality--- and if someone wanted an integrated schematic-capture-plus-pcb-layout tool, they would incorporate both geda core libraries and pcb core libraries underneath their own GUI implementation. I think this approach is a nice way to have your cake and eat it, too. Each tool can remain a standalone component, or you can stitch them together at a higher level without resorting to behind-the-scenes shell scripting and so forth. It has worked well for gdb, at least. Just a thought. :) 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: gEDA just hit SlashDotOrg
John Doty wrote: > > I very much > hope that gEDA does not evolve into a dull tool. > I agree. But I also agree with others who say that more could be done to bridge the gap between us and a typical Windows user. Who knows, as a result we may end up attracting a developer or two with skills we need. If we could just do something to help them get started. Like it or not, the Windows culture is very much into dull, boring tools. We can't show them a better way if we can't show them anything at 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: Texas Instruments TPS series
David Griffith wrote: > I've been finding myself fiddling with a lot of new TI stuff, specifically > stuff prefixed with TPS. Take a look at some of the new TI symbols I > uploaded. > This link: http://www.gedasymbols.org/user/david_griffith/symbols/tps7613x-1.sym ... appears to be broken. 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: Make-sure-internal-order-of-symbols-is-not-relevant-.patch
John Doty wrote: > That's one symptom of the bug, yes. But the real problem is that the > front end reduces what is logically a list of attributes to a single > attribute by arbitrarily picking one. That's wrong. Give them all to > the back end. Simpler, cleaner, and no barrier to any back end that > might need the whole list. > Why would the back-end want to be able to discriminate between devices with the same refdes? 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: merge multi symbol components
Joerg wrote: > > I've never seen it done that way, could make the schematic hard to read. > The customary way would be to place the whole uC on a sheet and then > pipe its pins to ports, which in turn correspond to ports on several > other sheets. They would be assigned meaningful names such as "P3.7" or > "ADC5" so most engineers would know what that is even if they don't have > the uC sheet in front of them. > Yea, that's a better way. I'm still learning. :) >> If I'm dealing with a wired-OR input, then the same pin might get used >> on several different sheets. And if that's the only pin on a port that >> gets used, then your logic would trip it as an unintentionally >> duplicated symbol. >> >> > > I guess in medical or similar regulated fields that would get you > flogged when the auditor cometh ;-) > > But to everyone his style ... > Well, it's worked for me. But the approach could definitely use some improvement. I appreciate your suggestions. 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: one year later...
John Luciani wrote: >Are you sure that was a tornado? >Looking at those pictures it appears to be a message from aliens >addressed to William Hemmel ;) > Yea, that's what I thought, too! :) We had a pretty nasty one just miss my home in 2004: http://en.wikipedia.org/wiki/2004_Roanoke_tornado 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: connecting elements in PCB
Stefan Salewski wrote: > On Fri, 2009-07-24 at 09:37 -0500, Bill Gatliff wrote: > > >>> http://www.delorie.com/pcb/docs/gs/ >>> >>> >> In 4.3 SMT Blinker, the third paragraph is talking about organizing the >> board's layer groups. But you haven't talked about that yet so I'm >> completely lost as a reader. >> >> Just an editorial criticism. So far, the document is pretty nice. >> >> >> b.g. >> >> > > For a novice it may be wise to read that fine tutorial from the begining > -- I did that and I think that most important points are explained well, > this includes layer groups. (I have to admit that layer grouping was > difficult to understand for me when I started with PCB long time ago.) > > This is above section 4.3, including a picture: > Aah, somehow I missed that. Thanks! 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: connecting elements in PCB
DJ Delorie wrote: >> I'd like to start drawing a PCB but do not want to import any gschem >> files... how do I connect the elemnts with circuit tracks? Are the lines >> created by the "line" button circuit tracks? >> > > http://www.delorie.com/pcb/docs/gs/ > In 4.3 SMT Blinker, the third paragraph is talking about organizing the board's layer groups. But you haven't talked about that yet so I'm completely lost as a reader. Just an editorial criticism. So far, the document is pretty nice. 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: connecting elements in PCB
DJ Delorie wrote: > http://www.delorie.com/pcb/docs/gs/ > " Then, you are tortured to death with non-modal dialogs." So true! :) :) 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: merge multi symbol components
John Doty wrote: > Make can orchestrate simulations, document construction, data > reduction, and much more (including, of course EDA). It's not > restricted to programming. It's a general purpose tool. I saw an article the other day where someone replaced their Linux init with Make, and saw a significant boot time reduction due to parallelism and automatic dependency resolution that scheduled the system bringup more effectively. Nifty! 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: merge multi symbol components
Kai-Martin Knaak wrote: > On Wed, 22 Jul 2009 06:07:54 -0500, Bill Gatliff wrote: > > >> In my case, I use one symbol to refer to all 8/16/32 bits of a GPIO port >> on a microcontroller. I'll use a few bits from that port on one page, >> and a few on another. >> > > Ok, this is a legitimate case. Still, the common error of unintentional > duplicate symbols should be brought to the attention of the user. How > about a warning, complemented with an entry in the yet to be defined > attribute "multi-part". This attribute would suppress the warning. > Totally agree. Some of my designs include multiple identical microcontrollers, and I'm always very aware of how difficult it is to make sure the wiring all gets to the right places. An error, with the command-line option of turning that error into a warning, would be very, very reassuring. 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: merge multi symbol components
John Doty wrote: > It worries me that people are wiring their scenarios into the tools, > when gEDA's unique strength is its flexibility. This isn't limited to > gEDA: it seems to be a programming universal that people feel > obligated to turn simple, flexible toolkits into bloated, inflexible > "applications". > I agree with you in principle. But it would be nice for gEDA to work "out of the box" for the most basic cases, so that new users don't have to work very hard to see results. I think it mostly does, except for its error detection abilities, and Kai-Martin is taking a stab at improving that. It won't work for all workflows, but it will help some and future versions will help with more I'm sure. I found gEDA pretty intimidating at first, because it has a bits-and-pieces feel to it. Over time, I'm learning ways to take advantage of all those bits-and-pieces as I find more challenging problems to solve--- and grow less satisfied with bending my workflow to gEDA's "typical" (if you can apply that word to it at all) way of doing things. And I'm finding that the tool is growing with me, which is fabulous. Some of my adaptations, like not tying my symbol library to a particular project, finding a balance bettween "heavy" and "light" symbols that suits my needs, footprint issues, and so on, have been foreseen by others who could have provided a "best practices" set of recommendations for starting me out on the right path. Those recommendations might not have made the first project go any smoother, but definitely would have helped the second, third, and so on. Things like gedasymbols, Luciani's site, etc. fall into this category. Without them to use as references, I would have struggled for much longer than I did. I think the situation is a lot like with the Linux kernel: true, it's powerful code but it takes someone with a big-picture vision to really put that power to good use. And there are different use cases and skill levels, hence all the different distributions that use modified Linux at their cores. LaTeX and pstools are other examples. I'm not suggesting that we need a gEDA "distribution" per se, but I bet there's a way to maintain all the flexibility that gEDA while at the same time improving the out-of-the-box experience. I think that's an important context to view Kai-Martin's work in. 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: merge multi symbol components
Gabriel Paubert wrote: > Connect it to an NC symbol to explicitly show that you don't use that > pin in that instance of the symbol. > I'm sloppy, I just leave them open. :) >> If I'm dealing with a wired-OR input, then the same pin might get used >> on several different sheets. And if that's the only pin on a port that >> gets used, then your logic would trip it as an unintentionally >> duplicated symbol. >> > > Ok, that one is really harder. > But it doesn't happen often enough that I think his tool needs to do anything more than issue a warning. I bet there's a cleaner way to deal with it, a solution that we'll find later. 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: merge multi symbol components
Peter TB Brett wrote: > > If it's useful for him, I don't see any reason why he shouldn't implement > it. I don't believe that he's arguing that it should become the default > behaviour. > Agreed. My impression was that he was working on a tool that could become generally available, I was just trying to offer some constructive feedback. To his credit, he's trying to solve a pretty difficult problem. One that I'm not sure I'd want to tackle. :) I'd be able to adopt his tool if it had an option to flag duplicated symbols as warnings, rather than errors, which is why I mentioned my use case--- but then failed to offer this suggestion. :( 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: merge multi symbol components
Kai-Martin Knaak wrote: > The main case I'd like to catch is unintentionally duplicated symbols. If > both, refdes and all pins are identical, it is safe to assume an error. > Nak. In my case, I use one symbol to refer to all 8/16/32 bits of a GPIO port on a microcontroller. I'll use a few bits from that port on one page, and a few on another. If I'm dealing with a wired-OR input, then the same pin might get used on several different sheets. And if that's the only pin on a port that gets used, then your logic would trip it as an unintentionally duplicated symbol. 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: august freedog sprint/cookout
DJ Delorie wrote: > It's that time again. If you're interested in coming to the > sprint/cookout, email me (privately) with which days (both saturdays > and sundays are options) you're available and I'll figure out the best > date for it. > What's the general geographic location of the event? 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: More robust support of multi-part symbols.
Steve Meier wrote: > Talking about gates and using the term slots is so 1980's. > > Today's issues are how are pga's supported. How are multiple logic > levels, being able to define a pin as an input an output or > bi-directional or differential? How are the gates logic levels defined? > > Let alone, how at the layout level we can do pin swapping and back > annotation. > > To me geda and pcb are just falling further and further behind the state > of the art. > I can't argue that one way or the other, but support for the fundamentals are no less important than they have ever been. 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: More robust support of multi-part symbols.
John Luciani wrote: >On Wed, Jul 8, 2009 at 2:08 PM, Bill Gatliff <[1]b...@billgatliff.com> >wrote: > >John Luciani wrote: >>aggregates the attributes manufacturer and >manufacturer_part_number, >> > > Are those two attributes a common convention? I've been using > manufacturer= and manufacturer_partnumber=. I've also been doing > vendor_partnumber_digikey= and vendor_partnumber_mouser=, but I'm > not so > sure those are useful enough to keep doing so. > >Putting vendor information into the schematic is not a good idea. >I use Postgres tables for that mapping. You could get the relations >using text files and hashes. >Ideally you would not put manufacturer information in the schematic >either. >You would have a master parts list with your own part number that does >a one-to-many map to multiple vendors. Since that database is a bit >of work to setup and maintain I use manufacturer and >manufacturer_part_number. > Makes sense to me. Especially since vendors like DigiKey and Mouser have search engines that can match to manufacturer part numbers. 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: More robust support of multi-part symbols.
DJ Delorie wrote: >> I looked around, and haven't seen anything documented for these >> attributes. >> > > http://www.gedasymbols.org/csv.html > How do you want to handle multiple vendors with different vendor part numbers? 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: More robust support of multi-part symbols.
DJ Delorie wrote: >> I looked around, and haven't seen anything documented for these >> attributes. >> > > http://www.gedasymbols.org/csv.html > Great!! 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: More robust support of multi-part symbols.
John Luciani wrote: >aggregates the attributes manufacturer and manufacturer_part_number, > Are those two attributes a common convention? I've been using manufacturer= and manufacturer_partnumber=. I've also been doing vendor_partnumber_digikey= and vendor_partnumber_mouser=, but I'm not so sure those are useful enough to keep doing so. I looked around, and haven't seen anything documented for these attributes. But I'd put them into all my symbols if I knew what to call 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: More robust support of multi-part symbols.
Kai-Martin Knaak wrote: > > 1) gnetlist should look for a footprint in every instance of a refdes > Agreed. I use multiple symbols per part as well, but tend to put the footprint= in just the power symbol. I also tend to group all my power symbols onto one or two pages by themselves. > 2) add a known attribute "parts" that lists all symbols of a component > (should the entries in the list be separated by space, or something >more sophisticated?) > I have an alternative suggestion, see below. > 3) gnetlist should complain if the lists of attributes are inconsistent. > > 4) gnetlist should complain if there are different footprints present > Agreed. > 5) gnetlist should complain if a component is not complete (part missing). > That won't work for me. Many of my multi-symbol parts are microcontrollers, broken down by functionality e.g. timer/counter 0, gpio, etc. in addition to just power. If I'm not using a portion of a microcontroller's functionality, then that symbol won't be present. And pins might appear in multiple symbols, due to pin multiplexing in the physical part. It would almost certainly be an error if a pin were actually used in two different places in a project, however ,because that would suggest that you were trying to use the pin for both its GPIO functionality and it's timer/counter function. That doesn't tend to work. But if I have an 8-bit GPIO port symbol and one page uses only three pins, then that same symbol might appear again in several other pages as I allocate the remaining pins. Finally, a design might have two or more microcontrollers or other multi-symbol parts. Maybe what you need instead of a complete parts list is a depends-on specification, to indicate that "if this symbol is present, then the symbols it depends on must also be present and have the same refdes". In my case, my timer/counter and gpio symbols would indicate that they depended only on the microcontroller's power symbol. > 6) gschem should read the parts list and insert all parts at once. > I don't see the point in this, especially since my symbols get spread out across multiple pages. Perhaps what you really mean is that if something is parsing a set of schematic pages, when it encounters a multi-part symbol (detected as a duplicated refdes but without any other conflicting information) then it should merge the information from all those symbols together and emit the result all at once in the output? That's always been my mental model of how multi-symbol parts worked. > 7) auto number of gschem should keep multi-part symbols with the same refdes. > Totally agree, but I have no idea how you would actually implement the ability to auto-assign them in my use case--- where the symbols would be on different pages, and/or you might have two or more parts each with multiple symbols. But at that point I think it's ok to require manual refdes assignment. > Next step would be to treat slotted components like multi-part symbols. > I've always thought that slotting was just a special case of multi-symbol, where the two symbols were visually identical. If slot changes were to allow the symbol to change, then the two are equivalent. Note that I'm not suggesting this, I'd rather we get away from slotting because that's been a source of more symbol entry errors than anything else I've done with gschem. > Any comments? > A few. :) 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: TI's "SOT25" DBV footprint...
Duncan Drennan wrote: >> TI's sn74lvc1g240 part uses what appears dimensionally to be an ordinary >> SOT25 package, but the pin numbering is different. Am I better off to >> just construct my own footprint, or is there a way to deal with this at >> the symbol level and still show the right pin numbers in the schematic? >> > > I'm pretty sure everyone will have a different way to deal with this. > My personal preference is to keep the footprint consistent and have > different symbols for variances in pin numbering. > > My reasoning: the footprint is a physical description of a component > and can represent multiple components. The schematic is the logical > description and the logic (pin numbering in this case) varies for > different components. > So, you're suggesting that I use the standard SOT25 footprint that comes with pcb, and then somehow craft a gschem symbol that shows pin numbers consistent with the sn74lvc1g240 datasheet but binds properly to the standard footprint? I suppose one way to do that would be to put ordinary text where the pinnumber= value is usually displayed. Anyone have any other ideas? 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
gEDA-user: TI's "SOT25" DBV footprint...
Guys: TI's sn74lvc1g240 part uses what appears dimensionally to be an ordinary SOT25 package, but the pin numbering is different. Am I better off to just construct my own footprint, or is there a way to deal with this at the symbol level and still show the right pin numbers in the schematic? Thanks! 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: Toporouter Changes
Anthony Blake wrote: > John Griessen wrote: > >> Seems like the force-field approach >> >>> just tweaks his "better" definition based on user input and not just the >>> board geometrics. >>> >> Right. To move in one direction from a point that repels is one way to code >> such a function. >> Another would be a straight line, and even better, a hand drawn line-segment >> line >> carving out regions of circuitry that should stay some distance away from >> eachother. >> Then rerun the program with wider DRC rules for the next region to pack >> against the first. and so on. >> > > I would prefer to implement this sort of functionality with topological > directives or constraints, and avoid geometric constraints if possible. > Kind of like providing the circuit-board equivalent of a geological topographical/relief map, so the algorithms know where the "valleys" (preferred paths) and "peaks" (mountains, don't climb them unless necessary) are? And the lakes, airports, Area 51's, etc Except that with circuit boards it would be more than 3-D, because some of the mountains would be abstract things like excessive trace length (which might later trigger the addition of a via and then a retry), DRC rules, desire to avoid the extreme edges of the board, and so on... An [n]-D "relief map"... Ok, that's about all that I can contribute to the idea. Love the work, and obviously totally unqualified to do any of 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: Toporouter Changes
John Griessen wrote: > Crosstalk is always a function of which wires, not parallels in general. > Right, so I guess that analysis on a routine basis won't tell you much--- so I'll retract that suggestion. I do think there would be some merit in looking at the statistics of trace lengths, though. But since a circuit only works if all the traces are there, that would be a higher priority than trying to minimize trace lengths compared to another autorouter. So that one is probably too academic to be of interest right now, too. Darn, that makes me zero-for-two. I'm going to go console myself with an Oreo. :) > What an autorouter that goes to completion can get you that is so valuable is > a way to generate three what-if cases of the same netlist where you set up > different constraints in advance to guide the autorouter. Comparing those > and selecting the best > is highly valuable. It's a case by case individual thing though. > Understood. Put another way, there's no substitute to knowing the capabilities of your tools, along with how to get those capabilities when using them. And it seems like you only get that knowledge after burning good cash on bad layouts. At least that's been the way for me! > The next high value thing to do as human input is after a good autorouter run > -- you > push parts of the circuit away based on your knowledge of crosstalk > susceptibilities. > The best way I've seen to do that is with a DRC correct local autorouter that > works like > a force field that pushes against circuitry in a user-chosen direction and > lets it move until it hits > design rule constraints. > I bet that Anthony's toporouter probably has some hooks already in place that could make that possible. The first trace one puts down on a board can go in an infinite number of directions, so he has to know that some paths are "better" than others. Seems like the force-field approach just tweaks his "better" definition based on user input and not just the board geometrics. So it's probably, what, ten lines of code or so to implement? He could just throw that in at the same time he's tinkering around with those magic "via" things everyone seems so keen on. :) :) 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: MOSFET high-side driver schematic symbol suggestion?
Christoph Lechner wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Bill Gatliff wrote: > >> Guys: >> >> >> Anyone care to suggest a schematic symbol for a MOSFET high-side >> driver? I'm having artist's block. :) >> > What about a box, with some pins? ;) > This is the way IRF does it. > http://www.irf.com/product-info/datasheets/data/ir2184.pdf > That's what my current symbol looks like. :) I'm considering dividing it up into two sub-symbols, however. One for the driver itself, and the other showing the "power" leads (for decoupling caps, etc.). I might make the driver symbol look like a typical sideways triangle a'la an op-amp, but there are three pins: the input, the output, and the source voltage feedback. So re-using that metaphor seems like a bad idea--- but I might do it anyway. :) Otherwise, it'll be just a boring old box with three pins. The power-related pins, of which there are only two, would still look like a box with two pins on it. My power-decoupling.sch pages are all just a sea of such symbols and capacitors, no point trying to clean that up. 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
gEDA-user: MOSFET high-side driver schematic symbol suggestion?
Guys: Anyone care to suggest a schematic symbol for a MOSFET high-side driver? I'm having artist's block. :) 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: Toporouter Changes
Anthony Blake wrote: > Hi All, > > Thanks to everyone who sent me boards to play with. The Meggy Jr board > helped reveal a rather tricky problem that I've only seen once before. > > I've updated the website (http://wand.net.nz/~amb33/toporouter/) with > boards from Kai-Martin Knaak, Ben Jackson, and Windell Oskay. > > After fixing a few problems this weekend, I'm quite happy with the way > the single layer code is working. See > http://wand.net.nz/~amb33/toporouter/LED-toporouted-before-speccuts.png > to compare the current LED board screenshots with the solution from > before the weekend. > I had to stare at it a few seconds to see the differences, but the later version is much improved! It might help your case if you could highlight some of the differences, to make it easier for others to appreciate. I'm increasingly fascinated by your work, in large part because you provide such tangible evidence of it! I think you should also more clearly mention on your example pages that when you say that the toporouter "failed N nets", what you really mean is that the toporouter was unable to complete the board _without employing additional vias or other strategies_. Otherwise, you are kind of under-selling yourself. The boards that you didn't finish are really close, probably trivial once you add just a few vias. I'm looking forward to that capability! On the pdhobbs board, the toprouted output shows a failed net at the top-left corner of the board that seems like a trivial case. Funny that it would miss that one--- and if it had found it, I think it could have completed at least one more net as well. I'd be curious to see how the total track lengths compare between your toporouter output and the geometric autorouter's, and what the statistical variation in lengths is between the individual tracks of the two boards. Does your output tend to find shorter paths but with occasional outliers, for example? The answers might be interesting to the RF and power guys, and might also help you automate the tests to see if toporouter changes improve the test case outputs. The geometric autorouter's octilinear output reduces the number of long, parallel traces that might lead to crosstalk. Your traces are not generally linear so they're even better, but I do still see some long, semi-parallel outputs. I'm thinking that your output should have better RF performance, but I'd be curious to see some simulations at some point down the road. Not any time soon, though--- just keep the good code coming! :) 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: Toporouter Updates
Anthony Blake wrote: > Hi Everyone, > > I've recently updated the toporouter website with some screenshots > showing the recent changes. > > http://www.wand.net.nz/~amb33/toporouter > Amazing! Very, very exciting work. I have a very small, mixed through-hole and smt design that I'd be happy to throw at you. About 70 components, the board is pretty sparse at 4"x1.8"--- but a much denser version is in the works. :) Due to connector placements, the board has some power and signal paths that must cross--- with the power traces getting priority because I want them to be as short as possible. I hand-route the power traces, as well as the power supplies to the ICs, and then tell the autorouter to route the rest with the "signal" trace style. I also hand-route a GND trace around the perimeter of the board, both to make sure that the board's mounting holes have good grounds, and to help mitigate ESD concerns as the board must be frequently handled. (It probably doesn't help much, but it makes me feel a little better). The autorouter (geda-gschem-1.4.3-2b1 deb package) is unable to route the remaining rats using only "power"-sized traces, but does a decent job if I use "signal" ones. When it has problems, it's almost always because a previous trace boxed it into a corner--- usually because it ran two traces in parallel on the top and bottom layers, or by putting traces too close to pins. The autorouter also has this annoying tendency to run a really long GND trace somewhere other than the GND trace I laid down 10mil away in the other direction. Odd. Anyway, let me know the best way to get this file to you, both the version I'm having built now and unrouted ones that you can play with. And whatever else you'd like. 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: spNet v0.9.2 released
John P. Doty wrote: > > I'm working on a gnetlist back end tutorial. I think that the > capabilities of gnetlist are underappreciated, and that specialized back > ends could be very useful. > Is your work-in-progress viewable on the wiki, or somewhere? 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: spNet v0.9.2 released
John P. Doty wrote: > > The people who seem to appreciate your work don't seem to understand > gEDA. They expect something like the "do everything poorly with one > tool" approach that is so distressingly common in software these days. A > kit of tools, each of which does one thing well, is alien. But that's > gEDA, that's its strength. > For the record, I just said I liked his documentation and website--- and pled ignorance on everything else. :) Look, I'll first apologize for starting this whole thing by calling you names, John. I intended it in jest, but obviously my email didn't make that clear enough. Sorry. It was inappropriate behavior from me, to say the least. I agree that one of gEDA's strengths is that each component does one thing, and does it very well. That fact alone has made it much easier for me to get my head around the small parts of it that I need to get my relatively modest designs done. It looks like Anthony has re-invented a wheel, and that's difficult to accept. But his motivation to contribute is no less commendable as a result, and I really do appreciate his effort--- and I suspect that you do too, John. I know he would love to hear that. In the bigger picture, I'll note that the tutorials and FAQs I've seen for gEDA all focus on a pretty specific workflow, which is to turn a schematic into a circuit board layout. There are obviously a zillion different ways that the tools would be useful, and I would really appreciate it if someone would write a few of them down! I'm a Contributing Editor for Embedded Systems Design magazine. If anyone wants to help me co-author a few short articles on using gEDA for things like circuit board layout, schematic capture, simulations, and whatever else it's good for, I'd be more than happy to give you ample credit and to assist in whatever capacity I can to see to it that the documents get published. They should be good candidates for the Wiki, too! If we can get some word out, and commit to documenting some of the really cool ways people are solving problems with gEDA, then I think we'll all get along a _lot_ better. We'll focus our efforts on the parts of gEDA that are truly lacking (and even identify them!). And we'd call more attention to the project, too. "Now who's with 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: spNet v0.9.2 released
Anthony Shanks wrote: > > Haha yeah, except I'm not sure what he says is accurate and I'm not > sure what the resistance is against a hierarchical netlister (without > workarounds like makefiles and such). Every single industry level > netlister I have ever seen does this and I have worked with plenty as > a student and now an engineer in the industry. As someone who manually > looks at netlists on a daily basis, flat netlists are very hard to > read and simulate slow in spice simulators. I'm not even sure a > makefile solution would really work anyway since flat netlisting each > cell separately in a makefile (which I assume John was talking about) > would not be able to automatically produce the subckt statements need > inside the main spice file. Correct me if I am wrong. > All greek to me. I can totally appreciate the power of Spice et al., but the last time I used that kind of simulation was, oh, waayyy too many years ago and I authored the input files with vi--- they would easily have fit on a page. Yea, I use gaf today to capture schematics and lay out boards--- but that's just scratching the surface of what I can do. I'm still only skin-deep, too ignorant to have even a worthless opinion on the topic. :) 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: spNet v0.9.2 released
John P. Doty wrote: > Anthony Shanks wrote: > >> http://spnet.code-fusion.net >> >> More of a beta/trial release, but I've done considerable testing with >> both my symbol libraries and the default gEDA libraries and everything >> for the most part seems smooth. For those of you who aren't familar >> with spNet, it's a spice netlister for gEDA that can netlist >> hierarchical schematics using the spice .subckt directive (which are >> easier to read and simulate faster). >> > Note that there was never any serious difficulty doing this with > gnetlist -g spice-sdb and a makefile. > You're a real buzzkill this week, you know that? :) First you don't like my idea, and now you don't like Anthony's either! :) :) >> It also has many more features >> detailed in the documentation (up to date now on the homepage). If >> anybody has any questions or any issues with spNet let me know. >> I love the website and level of documentation--- keep up the good work. 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
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
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
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
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
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
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
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: 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
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
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: Some thoughts about PCB track attrs in your schematic [was: Re: autorouter fixes and enhancements]
Christoph Lechner wrote: > > But I believe that would be possible to realize even with the current > versions of the tools (gschem, gnetlist, gsch2pcb, pcb). > In gschem one would add a new component to the library with one pin that > has to be attached to the net we want to have special properties. In the > value attribute one would say "width=50mil". > IMHO the best way is to add another script to the toolchain. I'm just a gaf user, and not a very good one at that, but... :) Aren't track attributes just another manifestation of what is already happening with, say, components and footprint attributes already? By that I mean, we're already communicating footprint attributes along with components, so wouldn't that same mechanism allow us to convey track width attributes along with tracks? Granted, I doubt that PCB handles nets by creating a "track" component, but I don't know that for sure. But if something like that were in fact the case, then maybe the remaining work is to just tell PCB to respond to a "width" attribute when it finds one? We can apply attributes to nets in gschem already, and presumably some of those would have to be communicated to PCB to accomplish whatever they are used for today. So the mechanisms for communicating net attributes must already be there. I guess what I'm asking is, are we really talking about a component attribute here, or a net attribute? I was thinking it was the latter. ... or maybe I'm just under-caffeinated. Could happen. :) b.g. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: autorouter fixes and enhancements
Dave McGuire wrote: >I don't know how commercial EDA software handles this either, but > regardless of what they do, this functionality sounds extremely > powerful. > Agreed! My schematics capture more than just inter-connections between components; having PCB able to read that information as well would be really, really, indescribably REALLY handy. b.g. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
