Re: gEDA-user: data directories in a library ( library packages )
Let's try not to change the subject line too much, I need to be able to find all these later to summarize :-) I was just trying to talk in general words about Kai martin's package idea. A package, (or any name for same idea), is a dir with footprint, symbol, simulation model, datasheet links, notes, etc in it. Yup. Each is a type of library, but I think we need to generalize library somewhat to include more than just symbols and footprints. This might be as simple as an additional toplevel directory (example: for simulation models), new well-defined file extensions (example: *.note), or even just standard attributes (example: that link to online PDFs). But it might be as complex as a new file format (open document, zip, GVFS, etc). Chip is not alot better than package. They both have the common word problem. Chip is just a bit more specific, so I thought there would be fewer ways to confuse it than with a category word like package. I don't want to divert the thread into a naming contest, but I think we should either find the right generic phrase that actually describes these (component maps, part database, chip data, etc) or make up something that won't be confused with another standard meaning (partmap, flowmux, heavyifier, chipdir, etc). I think we agree on the concept, we'll pick names later. It might be as simple as just calling it a library depending on how we implement it :-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
On Sat, May 21, 2011 at 7:53 PM, John Griessen j...@ecosensory.com wrote: On 05/21/2011 08:09 AM, Kai-Martin Knaak wrote: The notion of packages can be seen as a means to isolate dependencies. Pins in symbols must match pins in footprints. Simulation models are specific to components. Packages provide a way to keep comments, notes and all kinds of meta data attached. I like the idea of creating a library group containing all info related to a manufactured part or part range. I think the name package could create confusion with layout package used to implement a circuit, some of which have different numbers of pins, so what do you all think of this name for a library group: In the context of a library call them chip data directories, or chips for short. The chip data directories could also be compressed a standard way for ease of distribution. Some library elements don't match the word chip perfectly, such as resistor capacitor terminal block, etc, but people can figure from the context what was meant. On 05/21/2011 08:37 AM, DJ Delorie wrote: I don't think we've come to a consensus on how to ease the heavyification step yet, though, which may require a great deal of coding and redesign. The data dir in a library concept seems to make heavification easier. I'd always want to be able to heavify the symbol or footprint first, then use a script to make them all consistent, not have to do symbol then footprint in that order only. Names keep coming up as I think about relating symbols and footprints and adding heavy data to them. If symbols are not necessarily files, I'm used to the file name being the symbol name or footprint name -- it just seems normal. If a symbols or footprint was just a text section in a larger file, I'd be OK with that, and it would need tags like symbolname=some-kinda-name or footprintname=some-kinda-name. We could easily agree to shorten that down to tags like: symbol=some-kinda-sym-name, footprint=some-kinda-fp without even needing filenames with suffixes .sym .fp. I'd like to see that there is a many to many relationship. Example: You need a SO-8 footprint. With the footprint storage the relationships are a type of footprint backed by many footprints capable to fill the role. If it is directory and files there is a SO-8 directory with the x pcb footprint files that could be used to be a SO-8, like most, nominal, least, hand-solder, and etc. In a relational database plugin it could query for a footprint that provides SO-8 in the footprint table. This helps if you are say making a base schematic that may be made on many different types of boards, or purposes. When purposed it would get flattened and weighted with the particular process applied to it. Next example. For models in simulation. It is a mosfet, a 2n7002, there is a 2n7002 directory with a list of models for say guncap and spice. They also happen to be for different manufacture parts. In the package part it has a variety of parts that you may use, from lets say 4 vendors. The data store can let you simulate the circuit with each vendor, leading to confidence that your alternate parts are good. In lightening a resistor, I'd have the base parameters part of the symbol. Ohmic value, tolerance, power dissipation. This can then let the method of hevifying query a data store to help find your preferred parts. My thoughts on the interaction. Lets say that you draw out the topology of a circuit it has a micro controller and support parts. The uC is a medium weight part, it has the first variant chosen. The uC package is 33 pin or 64 pin part is not yet chosen, but the 33 pin symbol is the first variant, so it is displayed. A heavy part that is the connector that the board will use, every parameter is chosen when the connecter's symbol is placed. The rest of the parts are a bunch of light parts consisting of resistors, capacitors, and LEDs Now that the parts are placed and wired up. We then select the tool/wizzard/script that makes parts heavy, pretend were in the GUI mode and using the tool. So you click on the LED(s) that you want to assign parameters to. The tool knows that it is a LED, so it pulls up the dialog for making that part heavy. It has a interface into the datastore that we are using and I can start drilling down on the values. Kinda like digikey/mouser narrowing down parts. (To DJ's idea) this script might just be an interface to a CGI that is on a part vendors server. Now that the LEDs are taken care of, lets run the script that will make a schematic heavy to take care of the resistors and capacitors. In the schematic you specified the values and tolerances, so the script will take you preferred parts and assign them. The script might generate questions like you do not have a preferred resistor for value 100k at 10% tolerance, would you like to use the 5% tolerance you prefer? or automatically improve tolerances and just warn. Off to
gEDA-user: Dealing with duplicate symbol filenames?
I haven't noticed it in the future-library discussion yet, but one way or the other, I would like some sort of namespacing or subdirectory awareness in linked symbols. For example, I have a project with two symbols named pad.sym on the search path. One is from the standard library and the other is from [1]gedasymbols.org. Every time I start gschem, it complains about the ambiguity. A clunky way to sole the problem would be to encourage more unique filenames in the library and on [2]gedasymbols.org, but ideally, the library manager would be smart enough to know that the symbols are in different namespaces and will not complain. I suppose those namespace could be as simple as different subdirectories or as complex as an added namespace attribute. Does gEDA already a way to solve this problem that I've overlooked? Stephen References 1. http://gedasymbols.org/ 2. http://gedasymbols.org/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
John Griessen wrote: I think the name package could create confusion with layout package used to implement a circuit, I proposed package because eagle uses this term for a very similar concept. Yes, package already has a distinct meaning in the context of electronics. I would not be happy with a variation of library. A lib is a collection of objects of the same kind -- traditionally books. What my proposal aims for, is by contrast a wrap of different classes of objects. The term container comes to mind. This clearly can contain about anything. Maybe, it is a bit too versatile. Worse, it usually means the containing structure, not its content. Next try: packet This can also contain all kinds of objects. It closely avoids the clash with the meaning of package in data sheets. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Bugtracker-cleanup
Hello, I spend some time with the pcb-bugtracker on launchpad. So, I made a list of things, where I think, they can be done without adding new problems. Perhaps, someone of the developer with commit-access can have a look for them. There also are several patches which looks fine to me, but my programming-skills are not enough good to check them (today there are 45 bugs with non-commited patches). Here is the list: a) Patches for documentation - 699306 elements color in manual - 699391 refcard updates - 699476 G-CODE export GUI aa) Patches for the Webside - 704086 download page links to sourceforge b) Patches for GTK-gui - 769815 Fix warnings 'gray50 ignored' for gtk menu - 699496 Detect case-different accelerators as unique - 699510 Cleanup conditional code because GTK 2.12 is required now - 699493 Add plus and minus to possible keyboard-shortcuts c) New features/modifications - 699508 Use GTK dialog for confirming file-overwrite (replaces pcb-dialog-implementation with a dialog given by gtk+) d) Patches to the core - 699478 refdes labels in new layout can't be moved without restart Thank you for taking the time, kind regards, Felix ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
On 05/22/2011 10:37 AM, Kai-Martin Knaak wrote: Next try: packet This can also contain all kinds of objects. It closely avoids the clash with the meaning of package in data sheets. Packet is a good one. If someone is confused they can be told library packet, or see it is in library context. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
On 05/21/2011 11:35 PM, Steven Michalske wrote: So that wires that have the same meaning are still hooked up but new pins are unconnected, or old pins that no longer exist are now not connected. The other wish list ideas sound like where we are headed, but this last is probably beyond coder capabilities unless you know a good robodraw way to get it... John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: chip data directories in a library ( library packages )
On Sun, 22 May 2011 11:27:24 -0500 John Griessen j...@ecosensory.com wrote: On 05/22/2011 10:37 AM, Kai-Martin Knaak wrote: Next try: packet This can also contain all kinds of objects. It closely avoids the clash with the meaning of package in data sheets. Packet is a good one. If someone is confused they can be told library packet, or see it is in library context. Package seems like the right word to me. I've run into at least a few instances where changing from one physical package type to another required a different symbol because the pinout is totally different. I recall one chip I dealt with where the signals physically stayed in place between PLCC and SOIC, but the pin numbering was rotated to move pin 1 from one corner to the center of an edge. Similar for some old DRAMs from back in the day, where certain ZIP packages had a totally different signal-pin mapping than DIP. -- There are some things in life worth obsessing over. Most things aren't, and when you learn that, life improves. http://digitalaudioconcepts.com Vanessa Ezekowitz vanessaezekow...@gmail.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Broken TO92 footprint
Yes, I think there is supposed to be a TO-92A, TO-92B, and TO-92C (the different orders) but nobody paid enough attention, and I'm not sure if this is standard, or merely convention. see attached gif that was stolen from http://www.kss.sd23.bc.ca/chalmers/robotics10/Labs/ComparePNPNPN/howExplained.htm This is not good, the user has to remember that A means ECB, B means EBC, F means SDG, K means GAK (for SCR)... . Such suffix is also used for mechanical variant of the package like in TO220AB Wojciech Kazubski ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
On May 21, 2011, at 8:30 PM, Kai-Martin Knaak wrote: Unfortunately, gschem does not descend into subdirectories. So you have to give each and every dir in the config. Ah, but it can. I've been using lines like: (component-library-search Components) for years in my gafrc files. Components is a directory containing directories of symbols. I can't remember where I learned about this. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Meta (was: Reinventing the wheel)
On May 21, 2011, at 9:30 PM, DJ Delorie wrote: 1. Nobody wants to kill support for anyone's personal process What people want want what they actually do are two different things A little trust here is needed to get us past the what should we do phase and into the how can we do it phase. The difficulty for me is that when I see potentially flexible changes discussed in inflexible ways by developers, I strongly suspect that the developers will act as they write: they will actually implement something inflexible. Consider back annotation. Why not just call it annotation? An annotation tool can potentially be used either backward or forward, but I fear a developer who only perceives the backward case will find a way to restrict it to that case. When a mechanism in gschem is potentially applicable to a flow using any layout tool, not just pcb, why not use layout tool rather than pcb in the discussion? That will help keep the diversity of uses in everybody's mind. The use of neutral language would go very far toward building my trust. I've said this plenty of times in the past, but it bears repeating - we want the common uses to be easy, and the uncommon uses to be possible. Easy is a personal judgement. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Gerber magic numbers
Hey all, I am cleaning up the unit handling for the gerber exporter, using the guide at http://www.linux-cae.net/PCB/rs274xrevd_e.pdf Things are mostly straightforward, but I am lost as to the /10 factors in /**/ /* Utility routines */ /**/ /* These are for films */ #define gerberX(pcb, x) ((double) ((x))) #define gerberY(pcb, y) ((double) (((pcb)-MaxHeight - (y #define gerberXOffset(pcb, x) ((double) ((x))) #define gerberYOffset(pcb, y) ((double) (-(y))) /* These are for drills */ #define gerberDrX(pcb, x) ((long) ((x)/10)) #define gerberDrY(pcb, y) ((long) (((pcb)-MaxHeight - (y)))/10) #define gerberDrXOffset(pcb, x) ((long) ((x)/10)) #define gerberDrYOffset(pcb, y) ((long) (-(y))/10) Why are the drill numbers divided by 10, and why are they output with leading zeroes? Also, these macros are only used in gerber_set_layer, and the output code in this seems indistinguishable from that of set_line (both are X%dY%d\015\012). Could someone knowledgeable about the gerber format and how pcb outputs it help me out here? Thanks. PS: Can I replace the \015\012's all over gerber.c with \r\n's? -- Andrew Poelstra Email: asp11 at sfu.ca OR apoelstra at wpsoftware.net Web: http://www.wpsoftware.net/andrew/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Meta (was: Reinventing the wheel)
[snip] The difficulty for me is that when I see potentially flexible changes discusse d in inflexible ways by developers, I strongly suspect that the developers wil l act as they write: they will actually implement something inflexible. Yes, the developers will do whatever they want (regardless of whether you think it is flexible or inflexible). -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Meta (was: Reinventing the wheel)
[snip] Yes, the developers will do whatever they want (regardless of whether you think it is flexible or inflexible). And let me further qualify this statement with this: John Doty, if you really want to influence the developers, then you should step up and create something (like a prototype) that shows your ideas that others can play with and evaluate. Thanks, -Ales ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
John Doty wrote: On May 21, 2011, at 8:30 PM, Kai-Martin Knaak wrote: Unfortunately, gschem does not descend into subdirectories. So you have to give each and every dir in the config. Ah, but it can. I've been using lines like: (component-library-search Components) for years in my gafrc files. Just tried again and it didn't work on on my box. I tried this line: (component-library /home/kmk/geda/gedasymbols/www/user/kai_martin_knaak/symbols) In the choose-Dialog of gschem this got me none of the symbols in the various directories beyond .../symbols . Maybe a setting in system-gafrc or system-gschemrc? ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Bugtracker-cleanup
Thanks for taking the time to report the list - status update below. On Sun, May 22, 2011 at 06:01:49PM +0200, Felix Ruoff wrote: Here is the list: a) Patches for documentation - 699306 elements color in manual Committed. - 699391 refcard updates Committed. - 699476 G-CODE export GUI Commented on the tracker - we need eps files updated Makefile.am aa) Patches for the Webside - 704086 download page links to sourceforge Commented - Peter wanted to run some tests with robot on this bug b) Patches for GTK-gui - 769815 Fix warnings 'gray50 ignored' for gtk menu Committed. - 699496 Detect case-different accelerators as unique - 699510 Cleanup conditional code because GTK 2.12 is required now Committed. - 699493 Add plus and minus to possible keyboard-shortcuts c) New features/modifications - 699508 Use GTK dialog for confirming file-overwrite (replaces pcb-dialog-implementation with a dialog given by gtk+) d) Patches to the core - 699478 refdes labels in new layout can't be moved without restart Cheers, -- Krzysztof Kościuszkiewicz Simplicity is the ultimate sophistication -- Leonardo da Vinci ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Hi Everyone, I'm a new gEDA user and someone who's just learning electronics design and basically everything that comes with it. I started using Eagle (since that's what most people in the Arduino community use), but the limitations of the free/non-profit versions + the cost of moving to a professional license should I ever want to sell my project for a few bucks, made me quickly realized that Eagle wasn't going to work for me. Anyways, there's been quite a lot said about new users like me and so I figured I'd give my .02: As a new user I don't care what direction you go. Light, heavy, whatever. I suspect most gEDA newbies are like me: pretty confused what the differences really mean in practice. You guys discuss back and forth which is better which is great, but not only do I have no clue, I don't even have the experience to make an informed decision. Mostly, I'm just hoping to find the parts I'm using. For the rest, I just want some directions of how to make the symbols/footprints/etc of a good enough quality that not only do they work, but that I can share them with the rest of the gEDA community. Mostly, I just want gEDA as a project to say this is the officially supported and recommended way of doing things, adjust your workflow accordingly. At first I thought creating symbols was hard, and so I asked around and learned it was actually really easy and I can churn them out fast enough where it isn't an issue anymore. Point is, I never thought this would be easy, but I'm willing to put in the effort if I know which direction I should go. If there is a consistent story about how this is supposed to work, I'm sure people can improve the UI/experience to make it easier, but right now I just feel a bit lost and that makes learning a lot harder then anything else. That and newbies like me aren't very likely to help code- we don't have enough vested in the project to do that and in my case at least, I've got my own projects that I'm supposed to be working on. What newbies like me are more then willing and able to do though is create symbols/footprints etc. Just need to make it clear what you want and make it easy to submit for review/inclusion. Thanks for reading, Aaron -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin carpe diem quam minimum credula postero ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
DJ Delorie wrote:
These would be data structures that can contain all information
relevant to an entity us humans like to build electronics from.
I don't think this conflicts with any of the other ideas we've
proposed.
I don't think so, too. :-)
But a database of packets might look different from a database
that does the assignment of footprints, data sheets and meta
data by some other means.
It's almost like each component would be a micro-library of
its own.
In a sense, yes. The scope of this micro-lib up to the designer.
Extremes, I can think of are:
A packet for a specific microprocessor.
* a model name
* main symbol
* a power supply symbol
* a footprint
* a link to the data sheet
* acquisition information
* and a bunch of notes.
This is like a container with different kinds of objects.
A packet for NPN transistors.
* alternative symbols (with circle, without, different arrows...)
* alternative models (BC..., 2N... )
* alternative footprints (TO92, TO220, TO347, SO23, SOT223, pads
optimized for hand soldering, optimized for reflow, ...)
This is like a little library with different objects of the same kind.
Likewise, PCB has footprint variants you should be able to switch
between during layout, like RESC1608{M,N,L}.
The back-annotation problem remains. Is there any sensible way to do
back-annotation with a hierarchy where a subsheet is used multiple
times?
In schematics and in layouts it may be referred to with a unique name,
Hmmm... we need a way to scope names, I think.
true.
Maybe require that packet names are unique within a library. They
could then be referred to with libname/packetname. If only the packet
name is given, then there may be a list of libraries to search from.
Maybe come up with an
URL structure for specifying library/component/symbol/script/whatnot
This seems complicated. Who would specify this URL? If it is the
user in a file chooser like dialog, then this means five point'n clicks.
Or do the / mean alternatives? Then it is more like a search pattern.
---)kaimartin(---
--
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
It worked for me in gschem 1.6.1.20100214. Thanks for the tip, John! Kai, try (component-library-search /home/kmk/geda/gedasymbols/www/user/kai_martin_knaak/symbols) instead of (component-library ...). Stephen ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
Stephen Trier wrote: Kai, try (component-library-search Oh, now I see! Must have been blind before. I'll add this to the wiki and to the tutorial, too. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
On May 23, 2011, at 7:30 AM, Kai-Martin Knaak wrote: (component-library-search Components) Just tried again and it didn't work on on my box. I tried this line: (component-library /home/kmk/geda/gedasymbols/www/user/kai_martin_knaak/symbols) ^ Should be: (component-library-search /home/kmk/geda/gedasymbols/www/user/kai_martin_knaak/symbols) John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: This morning's treat
Well, here I am in Osaka. It's Monday morning, and I just saw the prototype Soft X-ray Imager (SXI) for the ASTRO-H space mission under test. Much of the electronics, a large, complex circuit board and some mixed-signal ASICs, is of my design, using gEDA. I've been working on this for six years, now, and it's wonderful to see it all built and plugged together. So, thank you to all who made this possible. It's a beautiful morning. John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ j...@noqsi.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: An opportunity to fix the symbol library
Stephen Trier wrote: Kai, try (component-library-search/home/..snip../symbols Unfortunately, it works only for the first layer. Symbols in ../symbols/analog/diode are still ignored. In other words: gschem does not descend recursively into sub dirs. ---)kaimartin(--- -- Kai-Martin Knaak Email: k...@familieknaak.de Öffentlicher PGP-Schlüssel: http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53 ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
But a database of packets might look different from a database
that does the assignment of footprints, data sheets and meta
data by some other means.
Yes, but that's for the how do we do it phase. At this point, if we
can agree that hiearchical storage is good and that we'd like to be
able to do both old-style, sym-meta-fp style, and patcket style
within this container format (or other way of collecting/defining a
library) that would be good enough for now.
This heirarchy could be as simple as our existing directory structure
(or url), or a more complex container format. Functionality depends
more on how you manage the data's meanings, not how to manage the
data's bits.
But think of this... if we had a library that could contain varied
types of data (sym/meta/fp/url/text), one type being another library,
does your packet idea become one way of organizing the data in the
library? Or is more needed?
Likewise, PCB has footprint variants you should be able to switch
between during layout, like RESC1608{M,N,L}.
The back-annotation problem remains. Is there any sensible way to do
back-annotation with a hierarchy where a subsheet is used multiple
times?
I got halfway through typing completely different problem when I
realized how it's related.
The unrelated part: the netlister needs to give each element enough
information to identify the origin of it's element-specific metadata,
such that it's at least possible (with sufficient technology) to
update that origin. This is a netlister problem, in that it must
flatten the heirarchy enough to realize the separate instances of
physical parts, and record that flattening in the element.
The related part is - what *is* the origin of that metadata?
Hmmm... as long as the netlister is consistent in flattening the
heirarchy, any element-specific data need not be back-annotated to the
schematic. It need only be back-annotated to the netlister, so it can
merge that data with the schematic data to update the layout. In this
case, the origin is the element itself.
For non-element-specific data (i.e. applies to all instances of the
heirarchy), I think the origin remains in the schematic, since pcb
doesn't understand heirarchy enough (or at all).
future
But that doesn't cover the potential case where pcb might support
hierarchical layouts (my powermeter is an example where that would
have been handy). Same solution would work at least - send
hierarchy-specific data to the netlister, so it can apply it to the
whole heirarchy.
I think the general case of a heirarchical schematic with *one*
element having special data, being back-annoted to the *schematic*,
just isn't going to happen - there is no *one* symbol that's unique to
that data, in which to store it, at least if you use separate *.sch
files for blocks in the heirarchy. Only if you view the *.sch by
navigating the heirarchy could gschem even hope to juggle all the
annotations enough to show you the as-built.
/future
This seems complicated. Who would specify this URL?
Who specifies URLs for the Internet?
In this case, I think the URL comes from two parts - where the library
is (top-level at least) (which can be hidden from the user in the
chooser) and the location *within* the library, which is defined by
the library author, and corresponds to the tree we already show in the
chooser.
___
geda-user mailing list
geda-user@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: This morning's treat
On 05/22/2011 08:57 PM, John Doty wrote: I've been working on this for six years, now, and it's wonderful to see it all built and plugged together. Congrats John. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
Yes, any annotation to just one instance of a package in a layout would back annotate to an instance attrib attached to a symbol instance in a schematic, Or to an instance attrib on the *parent* schematic, that says when you descend here, use these attributes IMHO this goes back to my observation that a layout knows frmo which schematics it came, but a schematic does not know to which layout you refer. In a heirarchy, only the higher level schematics know what the heirarchy is, the sub-schematics don't, so the higher ones need to retain the instance-specific data. Otherwise, the first time you re-use that sub-schematic in a different project, the instance data will be horribly misplaced. A way to netlist hierarchy with respect to instances without flattening-renaming-flat first is needed to do back and forth annotation and cross probing. You just need a way to store a path to the symbol in the element. It doesn't have to be the refdes, it just has to be something gschem/gnetlist can use to refer to the symbol in the hierarchy. It *could* be a refdes, or it could be an array of GUIDs encoding the path through the hierarchy. However, consider a slotted part: you'd need one path *per slot*. So if you use two quad NAND gates for one gate in each of eight instances of a subcircuit, and you change the package for one of those quads, you need to know which four of the eight subcircuits are affected. And if you gate-swap between packages, you then need to know which two subcircuits get their gates swapped. And since I don't use heirarchy, I can only assume it's even more complicated than that ;-) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On 05/22/2011 11:40 PM, DJ Delorie wrote: And if you gate-swap between packages, you then need to know which two subcircuits get their gates swapped. That might become an instance label like: I1.1 for slot 1 I1.2 for slot 2 And since I don't use heirarchy, I can only assume it's even more complicated than that;-) I don't think specifying it is any more complicated. Chip design software does all this and it looks like module-name attrib attached to a symbol in the higher level schematics, (none on a leaf instance), and instance numbers such as I1 or for convenience, used with buss labeling, stacks of instances designated 11:16 or I1:32 with busses labeled signal_a[0:31]. Implementing it may be harder than falling off a truck though... John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
gEDA-user: Draft consensus on: Solving the light/heavy symbol problem, what phase
I went through the whole thread again, in chronological order, and tried to maintain a current opinion for each of the participants as ideas were tossed around and people changed their minds or agreed/disagreed with others' proposals. Then I collected the results and tried to distill the essence of what I thought people generally agreed on (most people expressed a positive opinion) and some things that were at least uncontested (some people expressed a positive opinion, with no disagreements). I further tried to remove any how do we do it ideas, leaving behind the what do we need to do portions. At this point, please reply if you feel I have misrepresented the data at this phase. Otherwise, wait, and I'll write up a starting point for the how do we do it phase. Although, some of us (me included) are guilty of jumping the gun on that one anyway :-) GOALS (reiterated in summary) (1) Easy to heavify (not just emacs) (2) Easy for new users to make first board (3) Easy for new users to do first simulation (4) Inertia - preserve massively scripted flows and massively GUI flows. GENERAL AGREEMENTS [Note: you may substitute model for footprint if you prefer] We need to be able to support both small self-consistent heavy libraries as well as clean light libraries. It should be easier to heavyify objects in light libraries. A new user should have access to one or more small starter libraries of self-consistent heavy symbols and footprints. We need to support multiple libraries at the same time within the tools. Relations within a library should prefer matches within the library over matches found elsewhere. Libraries should not be restricted to local files - remote libraries should be usable as-is. Specifically, integration with gedasymbols.org should be better. The symbol/footprint duopoly in our current library is insufficient for our needs. One or more additional categories of information is needed, such as: * symbol class, in which multiple graphical variations of a symbol can be grouped. * Likewise, footprint classes * Some form of data (metadata) which matches a symbol and footprint with additional data (example: pin mapping, part numbers, values, datasheets) in order to represent a specific component. A library may contain both symbols and footprints, and other related data that may be needed for completeness. Each aspect of using the geda suite should be easier to learn, especially for new users, especially heavyifying. UNCONTESTED IDEAS Library browser should allow for filtering, searching, or other means to narrow down the list of options. Filter preferences should be able to be preserved across sessions. Libraries should allow for arbitrary heirarchy within them, with a way to scope a reference to something in the library. Links in the library should have preference rules for finding their target (i.e. a footprint= looks in the symbol's location (or metadata's location) first, etc). The tools and libraries need to allow a concept of a chip, packet, package, part, component, whatever - grouping all the relevent data (or references to) for a specific whatever in one place. *Use* is optional, but *ability* is needed. gattrib needs more integration with the various libraries (search, preview, auto-fill, etc). gschem should have more of this too, to help the user heavyify symbols. It must be possible to change some aspects (where practical) of the design from within pcb/sim (such as selecting a footprint/package, or pin/gate swapping, or a passive's parameters). ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
