Re: gEDA-user: Solving the light/heavy symbol problem
This post kind of blew out a bit - TLDR version - I have a database idea that may be helpful in the pin swapping under discussion. The database would provide a device representation that captures *everything*. The database would help inform the pin swapping decision process rather than provide any gEDA plugin automation. It would be a standalone tool (at this stage). long version... I have some thoughts on this - as my original reason for starting a database for managing symbols and components was trying to come up with some sane method of capturing all possible configurations of an ARM chip while only displaying those that are currently in use in the schematic. I am not convinced that the schematic is the correct place to capture the full detail of all possible functional variations of a symbol, otherwise the component symbol becomes bloated or split into many many subcomponents either of which is likely to be unreadable or obfuscated. I want a schematic that describes succinctly what the design is intended to do. I *do* however need to have some representation somewhere that captures what a device is capable of so that I can implement the design as easily as possible - the idea is to not have to manually create a new component symbol by hand for each design variation. Pin/function swapping to enable better routing I think *has* to be a fairly user involved process - although I suppose in theory it may be somewhat possible to tie into an autorouter of some description... off topic - but would it be possible to have a second class of rats nest that is one link per function? - ie 1 point to point line to indicate a data bus path etc - or just colored rats-nest where common function nets are color coded/off topic I think DJs description of pin swapping makes sense - it seems like a more complete version of slotting. In the design I have been working on recently, I used a slotted resistor package. The process for changing which device was used was actually very easy with the 'import schematic option'. I had the schematic and layout open side by side - hover the mouse over the footprint to determine the net - then swap the slot in the schematic and hit import schematic - then 'O' in PCB to refresh the rats nest. This was quite pleased at the efficiency, and pushing the design flow from schematic to layout makes sense to me. I could be handy to be able to pull some schematic information from the PCB, however how you indicate the change to the net from pcb is beyond me. (I don't think laying copper would be correct - what if you had an accidental short somewhere?) More on the capturing of functional component information - my current plan is to create an entirely self sufficient database of component information. This would redefine the concept of a device to encompass all possible variations of the device. (noting that not all of them are required for a device description to be useful) Eg, * A logical device is made up of a number of logical pins (one pin may exist across a number of device packages/footprints) * A logical pin can be tied to a number of functions (eg UART-TX, SPI-MOSI) * A function can be grouped in a functional class (eg UART) * A physical-device is defined by joining a device, footprint and pinout * The pinout mapping allows a logical pin to be defined once and remapped across multiple packages - ie DIP, SOIC, QFN * Functional class awareness allows a package with multiples of the same function to be swapped with a degree of automation, including grouping pins that together form a functional group (ie a data or address bus, a serial port etc) * Pins and functions are somewhat separated - so it's easy to handle the situation where UART1_TX can be on pin 15, or pin 47. * This allows for the possibility of remapping a generic UART function between UART_1 and UART_2, along with the option of configuring UART_1 to use pins 15 and 16, or pins 47 and 48. This concept does not in any way replace DJs description of pin swapping - this is more about the capture of information than the mechanics of an implementation at this stage. I think I have the bulk of the database schema worked out, with a few minor details about some of the linkages to finalize - the harder part is providing a workable interface to the information. Particularly an efficient way to capture and describe the information in the first place, and then methods of manipulation and output. My initial thoughts are to have some of the information captured from a spreadsheet - this is most likely the easiest way to enter the data that is read from a datasheet - this can then be pulled into the database (similar to tragesym I suppose). The next issue is then view and manipulating the data - again my first
Re: gEDA-user: Solving the light/heavy symbol problem
-Original Message- From: geda-user-boun...@moria.seul.org [mailto:geda-user-boun...@moria.seul.org] On Behalf Of John Doty Sent: Tuesday, May 24, 2011 3:05 PM To: gEDA user mailing list Subject: Re: gEDA-user: Solving the light/heavy symbol problem On May 24, 2011, at 9:43 PM, DJ Delorie wrote: My flows are also heavily scripted, so yes, I'll remember. The underlying data and low-level tools follow the scripting paradigm - stepwise progress from A to Z via simple apps that interact with simple data. The GUI needs to *hide* that, not replace it, making the underlying data *seem* integrated and easy to manage, when in fact it is not. This is where we disagree. The GUI needs to make the data easy to manage, but at the same time it needs to *reveal* its machinations. If it hides everything, the user winds up either: The easy answer to this is to do what Cisco does with their ASDM software: you can set an option that tells it to present to the user the exact text of every command it is sending to the router. That's how I've learned to manage my routers. There are a few complex functions that can't be done through ASDM, for which you need to use the command line, but by the time you're doing those, you already know your way around the router fairly well. The exact same mechanism would likely work very well for GEDA, allowing users to learn the command line usage while getting help from the GUI along the way. Adding an option to dump the commands to a text file as they're executed through the GUI would enable to develop fully fleshed-out work flows as well. This also helps ensure that the developers don't do anything that REQUIRES the GUI, since every command has to be displayed to the user along the way. Dave ___ 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
The easy answer to this is to do what Cisco does with their ASDM software: you can set an option that tells it to present to the user the exact text of every command it is sending to the router. PCB is close to this - many of the things it does already go through the action (scripting) layer anyway. There are a few things that bypass it, like coordinates. I'm willing to help you learn enough of the innards of PCB to prototype a convertion to all-script-logging mode, if you're interested. ___ 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
David C. Kerber wrote: The easy answer to this is to do what Cisco does with their ASDM software: you can set an option that tells it to present to the user the exact text of every command it is sending to the router. I have seen some CAD suites do this. IIRC, these were MicroStation, varicad. I'd appreciate this feature. ---)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
On 05/24/2011 07:22 AM, DJ Delorie wrote: if it's layout-specific data, the copy in the layout is correct. Perhaps we need to keep track of whether the data in the layout and schematic originated in that file, or is the result of user changes elsewhere being imported. But any solution depends on (1) allowing data to originate from multiple places, and (2) sane rules for which wins. This is a concept I like and think it could be maintainable. The sanity of the data-conflict-rules would come from simplicity, so they don't grow to be high maintenance. Call it data-conflict-rules for resolving effects of two way data flows between tools. On 05/24/2011 07:37 AM, DJ Delorie wrote: Yup. I had proposed using the pin*label* as the identifier, not the pin*number*. The label is owned by the schematic, but the number is owned by the partdb or layout. That lets you, for example, change the package in layout without having to change the schematics first. This will get involved with pin swapping as in FPGAs or other programmable chips. Each symbol for a pin function programmable chip will have either a large number of variants or be able to adapt pins with the standard positional numbering to have any functional labeling. I think pin swapping for layout purposes where identical functions are swapped in groups, such as I2:NAND-in-1 and I2:NAND-out-1 swap with another pair in same or another package should not involve changing package labels, just changing the netlist. Otherwise my head starts to twirl in confusion over how to support it or maintain the tool that does it. IOW, my idea of pin swapping convenience would be a plugin that calls for a new netlist to be made, perhaps saving a history of netlists recently asked for, then loads that new netlist, and maybe does some topology equivalence check. That reasoning comes from the plugin's purpose being swapping pins for better layout while preserving circuit function and logic. On 05/24/2011 02:04 PM, John Doty wrote: The GUI needs to*hide* that, not replace it, making the underlying data*seem* integrated and easy to manage, when in fact it is not. This is where we disagree. The GUI needs to make the data easy to manage, but at the same time it needs to*reveal* its machinations. I like the way of hiding from normal view, while keeping a log of commands used such that the state of the document(s)/project would be the same if done by the GUI or replaying the commands. This is especially valuable in capturing flows of work done first with the GUI, to turn them into scripted macro sections you can do in other positions, or use as basis for a parameterized script. 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
Otherwise my head starts to twirl in confusion over how to support it or maintain the tool that does it. True. Please re-read my pin mapping doc, and see if your swirling head can come up with a solution ;-) http://www.delorie.com/pcb/pin-mapping.html Maybe the solution for FPGAs and the like, is to use something other than schematics - something more appropriate to such a dynamic component. ___ 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 Tue, May 24, 2011 at 01:43:08AM -0400, DJ Delorie wrote: Hierarchy isn't the only reuse scenario. Consider transition from breadboard to prototype to production. A top-level schematic might not change, even though attributes of parts might change (different packages, tighter specs, ...). In that case, the instance-specific data can't be in *any* schematic. Up to now, we've been using the schematic as the master files for the design. Perhaps this is a bad idiom? Perhaps the design should be some other data, which uses the schematic as but one of its inputs? Maybe in the backend it is a bad idiom (that is, gschem should be saving the schematic and design as separate beasts, maybe in a gzipped collection or something). But from the user's perspective it makes sense. When you first set out to design a circuit, you start by scribbling out a block-level schematic, then fleshing it out into a real schematic, long before you care about specific parts or footprints or decoupling caps. Probably these high-level schematics would be scribbled on the back of an envelope or on a whiteboard rather than in gschem, but I think it reflects a schematic-oriented view of the circuit for most people. Plus, simulations and ratsnests depend on the schematic data, so it is a sensible base for design work. -- 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: Solving the light/heavy symbol problem
Maybe in the backend it is a bad idiom (that is, gschem should be saving the schematic and design as separate beasts, maybe in a gzipped collection or something). But from the user's perspective it makes sense. How we organize the data, and how the user interacts with it, need not be the same :-) ___ 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
How we organize the data, and how the user interacts with it, need not be the same :-) I didn't read the complete threat so if I miss the point or if I repeat anyone I'm sorry. Is it not possible to make a top level program that launches the different programs (gschem, pcb, simtools, .)? The top level program can have it's own file with the meta data and cross references to the other files (the refdes maybe). The top level program can have a wizard to help new users to heavyfy the standard symbols. The top level program can have a check/lead to help setting up a simulation project/layout project/IC design project/whatever project. The top level program can call gnetlist to connect it all together. The top level program can have an import/export function to include sheets/pcb designs from other projects. This way you also have a backwards compatibility path (all additional data is stored in the TLP file), not important I know, but still... Just my €0.02 Robert. ___ 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
Is it not possible to make a top level program that launches the different programs (gschem, pcb, simtools, .)? Yes. In fact, this has been done. However, it serves to collect the various files that make up a design, not the information *in* the design. The underlying tools still deal with the same files and data as they would without a GUI, and the underying tools still force the user to jump from tool to tool to get various tasks done. What I think users want is to have the underlying tools be more aware of the other sources of data in the design, and each other, so that the GUIs appear to be more integrated despite being individual tools and datasets underneath. This may require some high-level these are the files in your design also, but it's a slightly different problem to solve. But an even different is the problem of what *design* data goes in which file. This part is not backwards compatible, because we'd want to move data out of the other files (sch, pcb, whatever) into a new container. Consider: if we have N steps in our flow, we currently have N files and N tools, each of which deals with their one data file, with converters between them. But what if each tool could interact with the data files from step N-1 and N+1 also? In the past, this has meant that gschem knew about pcb's file format, and pcb knew about gschem's (via gnetlist). But a new container between schematic and pcb (for example) would allow these two steps to have a common spot to store common data, without either needing to know about each other's private data. Now add to that, plug-ins for each tool that know how to directly communicate with other running tools related to the design (gschem, pcb, gerbv, icarus). Now, each tool has its own data and responsibilities, and *could* act in isolation, but also *could* appear to be integrated with the other tools. It would be *as if* there were one design file that all the tools knew about, when in reality there isn't one. That's the dichotomy I was referring to - how the low-level design data is stored, and how the tools interact with that data on behalf of the user. ___ 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
I really don't want any *major* changes to the core workflow and UI TBH. The changes that would make this a more complete tool (for me anyway) are: PCB: - better control over polygons. Ie better awareness/ability to tie to nets, built in crosshatching (intstead of solid), and an option to hide all polygons without having to put them on a separate layer (this messes with DRC) (thin draw poly is cool though!) - footprints: native text capability, polygons, manual solder-mask, manual paste mask - A manual paste layer - Not sure about how to describe this, but I think it comes under the back-annotation editing of symbols... PCB is a little thin on the ground when it comes to editing elements on the fly (can you even edit text from the gui once placed?) gschem: not too many changes as I see it... - A footprint viewer - when selecting/setting a footprint it would be nice to have a preview (this could most likely be done as some sort of plugin) - A more complete channelisation/subcircuit/bus concept - basically just tie buses and subcircuits together (i think I may try and do this myself - i've asked about it before and got some useful feedback) Light vs heavy I think this has all been said but *my* summary is * you can never have *all* the heavy symbols - and chances are most of your heavy symbols will be useful as is to less than half gEDAs users. * purely light symbols leave beginners wondering why their projects don't compile out of the box solution (as discussed) - set up a default beginner/base library with a subset of the most commonly used components (defined by how much time and effort people are prepared to put in I guess) that is shipped - don't do anything to over complicate the heavyfication process - as it stands is fine :) I think tying gschem and pcb together more closely is a separate task - DJs database. I've been thinking of attempting to do this myself for some time - i'm as far along as writing a base schema to capture the core information... A functional component can take on many forms - the alignment of function to pin and whether the function is available is interdependent with the choice of footprint, functions can be remapped amongst pins (look at most ARM chips). Ideally one should be able to define a functional requirement in the schematic, swapping which pin provides said function in the final layout shouldn't be a major chore. I don't think this is an improvement that needs to be made in gschem - gschem is for schematic capture, which it does fine. Parts/symbol/component management is a separate task, so long as gschem doesn't hinder this process great - if it can include some plugins to make the task better integrated (such as a footprint preview) even better. A tool like gschem shouldn't be tied up trying to define and handle all variations of what any given person thinks makes up a symbol. It already has the capability to have arbitrary text attributes - that's enough. Just link the gschem symbol to the database/tool (separate program) that handles the various symbol permutations via a unique ID of some description or other... Anyway - the database idea has been looked at before, and from memory even implemented somewhat; so its nothing new. Geoff (If anyone is interested in the schema I've started [1]http://nixotic.com/partsdb.png) References 1. http://nixotic.com/partsdb.png ___ 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: Up to now, we've been using the schematic as the master files for the design. Perhaps this is a bad idiom? It is not just us. it is the traditional way to look at an electronics project. Schematic, layout and BOM contain all the information needed to reproduce. Of course, the EDA may keep the data in some other form and derive these documents on the fly. But this would make the work-flow more complicated. You'd have a hard time to re-integrate a layout, once it has diverged from the schematics. This is one of the major blunders of eagle. There is no decent way to reunite layout and schematic after you changed one without the other. I have seen more than one project break this way. ---)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
On May 24, 2011, at 2:43 PM, DJ Delorie wrote: Up to now, we've been using the schematic as the master files for the design. Perhaps this is a bad idiom? Perhaps the design should be some other data, which uses the schematic as but one of its inputs? If you have a hierarchical design, one extra thing you need to track somehow is which schematics are at the top level, so you know which ones to feed explicitly to gnetlist. There may also be variant designs based on different but overlapping sets of schematics (my chip designs are like that). I also use pins2gsch a lot for connector maps: maintaining connectors as drawings is a pain, and not very illuminating, I think. In this case, the master is the .tsv that defines the map, not the .sch that's derived from it. I used this for the CCD driver board whose picture I posted earlier, and I'm really glad I did: the folks on the other sides of the interfaces kept changing pin assignments, and a table is much easier to fix than a drawing. So, already, for me the schematics themselves don't completely define a design, at least in my big project flows. 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: Solving the light/heavy symbol problem
On May 24, 2011, at 3:33 PM, DJ Delorie wrote: How we organize the data, and how the user interacts with it, need not be the same :-) Please remember that what interacts with the data may not be a human user, but a script. The user behind the script must find the the organization sufficiently comprehensible that the script can be constructed to penetrate it without human help. This is exactly why GUI so commonly poisons scripting, because GUI is generally designed to facilitate human interaction, not avoid it. 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: Solving the light/heavy symbol problem
On May 24, 2011, at 4:31 PM, myken wrote: How we organize the data, and how the user interacts with it, need not be the same :-) I didn't read the complete threat so if I miss the point or if I repeat anyone I'm sorry. Is it not possible to make a top level program that launches the different programs (gschem, pcb, simtools, .)? The top level program can have it's own file with the meta data and cross references to the other files (the refdes maybe). The top level program can have a wizard to help new users to heavyfy the standard symbols. The top level program can have a check/lead to help setting up a simulation project/layout project/IC design project/whatever project. The top level program can call gnetlist to connect it all together. The top level program can have an import/export function to include sheets/pcb designs from other projects. This way you also have a backwards compatibility path (all additional data is stored in the TLP file), not important I know, but still... Well, the classic TLP is make, and gEDA works pretty well with it. Of course, make is old-fashioned and rather crude. It's easy to create something prettier, but it's very hard to create something that works better. 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: Solving the light/heavy symbol problem
I really don't want any *major* changes to the core workflow and UI TBH. Understood. The changes that would make this a more complete tool (for me anyway) are: Yup, all discussed before. One impossible task at a time please :-) (can you even edit text from the gui once placed?) the 'n' key (change Name, originally for refdes, but now for any text) I think this has all been said but *my* summary is Yes, I think your summary aligns with what we discussed. ___ 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
It is not just us. it is the traditional way to look at an electronics project. Schematic, layout and BOM contain all the information needed to reproduce. We currently derive the BOM from other sources (well, from the schematics). PCB can derive its own BOM as well. The metadata idea would flip this, and have the BOM be an *input* to the process, not an *output*. This is one of the major blunders of eagle. There is no decent way to reunite layout and schematic after you changed one without the other. I have seen more than one project break this way. Yeah, that was a tough problem to solve, until I realized (well, considered :) that the layout-specific data does NOT need to be reunited with the schematics. The key problem is, if you have conflicting information in two places, which is correct? My though was: if it's layout-specific data, the copy in the layout is correct. Perhaps we need to keep track of whether the data in the layout and schematic originated in that file, or is the result of user changes elsewhere being imported. But any solution depends on (1) allowing data to originate from multiple places, and (2) sane rules for which wins. ___ 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
Pin numbers are a bit harder than most other attributes in the present state of gnetlist, because the front end employs pin numbers internally to track pin identity. Yup. I had proposed using the pin *label* as the identifier, not the pin *number*. The label is owned by the schematic, but the number is owned by the partdb or layout. That lets you, for example, change the package in layout without having to change the schematics first. And, of course, there's no reason that the rules need to come from a single place, using a uniform format. I hadn't gotten around to thinking about where the rules came from, just that they should exist. I suspect any solution would need to be available to gschem and pcb also (or anything else), though, for previews and manual changes. I did think about where the *metadata* would come from, and some API to hide all that behind. I'm waffling between something like HTTP/CGI (automatic integration with any web server) or SQL (powerful query language). ___ 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
Please remember that what interacts with the data may not be a human user, but a script. The user behind the script must find the the organization sufficiently comprehensible that the script can be constructed to penetrate it without human help. This is exactly why GUI so commonly poisons scripting, because GUI is generally designed to facilitate human interaction, not avoid it. My flows are also heavily scripted, so yes, I'll remember. The underlying data and low-level tools follow the scripting paradigm - stepwise progress from A to Z via simple apps that interact with simple data. The GUI needs to *hide* that, not replace it, making the underlying data *seem* integrated and easy to manage, when in fact it is not. ___ 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 Tue, 2011-05-24 at 15:24 +0900, John Doty wrote: On May 24, 2011, at 2:43 PM, DJ Delorie wrote: I also use pins2gsch a lot for connector maps: maintaining connectors as drawings is a pain, and not very illuminating, I think. In this case, the master is the .tsv that defines the map, not the .sch that's derived from it. I used this for the CCD driver board whose picture I posted earlier, and I'm really glad I did: the folks on the other sides of the interfaces kept changing pin assignments, and a table is much easier to fix than a drawing. So, already, for me the schematics themselves don't completely define a design, at least in my big project flows. It has been my wish for some time that a netlist / BOM type input file becomes more first class within gEDA. Net lists / BOM are the about the most fundamental piece of data within an EDA tool. Schematics are just one way of inputting that, and PCB layouts are just one way of embodying it. It seems un-warranted to make a schematic file from a data-table when the end output is just the data-table in a different format. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ 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 Tue, 2011-05-24 at 16:56 +0900, John Doty wrote: Well, the classic TLP is make, and gEDA works pretty well with it. Of course, make is old-fashioned and rather crude. It's easy to create something prettier, but it's very hard to create something that works better. make is a clever tool, and underlying its operation is constructing a directed dependency graph, then computing an operation order to satisfy the desired target(s). I would love to see the data-structure and algorithmic part of make made available as a library so we could build upon those parts more readily, or perhaps even wrap a GUI around a real Makefile and show the user a graphical representation of the project state. Details of the Makefile syntax and the fact that actions are made from shell script fragments is somewhat irrelevant. The underlying logic is re-implemented in many projects in quite diverse areas. Inkscape import filters and gstreamer pipelines are two examples I can think of right now. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) signature.asc Description: This is a digitally signed message part ___ 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
What I think users want is to have the underlying tools be more aware of the other sources of data in the design, and each other, so that the GUIs appear to be more integrated despite being individual tools and datasets underneath. This may require some high-level these are the files in your design also, but it's a slightly different problem to solve. So if I understand correctly each program in the gEDA tool chain will need a pipe/gate/threat/port/whatever through which it can communicate to a TLP or the N-1 and N+1 tool in the work flow. Something like a multi master serial communication link (I'm more a hardware engineer than a software engineer ;-) But an even different is the problem of what *design* data goes in which file. This part is not backwards compatible, because we'd want to move data out of the other files (sch, pcb, whatever) into a new container. This shouldn't be a problem, the file format of gschem is an excellent example of flexibility. If you have a TLP which can gather information from the various files and make a new file with the meta data it didn't find then your OK. For the user it doesn't matter where the information is stored as long as it is stored. For a script or a text-file junkie it might be hell. Or am I missing something? ___ 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
Lot of good discussion here. Keep it up. I work in the asic/fpga arena and I am building a tool flow based on the ip-xact standard (IEEE-1685). It has a lot in it that solves many of the problems in this discussion and I would suggest that gEDA might want to borrow a few tips from that standard. 1) It is targeted for exchanging data between tools. All the files use xml so that parsers are available for all languages. 2) All objects have a unique identifier. Ip-xact uses a VLNV for Vendor,library,component and version. There are no name collision issues as long as the rules are followed. 3) Multiple views are supported. I can created a view with one deliverable for simulation and a different view and deliverable for synthesis. I can generate a light symbol view as well as a heavy one. 4) No problems with data duplication. By using correct by construction techniques you never duplicate data. You keep the master source in an ip-xact file and generate everything from there. 5) Overlays are supported. You never modify anything that you do not have engineering responsibility for. If you want to change a library part for a local design then you create a local part that uses the lib part and then all the changes are made in the local part. The master is never touched. 6) ComponentGenerators are supported. You can embed generators inside of a component that control how it is processed by other tools. John Eaton ___ 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 May 24, 2011, at 9:37 PM, DJ Delorie wrote: I had proposed using the pin *label* as the identifier, not the pin *number*. The label is owned by the schematic, but the number is owned by the partdb or layout. That lets you, for example, change the package in layout without having to change the schematics first. What about packages with duplicate pins, e.g. both 2 and 4 are drain? 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: Solving the light/heavy symbol problem
On May 24, 2011, at 9:43 PM, DJ Delorie wrote: My flows are also heavily scripted, so yes, I'll remember. The underlying data and low-level tools follow the scripting paradigm - stepwise progress from A to Z via simple apps that interact with simple data. The GUI needs to *hide* that, not replace it, making the underlying data *seem* integrated and easy to manage, when in fact it is not. This is where we disagree. The GUI needs to make the data easy to manage, but at the same time it needs to *reveal* its machinations. If it hides everything, the user winds up either: 1. stuck with the GUI, unable to use the toolkit as a kit, or 2. having to penetrate the GUI code to figure out how to use the kit. It's like having a travel agent book a trip: you might say I want to get from A to B, but the itinerary the agent delivers had better reveal the route. And that route had better be simple enough that you can understand it. That one can hide complexity behind an interface does not excuse unnecessary complexity. When SUN created GUI for system administration, a sysadmin friend of mine complained bitterly that the result was they used it as a license to expand the admin databases in an undisciplined way, because the GUI could hide the chaos. But if you need to script admin tasks... Back in the early days of NeXT, their GUI-building GUI, Interface Builder, was really easy to use. It emitted the Objective-C code to construct and connect the objects behind the interface, so it was easy to understand what was going on behind the scenes. That's important. While the GUI is very useful to get the appearance right, the functionality requires actual coding. But they couldn't leave a good thing alone. Programmers are supposed to hide information regardless of its importance to the user these days, so they fixed IB to directly and invisibly create archived objects in a fully initialized state. The result was that what had been clear became mysterious, and you had to be much more of an expert to get results. 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: Solving the light/heavy symbol problem
What about packages with duplicate pins, e.g. both 2 and 4 are drain? PCB already handles this by just treating them as one pin with two copper bits, but you could use D1/D2 if you wanted to make them separate. But I did cover this in my pin mapping doc: Here's the 8-SOIC case, showing how to map a single schematic pin to multiple footprint pins: G = 4 S = [1,2,3] D = [5,6,7,8] ___ 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
I think what a GUI does is no different than what Make does - it lets you encapsulate complex operations into simpler ones. When a user clicks on run simulation, they don't care how many steps it takes to do that, they just want their simulation. When you run make sim to run your simulation, you don't care what the Makefile does, only that it does it. With that point of view, look at your argument wrt your flow: This is where we disagree. The Makefile needs to make the data easy to manage, but at the same time it needs to *reveal* its machinations. If it hides everything, the user winds up either: 1. stuck with the Makefile, unable to use the toolkit as a kit, or 2. having to penetrate the Makefile code to figure out how to use the kit. (er, as an example, I still don't know how to rebuild just one subdirectory of the Linux Kernel - I always run a full make from the top, because that's the only thing I've figured out so far) The solution to these problems is not transparent tools, it's better documentation. I've seen the Makefiles ISE spits out, that doesn't tell me how the tools work. Now, I don't think the GUI should hide information for the sake of being obscure. I think the GUI should hide information because the user already has enough to worry about. We get a lot of users complaining about too many clicks or why can't I do that in the gui. They use a GUI because they want to work on their design, not learn how to use our tools. Many of them don't even know a shell window exists. Consider the pcbfwd netlister (File-Import in PCB). It's scriptable. You could run gnetlist manually. You can use that in a Makefile to update a layout. But the *only* feedback (er, non-bug-report type) I get about it is Wow! I can update my layout with one button!. ___ 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 May 24, 2011, at 9:37 PM, DJ Delorie wrote: I did think about where the *metadata* would come from, and some API to hide all that behind. I'm waffling between something like HTTP/CGI (automatic integration with any web server) or SQL (powerful query language) I think if we continue to worry about what the user or consumer might see without prototyping it, we'll just argue about it forever. But we seem to have reached the consensus that gnetlist is the place where everything should come together. That, I think, requires refactoring gnetlist. When the right factors are present, the gnetlist approach is very powerful, but we don't have all of them here. We can't really make a prototype that covers the ground. I'm quite willing to help on the plug-in/back-end side, but working on a minor refactoring of gnetlist itself was a very negative experience. I have no desire to descend into the Mines of Moria again. Who is brave enough? 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: Solving the light/heavy symbol problem
On May 25, 2011, at 5:58 AM, DJ Delorie wrote: I think what a GUI does is no different than what Make does - it lets you encapsulate complex operations into simpler ones. When a user clicks on run simulation, they don't care how many steps it takes to do that, they just want their simulation. When you run make sim to run your simulation, you don't care what the Makefile does, only that it does it. Sometimes yes, sometimes no. I often use make -n or look at the rules in the makefile. One problem juggling many long term projects is that I forget how I organized the processes years ago when I set things up. That's part of the power of make: it can hide or reveal as needed. The solution to these problems is not transparent tools, it's better documentation. Sure. That's easy to say, very difficult to implement. I've seen the Makefiles ISE spits out, that doesn't tell me how the tools work. Bad factoring is always a problem. Now, I don't think the GUI should hide information for the sake of being obscure. I think the GUI should hide information because the user already has enough to worry about. We get a lot of users complaining about too many clicks or why can't I do that in the gui. They use a GUI because they want to work on their design, not learn how to use our tools. Many of them don't even know a shell window exists. They don't automate. There's a place for that. But what makes gED*A* *uniquely* powerful is its friendliness to automation. 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: Solving the light/heavy symbol problem
On May 24, 2011, at 10:30 PM, Peter Clifton wrote: the fact that actions are made from shell script fragments is somewhat irrelevant. I think it's highly relevant, because it means that anyone familiar with shell commands has a head start understanding what's going on. 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: Solving the light/heavy symbol problem
I'd like to note that we have a serious power tool in gnetlist, and it's not too hard to get it to translate attributes. Here's an example: gnetplug-metadata.scm Description: Binary data project_metadata.scm Description: Binary data metademo.sch Description: Binary data Usage: gnetlist -l project_metadata.scm -g your_favorite_back_end metademo.sch project_metadata is a project-specific file, while gnetplug-metadata.scm defines the simple machinery that makes this work. A next step might be to have a parser for a rule format that's more tabular and spreadsheet-friendly than S-expressions, although cargo cult construction of rules from the example here shouldn't be too hard. This could be a fine mechanism for manipulating invisible attributes like footprints. It can't do annotation because gnetlist hides much of the schematic data from the back-end script. There is an annotation tool that's conceptually like gnetlist at https://github.com/xcthulhu/lambda-geda. It converts schematic format to/from S-expressions for processing with a back end, but it's written in Haskell, which I guess would be even more of a barrier than Scheme. It is, however, in production use at Noqsi and Osaka, creating flattened schematics for documentation. Consider it proof of concept for an annotation tool. 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: Solving the light/heavy symbol problem
On May 23, 2011, at 1:40 PM, DJ Delorie wrote: 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. Hierarchy isn't the only reuse scenario. Consider transition from breadboard to prototype to production. A top-level schematic might not change, even though attributes of parts might change (different packages, tighter specs, ...). In that case, the instance-specific data can't be in *any* schematic. 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: Solving the light/heavy symbol problem
I'd like to note that we have a serious power tool in gnetlist, Yup. I had hoped to move some of the heavyifying data into a database or the layout (or whatever), and have gnetlist gather all the attribute data from the schematic, the database, and the layout. It can then combine the data in order to update the layout. For example, to do pin swapping - you could set the pin numbers in the schematic, or leave them unspecified. If unspecified, gnetlist would see unassigned pins and allocate them based on some pin map database, then give that to the layout. On the next iteration, the pin numbers would be provided by the layout so gnetlist would know not to change them. Either way, gnetlist gathers the pin information from wherever it is available, and doles it out to whoever needs it. On a simpler scale, I expected gnetlist to read my partdb that maps light symbols and design rules to heavy symbols. At least, for those attributes not already specified in the schematic. No need to have hundreds of symbols, when you could have hundreds of rows in a database instead. Thus, schematics need only concern themselves with schematics - the symbolic connections of the design. Design-specific component attributes would be managed by gnetlist and gattrib. Physical layout, simulation, or other final target information would be managed by their respective tools. But yes, this means gnetlist would have to take on much more responsibility for managing the project. With your workflow, for example, your heavy symbols might be heavy only by having a manufacturer's part number in them, or some keyword that says that it is (purpose=bypass-cap for example), with all the other information added by gnetlist. ___ 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
Hierarchy isn't the only reuse scenario. Consider transition from breadboard to prototype to production. A top-level schematic might not change, even though attributes of parts might change (different packages, tighter specs, ...). In that case, the instance-specific data can't be in *any* schematic. Up to now, we've been using the schematic as the master files for the design. Perhaps this is a bad idiom? Perhaps the design should be some other data, which uses the schematic as but one of its inputs? ___ 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: 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: 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
Re: gEDA-user: Solving the light/heavy symbol problem
DJ Delorie wrote: IIRC there are a few proposals and/or active solutions in play: * Standard library is light, users heavyify them (we need a better verb for that ;) into a project-specific (or even site-global) heavy symbol library. * Standard library is heavy, users either use those as-is or modify them to alternate heavy symbols. * Standard library is light, the tools automatically heavyify them based on some database somewhere (both static and dynamic conversions have been seen/suggested). * Standard library is some mix of heavy/light. I think this is what we have now, although not ideally implemented. My proposal to tackle many of the library related issues is the notion of packages. These would be data structures that can contain all information relevant to an entity us humans like to build electronics from. Specifically, they may contain * symbols * footprints * simulation models * data sheets * acquisition information. * comments Note, the plural. Symbols may be alternative, or grouped. All content may be embedded or a link. Both have their specific strengths and it is up to the designer of the lib to choose. There may even be a combined embedded and linked mode. Use a link as a reference but keep a local copy for fall-back. If the reference diverges from the local copy, ask the user what to do -- update or switch to pure embedded mode. To the environment, a package can be a file or an entry in a data base. In schematics and in layouts it may be referred to with a unique name, just like symbols are currently referred to. In addition, the entry in the schematic file would tell which of the symbols, footprints, or whatever this instance uses. There would be a GUI dialog to view the contents of a package and choose from them. Of course, it would also be possible to override and enter completely new for this instance only. Much like we can do now in the attribute editor. Packages and pure symbols could be mixed transparently. Where and how to look for them would be configured in gafrc, just like we do now. So the fraction of data base lovers would be catered as well as those, who are in favor of files. They could use and share the same packages. 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. * It should be easy to go from a light symbol to a heavy one, so that users can add, say, a generic resistor to a schematic and later allocate a specific part to it. There may be a no defaults mode on insertion of a package. If you want to set the specifics later, click on the symbol and choose. How specific or a package is by default would be a design decision of the library author. --)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
Cullen Newsom wrote: Couldn't you consider maintaining some backwards-compatibility by having the metadata file simply contain references to the symbol files (plus other garbage, spice, kitchen sinks, etc), and footprint files? That should only require a minimal effort on the part of gSchem to read the new metadata file. This smells suspiciously like the packages I propose in another mail ;-) ---)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
On Sat, May 21, 2011 at 9:09 AM, Kai-Martin Knaak k...@lilalaser.de wrote: My proposal to tackle many of the library related issues is the notion of packages. These would be data structures that can contain all information relevant to an entity us humans like to build electronics from. Specifically, they may contain * symbols * footprints * simulation models * data sheets Not clear to me if your proposal means the data sheets are included in the distributed package? If so, that most likely runs afoul of the company's copyrights and would require permission from said copyright owner, for *each* data sheet. I've had to contact legal departments to use information in data sheets in some of my work, and they've always been happy to grant such access, but you still have to go through the time consuming steps. ___ 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
Kai-Martin Knaak, [snip] My proposal to tackle many of the library related issues is the notion of packages. Great, thank you for posting these details. You seem to have an approach on how to fix the library issues. It would be great if you could now implement this approach as a prototype for everybody to evaluate. I look forward to downloading your new symbol libraries as well as any modified software. Thank you, -Ales ___ 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
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. It's almost like each component would be a micro-library of
its own.
Note, the plural. Symbols may be alternative, or grouped.
I've worked with EDA systems that did this - you have a symbol class
with variants on the graphics. For example, 2-3 resistor shapes with
compatible pin locations, which you can swap between. I think this is
a good feature to add, if we can.
Likewise, PCB has footprint variants you should be able to switch
between during layout, like RESC1608{M,N,L}.
In schematics and in layouts it may be referred to with a unique name,
Hmmm... we need a way to scope names, I think. Maybe come up with an
URL structure for specifying library/component/symbol/script/whatnot
from whence we get the information we need. We already have problems
with same-named files in different directories.
So the fraction of data base lovers would be catered as well as
those, who are in favor of files. They could use and share the same
packages.
Yes, I think we need to get away from the idiom that symbols are
files, footprints are files and allow other ways to store these (db,
web, zip, script, etc, as well as files).
There may be a no defaults mode on insertion of a package. If you
want to set the specifics later, click on the symbol and choose.
Yup, that's the way I usually do it.
___
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
It would be great if you could now implement this approach as a prototype for everybody to evaluate. I think we're still in the what do we want to do phase :-) Some time this weekend, I'll re-read the thread and see which ideas we seem to have come to a consensus on, and see what if any parts of the plan can already be done. Then we can start talking about how to get the rest done. For example, I think we all like the idea of a heavy starter library, that's known to at least produce usable results with minimal effort. However, the proponents of that idea can already do this with no dependencies on software changes - just upload it to gedasymbols. I might do one myself. But we also seem to be converging an a need for multiple library management, including non-local libraries, which will require some nontrivial coding effort in many of the tools, so we shouldn't suggest starting on that just yet. 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. If we have come to a consensus on what do we want to do the next step would be to figure out the coding needed and get people to start on prototypes. Perhaps we'll end up with the horrible problem of having to choose between two excellent implementations :-) ___ 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
[snip] I think we're still in the what do we want to do phase :-) We have been in the what do we want to do phase for many many years. Talk is cheap. -Ales less talk, more code ___ 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
We have been in the what do we want to do phase for many many years. Talk is cheap. Agreed, but we still need to get everyone on the same page, or at least in the same book, so we can actually *do* it this time, and stop rehashing the same old problems. Talk is cheap, but buy-in is very expensive. ___ 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
Talk is cheap, but buy-in is very expensive. And, of course, I expect those who are contributing to the talk part to buy-in to actually *doing* their part of it, too. ___ 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 Sat, May 21, 2011 at 09:19:21AM -0400, Bob Paddock wrote: On Sat, May 21, 2011 at 9:09 AM, Kai-Martin Knaak k...@lilalaser.de wrote: My proposal to tackle many of the library related issues is the notion of packages. These would be data structures that can contain all information relevant to an entity us humans like to build electronics from. Specifically, they may contain * symbols * footprints * simulation models * data sheets Not clear to me if your proposal means the data sheets are included in the distributed package? If so, that most likely runs afoul of the company's copyrights and would require permission from said copyright owner, for *each* data sheet. OK, URL(s) and SHA1 of the data sheet. I've had to contact legal departments to use information in data sheets in some of my work, and they've always been happy to grant such access, but you still have to go through the time consuming steps. I have done that, too, but only rarely. It's a royal PITA. Do those guys *cough*Marvell*cough* want us to use their parts, or not? - Larry ___ 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/20/2011 04:09 PM, DJ Delorie wrote: hmmm... think about how a simplehttp:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of*that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. Could RSS feeds work for this? a starter set of feeds would be small and easy for beginners. Symbol and footprint names and descriptions could be supplied via RSS, then following the RSS link when selecting the symbol or footprint would show you its details before placing it. Users would add to the RSS feeds they track as they go along finding source of footprints/symbols. There would be name conflicts sometimes. Some users would want a short list of library items, some would want to create their own subset libraries locally. It would be nice if the method of choosing footprint names and descriptions to list was the same for remote RSS feeds as for local directories. It might be a good idea to require two attributes of a symbol or footprint to be name and short description, then all you need to show a names and descriptions list is look inside the library item. I like for the name of a symbol to be the filename without its suffix -- is there any reason for any different definition for symbol name? On 05/20/2011 04:14 PM, DJ Delorie wrote: Do they add meta-data to the symbol, the footprint, or store it elsewhere? We*do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI:-) Separating the metadata would help create manageable libraries, since the symbol can stay unchanged, stable in use. I like adding the meta-data to a separate file, even if it associated with a footprint first. For example: SOIC-8.fp along with SOIC-8.fp.meta, which contains attribs symbolname=FET_dual_11234.sym footprintname=SOIC-8.fp could be created first, and a symbol for FET_dual_11234.sym defined later. Many people would never do the above, but it would help with annotating as built layouts back to a schematic. Ordinarily, you would start with file FET_dual_11234.sym and FET_dual_11234.I002.sym.meta containing attribs symbolname=FET_dual_11234.sym footprintname=SOIC-8.fp, and add file SOIC-8.fp later and never opt to create a file SOIC-8.fp.meta, and that's OK. Any GUI tool that found both kinds of files could pop a dialog to ask, which will overrule the other? This makes me think of a missing part -- instances will clobber names if not having an instance part in the meta-data file name. Instead of SOIC-8.fp.meta we would use SOIC-8.fp.I231.meta which contains attribs symbolname=FET_dual_11234.sym symbol-meta-data=FET_dual_11234.I002.sym.meta footprintname=SOIC-8.fp. John Griessen -- Ecosensory ___ 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
I like adding the meta-data to a separate file, even if it associated with a footprint first. For example: SOIC-8.fp along with SOIC-8.fp.meta, which contains attribs symbolname=FET_dual_11234.sym footprintname=SOIC-8.fp could be created first, and a symbol for FET_dual_11234.sym defined later. Is there an advantage to separating out the attributes of a symbol, but still having them symbol-specific? I suppose if we had symbol *classes* we'd want to pull the attributes out of the graphical representation of the symbol (like resistor-1.sym) and put them in the symbol class (resistor.scl). But what I was thinking was, for example, having NAND2.sym be a generic 2-in NAND gate, SO14.fp be a generic soic-14, and the metadata would be SN74LVC00ANSR.part. The metadata would have symbol=NAND2, footprint=SO14, pinmap=[(A,B),Y]=([(1,2),3],...), etc. ___ 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 Fri, 20 May 2011 12:01:59 -0400 DJ Delorie d...@delorie.com wrote: [Subject changed to start new thread] [...] When I first read geda documentation, there were already references that this had been discussed ad nauseam. If the default lib is to be changed now, then there should be some kind of new consensus on the heavy/light issue. IIRC there are a few proposals and/or active solutions in play: * Standard library is heavy, users either use those as-is or modify them to alternate heavy symbols. I say go with this - because users already have to modify nearly all the symbols they use in a schematic when using the existing library. This way, most of the symbols will have default footprints and other attributes that will do just fine. At the very least, I don't think it would make the end user's workload any worse. If it breaks someone's workflow temporarily, they'll have to adapt. Such things are commonplace with far more major upgrades than an EDA package. I think of office suites and even whole OSs, which often end up requiring formal re-training when upgraded. -- 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: Solving the light/heavy symbol problem
Oh boy am I glad y'all are having this conversation, and I hope you don't mind some comments from the peanut gallery. On Fri, May 20, 2011 at 11:01 AM, DJ Delorie [1]d...@delorie.com wrote: [Subject changed to start new thread] When I first read geda documentation, there were already references that this had been discussed ad nauseam. Sigh, yes. It's not an easy problem to solve, and I would consider any solution a major effort because it touches everything from gschem to pcb to sim. No it isn't easy but for the reasons mentioned above has the potential to improve gEDA usability (ergo adoption) in significant ways. ...the ability for the user to manage their library from either gschem or pcb would be ideal. Yes please! (right click and or hotkey - attach footprint to symbol) Bonus points for backwards compatibility, but I think that would only make things much harder for us. I'm willing to start fresh with the caveat that old designs would need to point to old libraries. In the past the desire for backwards compatibility was a stumbling block for this, but perhaps we just need to accept the breakage. I'm also willing to consider a new method for auto-generating families of footprints. I think M4 is not the preferred method for anyone anymore, despite a general disagreement about what *is* preferred :-) Put me down for intense dislike of M4. Sorry. I'm sure it's a fine choice for some, but I've never had to touch or know anything about M4 for anything else, ever. Which means that on some occasion that all I had wanted to do was make a printed circuit board; now I have to go and learn enough about M4 to make my little footprint(s). It also means that I'll probably do something wrong, or in a non-optimal way, since I'll never use it enough to achieve any sort of proficiency. tl;dr I would love an easier way to generate footprints. If the default lib is to be changed now, then there should be some kind of new consensus on the heavy/light issue. There are many perfectly reasonable occasions / individuals who would prefer the heavy option. It is also reasonable to say that the light option gets you the most flexibility. After years of watching this debate go nowhere, may I suggest that you must either find a way to do both, or tell some of us to bugger off. IIRC there are a few proposals and/or active solutions in play: * Standard library is light, users heavyify them (we need a better verb for that ;) into a project-specific (or even site-global) heavy symbol library. * Standard library is heavy, users either use those as-is or modify them to alternate heavy symbols. * Standard library is light, the tools automatically heavyify them based on some database somewhere (both static and dynamic conversions have been seen/suggested). * Standard library is some mix of heavy/light. I think this is what we have now, although not ideally implemented. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. The solutions either accept a common subset of heavy symbols or defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. This is bad for so many reasons, not the least of which is that there will be so much duplicated effort spent on a very mundane task, like creating a symbol/footprint for some three-terminal regulator, or TTL logic gate or something. My own proposal (posted in the past) is here: [2]http://www.delorie.com/pcb/component-dbs.html It moves the problem out of gschem and into the netlister, which gives PCB the opportunity to be part of the process as well (the netlist can accept input from both gschem and pcb), but adds the requirement for back-annotation for those who prefer the master schematics to have that info in them. It is also an optional step in the flow, so it doesn't block other solutions (like a heavy-only library). Note that any solution should have these attributes: * It should be easy to go from a light symbol to a heavy one, so that users can add, say, a generic resistor to a schematic and later allocate a specific part to it. While text editing is technically easy, it doesn't streamline into a gui-centric flow, mor is it readily scriptable. * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This might mean a
Re: gEDA-user: Solving the light/heavy symbol problem
I say go with this - because users already have to modify nearly all the symbols they use in a schematic when using the existing library. This way, most of the symbols will have default footprints and other attributes that will do just fine. Ok, then how do we generate the thousands, if not millions, of symbols we'll need? How do we choose what the default set of parts should be? Just among the few of us here, we've already found out that just picking through-hole vs smt is not a clear choice. If we come up with a way to do that, we'll also have a way for the user to do it. No matter how complete a heavy-only library is, it won't be complete enough, so we *still* need to make sure the user has a way to add to their library. And consider that, no matter how heavy a symbol is, you can always make it heavier. Let's say we ship a symbol for a 4.7k 0603 resistor. Does it include manufacter's part numbers? Vendor name? Tolerance? These are additional data the user could add. Where does it come from? How do they add it? Should we add it up front? Why? I like the idea of including a set of heavy symbols as a starter pack - maybe a few sets of them (through-hole vs smt, for example) - but I think we need to also allow for a set of light symbols too, and think about the process of user-heavyifying them. This, along with how do I create new symbols/footprints is a common stumbling block for new users. ___ 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
And consider that, no matter how heavy a symbol is, you can always make it heavier. Let's say we ship a symbol for a 4.7k 0603 resistor. Does it include manufacter's part numbers? Vendor name? Tolerance? These are additional data the user could add. Where does it come from? How do they add it? Should we add it up front? Why? Yes users must be able to add metadata, ie: company internal part numbers, document numbers, etc. I like the idea of including a set of heavy symbols as a starter pack - maybe a few sets of them (through-hole vs smt, for example) - but I think we need to also allow for a set of light symbols too, and think about the process of user-heavyifying them. This, along with how do I create new symbols/footprints is a common stumbling block for new users. How about (right-click, attach footprint to symbol?) Heck, it would also be nice to be able to switch footprints from within PCB; for example, when changing a board from thru-hole to SMT. ___ 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
I would love an easier way to generate footprints. Now that we're pre-parsing all the M4 footprints anyway, perhaps we could allow for a range of scripting options in the Makefiles that generate the library? There have been a few footprint-specific languages developed over the years. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. No, but if we choose a subset, we pretty much guarantee that there will be users who need something we left out. I don't want to be replicating Digikey's database, for example, but any part I leave out is a part someone else might need. defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. Hmm... but does this mean we should do the work for them, or does this mean we need to come up with a better way for them to do the work? * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This is why I see no clear win between just heavy and just light - different users at different levels need different solutions. A new (to geda) user should be able to pick common parts from a list and make *something* that works, but an experienced user will eventually need to make their own. Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to If we go with the idea of more than one library, we can ship a starter library (like, Radio Shack 500-in-1 parts list, or Spice 101 with examples) and let the user import libraries from, say, gedasymbols. With my scheme, that would be a starter database instead, but similar results. Actually, with gedasymbols, *anyone* can make a small self-contained heavy symbol library. The problem happens when you want to make a self-contained *light* symbol library, then you need more logic in the tools to heavyify them. synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). hmmm... think about how a simple http:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of *that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. This also allows for footprints-by-cgi, another level of scripting them. Or script://$prefix/pcb/dip-generator.pl?pins=16width=300mil etc. By the way, if you guys decide to tackle a big re-write, the IPC and NIST tried to tackle this problem a few years ago. We've been using standard names for new footprints at least. When we can :-) ___ 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
I'm have no a lot of expirience in PCB creation, so may be I don't know something, but I have following suggestions: Just now my workflow is the next: 1. I draw scheme in gschem. 2. I run gsch2pcb and look for errors like this: WARNING: C5 has no footprint attribute so won't be in the layout. C5: deleted element 0805 (value=20pF) 3. I go again to gschem and manually fix missed footprints. As I understend on the last step gattrib coud be used But for me it is useless, 'cos I just can enter value and don't see the preview of footprint. So, may be it would be usefull to add for gattrib preview feature vith library navigation and add to gschem somekinde of bridge to new gattrib utility? 2011/5/21 DJ Delorie [1]d...@delorie.com I would love an easier way to generate footprints. Now that we're pre-parsing all the M4 footprints anyway, perhaps we could allow for a range of scripting options in the Makefiles that generate the library? There have been a few footprint-specific languages developed over the years. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. No, but if we choose a subset, we pretty much guarantee that there will be users who need something we left out. I don't want to be replicating Digikey's database, for example, but any part I leave out is a part someone else might need. defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. Hmm... but does this mean we should do the work for them, or does this mean we need to come up with a better way for them to do the work? * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This is why I see no clear win between just heavy and just light - different users at different levels need different solutions. A new (to geda) user should be able to pick common parts from a list and make *something* that works, but an experienced user will eventually need to make their own. Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to If we go with the idea of more than one library, we can ship a starter library (like, Radio Shack 500-in-1 parts list, or Spice 101 with examples) and let the user import libraries from, say, gedasymbols. With my scheme, that would be a starter database instead, but similar results. Actually, with gedasymbols, *anyone* can make a small self-contained heavy symbol library. The problem happens when you want to make a self-contained *light* symbol library, then you need more logic in the tools to heavyify them. synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). hmmm... think about how a simple http:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of *that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. This also allows for footprints-by-cgi, another level of scripting them. Or script://$prefix/pcb/[2]dip-generator.pl?pins=16width=300mil etc. By the way, if you guys decide to tackle a big re-write, the IPC and NIST tried to tackle this problem a few years ago. We've been using standard names for new footprints at least. When we can :-) ___ geda-user mailing list [3]geda-user@moria.seul.org [4]http://www.seul.org/cgi-bin/mailman/listinfo/geda-user References 1. mailto:d...@delorie.com 2. http://dip-generator.pl/?pins=16width=300mil 3. mailto:geda-user@moria.seul.org 4. http://www.seul.org/cgi-bin/mailman/listinfo/geda-user ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Solving the light/heavy symbol problem
On 20/05/11 17:01, DJ Delorie wrote: * Standard library is light, users heavyify them (we need a better verb for that ;) into a project-specific (or even site-global) heavy symbol library. Personally, I'd say that this is a sensible way to go. I'd then suggest having an extra set of options somewhere (perhaps even have an entire beginner mode), and this guides people through the heavification of symbols. For example, when you select a component to add to the schematic, it offers some help by suggesting a set of frequently used footprints (probably generated from the user's MRU list), along with suggesting addition of other attributes. The other thing that I find insanely useful is gedasymbols. I don't suggest for a single moment that shipping the entire gedasymbols library with gEDA/PCB is a good idea, but perhaps the following should be considered (no idea if it's actually possible): - gEDA has a way of detecting a network connection. - If connected, search will also search gEDAsymbols, and on request download the sym (and possibly its associated footprint). This, again, would certainly help with streamlining my workflow, as I tend to spend a fair amount of time opening tabs and browsing to gedasymbols. I don't think shipping heavy symbols is a good idea - it is easier to go from light - heavy, than the other way, even if it's only a few mouse clicks away. One final comment about this: Perhaps the proposed sym+metadata+fp is the way forward - the metadata is basically a set of overrides on the sym and fp data, and everything gets dealt with that way. Just my 2 cents. Chris ___ 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 Fri, May 20, 2011 at 12:01:59PM -0400, DJ Delorie wrote: My own proposal (posted in the past) is here: http://www.delorie.com/pcb/component-dbs.html I like this idea a lot. Allowing pcb and gschem to use different (multiple) databases with different backends gives us a lot of freedom. It would let us ship, say, a sqlite database with a bunch of defaults (after bickering endlessly about what such defaults might be), while shops or even gedasymbols.org might have a real SQL db so that everyone has the same footprint data. It would also greatly simplify packaging and versioning, since these database backends can be changed by sql scripts, can store metadata, etc. It moves the problem out of gschem and into the netlister, which gives PCB the opportunity to be part of the process as well (the netlist can accept input from both gschem and pcb), but adds the requirement for back-annotation for those who prefer the master schematics to have that info in them. It is also an optional step in the flow, so it doesn't block other solutions (like a heavy-only library). -- 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: Solving the light/heavy symbol problem
It would let us ship, say, a sqlite database with a bunch or OOo spreadsheet, or CSV text file, or even a web server CGI. See also: http://www.gedasymbols.org/csv.html ___ 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 Fri, May 20, 2011 at 4:14 PM, DJ Delorie [1]d...@delorie.com wrote: Yes users must be able to add metadata, ie: company internal part numbers, document numbers, etc. Do they add meta-data to the symbol, the footprint, or store it elsewhere? Well, as an example, I insert some unique identifier (company part number), or keyword, etc in some field, or even as a comment in the symbol or footprint file. Later, I can grep for the unique identifier, and find all the places I've used it. This kind of thing has been helpful for building BOMs that the purchasing folk won't try to have you tarred and feathered for. We *do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI :-) Heck, it would also be nice to be able to switch footprints from within PCB; for example, when changing a board from thru-hole to SMT. I've considered that too. It means either pcb has to be able to talk to gschem, or gschem and pcb need to share a separate metadata container. I.e. a project would be schematics+metadata+layout, not just schematics+layout. It looks to me like the schem + metadata + layout is where you're headed. I can't see how else to integrate all that stuff, and still have gSchem + PCB remain separate entities (which is as it should be). Couldn't you consider maintaining some backwards-compatibility by having the metadata file simply contain references to the symbol files (plus other garbage, spice, kitchen sinks, etc), and footprint files? That should only require a minimal effort on the part of gSchem to read the new metadata file. Here's another link to the IPC-2581 stuff. [2]http://webstds.ipc.org/2581/2581intro.htm References 1. mailto:d...@delorie.com 2. http://webstds.ipc.org/2581/2581intro.htm ___ 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
Chris Malton wrote: On 20/05/11 17:01, DJ Delorie wrote: * Standard library is light, users heavyify them (we need a better verb for that ;) into a project-specific (or even site-global) heavy symbol library. Personally, I'd say that this is a sensible way to go. This is the way it is since at least six years. Unfortunately, it does not fit three of the four attributes on DJs wishlist. ---)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
On Fri, 20 May 2011 16:54:20 -0400 DJ Delorie d...@delorie.com wrote: I say go with this - because users already have to modify nearly all the symbols they use in a schematic when using the existing library. This way, most of the symbols will have default footprints and other attributes that will do just fine. Ok, then how do we generate the thousands, if not millions, of symbols we'll need? I've been thinking about that, and to be blunt, I have no frickin' clue. ;-) Maybe some clever scripting against a set of generic parts (similar to what I did with those footprints I just submitted). How do we choose what the default set of parts should be? Just among the few of us here, we've already found out that just picking through-hole vs smt is not a clear choice. The only fair way to handle this is to use gschem to conduct a sort of extended poll - the program itself could submit a data point to some central site each time the user instantiates a symbol or adds an attribute that affects the final build of the device (but only in ways that matter for this vote), with some kind of mechanism for changing one's vote when an attribute is changed. The server would compile all that data into a list of symbol - (footprint, device, manufacturer, ...) mappings and whatever floats to the top for any given symbol after, say, 6 months becomes the default for that symbol. If we come up with a way to do that, we'll also have a way for the user to do it. No matter how complete a heavy-only library is, it won't be complete enough, so we *still* need to make sure the user has a way to add to their library. For that, I'd say keep the existing mechanism for now, but suggest a default location for such creations (.gEDA/symbols/ and .gEDA/footprints/ sound fair). Let the user override these settings in the programs' respective config files, or make a couple of symlinks, if they want to use something other than these proposed defaults. I have Gschem and PCB set to use the two directories where my gedasymbols.org symbols and footprints are stored, so that those files are always available no matter what project I'm working on. And consider that, no matter how heavy a symbol is, you can always make it heavier. Let's say we ship a symbol for a 4.7k 0603 resistor. Does it include manufacter's part numbers? Vendor name? Tolerance? These are additional data the user could add. Where does it come from? How do they add it? Should we add it up front? Why? Choose attributes that result in an easy-to-hand-assemble board. That way a quick schematic-to-PCB export will result in a board that one could at least fab, even if it means the user has to flip back and forth between the schematic and hard-copy BoM sheets to find part values. The idea is to get from schematic to board-in-hand with as little trouble as possible. I like the idea of including a set of heavy symbols as a starter pack - maybe a few sets of them (through-hole vs smt, for example) - but I think we need to also allow for a set of light symbols too, and think about the process of user-heavyifying them. This, along with how do I create new symbols/footprints is a common stumbling block for new users. Sounds fair, but I could see a situation where this could overload the user. How about adding these options to the library browser: - Show symbols where footprints are... [ ] Through-hole [ ] Basic SMT -- catch-all for single resistors, caps, SOTs, etc. [ ] PLCC [ ] SOIC [ ] SSOP/TSSOP [ ] BGA [ ] Board-edge devices [ ] Unspecified - We *do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI :-) Careful, you'll incur John Doty's wrath. ;-) -- 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: Solving the light/heavy symbol problem
On Fri, May 20, 2011 at 4:09 PM, DJ Delorie [1]d...@delorie.com wrote: I would love an easier way to generate footprints. Now that we're pre-parsing all the M4 footprints anyway, perhaps we could allow for a range of scripting options in the Makefiles that generate the library? There have been a few footprint-specific languages developed over the years. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. No, but if we choose a subset, we pretty much guarantee that there will be users who need something we left out. I don't want to be replicating Digikey's database, for example, but any part I leave out is a part someone else might need. You could collect users' statistics anonymously and let it be a popularity contest. Especially if the databases were centralized. defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. Hmm... but does this mean we should do the work for them, or does this mean we need to come up with a better way for them to do the work? I'm hoping for a better way for them to do the work or even, machine does most of the work Teach them to fish and all that. * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This is why I see no clear win between just heavy and just light - different users at different levels need different solutions. A new (to geda) user should be able to pick common parts from a list and make *something* that works, but an experienced user will eventually need to make their own. Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to If we go with the idea of more than one library, we can ship a starter library (like, Radio Shack 500-in-1 parts list, or Spice 101 with examples) and let the user import libraries from, say, gedasymbols. With my scheme, that would be a starter database instead, but similar results. Actually, with gedasymbols, *anyone* can make a small self-contained heavy symbol library. The problem happens when you want to make a self-contained *light* symbol library, then you need more logic in the tools to heavyify them. synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). hmmm... think about how a simple http:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of *that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. Here's some pie-in-the sky for you. I can imagine a database with which a small number of users has full commit privileges, others' symbols / footprints (perhaps even by default / automatically) will be submitted, which would in turn generate a vetting request whereby a user with full access could approve or deny the new or modified files. Some effort would also be spent getting a machine to look for common mistakes and automatically reject them. I'd love to see it get all Web2.0-ish, and I think it could work very well. (if I only knew how to make it so). This also allows for footprints-by-cgi, another level of scripting them. Or script://$prefix/pcb/[2]dip-generator.pl?pins=16width=300mil etc. Yes, this too. I've naively wished a thousand times or more for a machine that could take as its input a pdf datasheet, and produce as its output, symbols and footprints in some magically standardized format. By the way, if you guys decide to tackle a big re-write, the IPC and NIST tried to tackle this problem a few years ago. We've been using standard names for new footprints at least. When we can :-) Don't take any of this personally. I have a great affection and appreciation for gEDA and it's principles and goals. References 1. mailto:d...@delorie.com 2. http://dip-generator.pl/?pins=16width=300mil ___ geda-user mailing list geda-user@moria.seul.org
Re: gEDA-user: Solving the light/heavy symbol problem
Couldn't you consider maintaining some backwards-compatibility by having the metadata file simply contain references to the symbol files (plus other garbage, spice, kitchen sinks, etc), and footprint files? That should only require a minimal effort on the part of gSchem to read the new metadata file. My thought on that would be that PCB gives gnetlist information about the layout (pin swapping, package changes, etc) and gnetlist reads the schematics, applies the metadata and layout changes, and generates updates for the layout. Or, reads it all and generates an annotated schematic. No reason why gschem couldn't run the netlister itself, with a different backend that gives it the same metadata in a gschem-friendly format. That way, you can make changes in pcb and not worry about getting them out of sync with the schematics, and you an have both light and annotated schematics, or you can back-annotate your schematics. It seemed like it would cover all the bases. For backwards compatibility, you just have an empty (or no) metadata, so you get whatever's in the schematics. ___ 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
Metadata can be a parallel task. In gschem you pick your resistor. You have two buttons, place lite, place heavy. Place heavy brings up a second wizard to populate the heavy symbol, probably from your database. Then place your symbol. In pcb, when you import a schematic. Any parts without footprints gets listed. Then you can populate the right footprint. And a back annotation mechanism to update upstream schematics. As a third tool for series workflows sch in to output updated sch, bom, and netlist. Perhaps with features like, general remapping of footprints to the smallest package in your library. Or to your preferred hand soldering size for that type of component. Like ranking 0603 first, 0805 second, and 0402 third. Based on parameters like value and tolerance. Option to use only the heavy part specified, i.e. Don't change out this part. Steve On May 20, 2011, at 6:34 PM, Cullen Newsom cullennew...@gmail.com wrote: On Fri, May 20, 2011 at 4:09 PM, DJ Delorie [1]d...@delorie.com wrote: I would love an easier way to generate footprints. Now that we're pre-parsing all the M4 footprints anyway, perhaps we could allow for a range of scripting options in the Makefiles that generate the library? There have been a few footprint-specific languages developed over the years. In all cases, one key problem is that there are so many potential heavy symbols that we cannot possibly have all of them. Nobody needs all possible heavy symbols, and disk space is cheap. No, but if we choose a subset, we pretty much guarantee that there will be users who need something we left out. I don't want to be replicating Digikey's database, for example, but any part I leave out is a part someone else might need. You could collect users' statistics anonymously and let it be a popularity contest. Especially if the databases were centralized. defer the problem to the user, who only puts effort intothe symbols they needed. Which puts many (often novice users) to the task of creating their own symbol/footprints, and probably doing it wrong. Hmm... but does this mean we should do the work for them, or does this mean we need to come up with a better way for them to do the work? I'm hoping for a better way for them to do the work or even, machine does most of the work Teach them to fish and all that. * New users should find it easy to make their first PCB. Yes! New users, casual users, experienced users, all users. This is why I see no clear win between just heavy and just light - different users at different levels need different solutions. A new (to geda) user should be able to pick common parts from a list and make *something* that works, but an experienced user will eventually need to make their own. Don't ship gSchem or PCB with any. At first run, and in preferences, and in config files, give users the ability to choose their own poison. Use git to If we go with the idea of more than one library, we can ship a starter library (like, Radio Shack 500-in-1 parts list, or Spice 101 with examples) and let the user import libraries from, say, gedasymbols. With my scheme, that would be a starter database instead, but similar results. Actually, with gedasymbols, *anyone* can make a small self-contained heavy symbol library. The problem happens when you want to make a self-contained *light* symbol library, then you need more logic in the tools to heavyify them. synchronize with a (set of) master symbol and or footprints, and or something else databases. Include options to use others' symbols / parts (gedasymbols, luciani, etc). Include options for users to share their own symbols via git. Create online symbol and footprint generators that create standard footprints (at least for JEDEC standard stuff) properly (according to best practices). hmmm... think about how a simple http:// changed the way we share information across the Internet. Think of how Facebook changed the way people manage their social lives. Are we prepared to put the effort into making something of *that* scale, for EDA? It would be cool if we got it right, but a pain if we didn't. Here's some pie-in-the sky for you. I can imagine a database with which a small number of users has full commit privileges, others' symbols / footprints (perhaps even by default / automatically) will be submitted, which would in turn generate a vetting request whereby a user with full access could approve or deny the new or modified files. Some effort would also be spent getting a machine to look for common mistakes and automatically reject them. I'd love to see it get all Web2.0-ish, and I think it could work very well. (if I only knew how to make it so). This also allows for
Re: gEDA-user: Solving the light/heavy symbol problem
Ok, then how do we generate the thousands, if not millions, of symbols we'll need? I've been thinking about that, and to be blunt, I have no frickin' clue. ;-) Maybe some clever scripting against a set of generic parts (similar to what I did with those footprints I just submitted). Yup, I also figured you'd need some sort of database-driven scripting to generate them all. Then I realized, you don't need to run the script at build time, you only need to be able to run the script as needed by the user - then we don't have thousands of resistor symbols, we have one (or a few) resistor symbols and thousands of lines in a database. Then we replace the database with a CGI at digikey... ;-) Of course, we just reversed this for the M4 footprint library. Mostly because M4 is a bad choice these days, though, not because scripting itself is bad. The only fair way to handle this is to use gschem to conduct a sort of extended poll I wouldn't want information about user's schematics leaked, the privacy issues are too dangerous. However, we could collect stats about things downloaded from, say, gedasymbols. Perhaps we could have a small number of starter libraries on gedasymbols, and the geda installer prompts you to pick one to download. We track how many downloads of each, and use that to decide which to include in the distribution. Or we include them all in the distro, let the user pick, and who cares which one is more popular :-) And consider that, no matter how heavy a symbol is, you can always make it heavier. Let's say we ship a symbol for a 4.7k 0603 resistor. Does it include manufacter's part numbers? Vendor name? Tolerance? These are additional data the user could add. Where does it come from? How do they add it? Should we add it up front? Why? Choose attributes that result in an easy-to-hand-assemble board. Well, yes, but that wasn't the point I was trying to make. If the user *wants* to add more info to a part, they need a way to do it. That way should be easy for them. Sounds fair, but I could see a situation where this could overload the user. How about adding these options to the library browser: - Show symbols where footprints are... [ ] Through-hole [ ] Basic SMT -- catch-all for single resistors, caps, SOTs, etc. [ ] PLCC [ ] SOIC [ ] SSOP/TSSOP [ ] BGA [ ] Board-edge devices [ ] Unspecified - Well, this looks like either (1) multiple available libraries, pick one, or (2) what I proposed for the component database model. It sounds like we're agreeing that geda needs a way to manage libraries, at least, rather than having a library. We *do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI :-) Careful, you'll incur John Doty's wrath. ;-) I've always thought of gattrib as gnetlist's GUI but they're not *that* related. The component database (i.e. netlister's metadata) idea *would* make then that related, though. Gattrib would become the metadata GUI. ___ 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
I'm hoping for a better way for them to do the work or even, machine does most of the work Teach them to fish and all that. Teach them to fish, yes, but make them figure out how to make a fishing pole from scratch? *I* might like that, but most users wouldn't. Hence the it should be easy part. (if I only knew how to make it so). That's the problem, yes. We can all come up with great ideas, but someone has to be able to turn them into reality. Yes, this too. I've naively wished a thousand times or more for a machine that could take as its input a pdf datasheet, and produce as its output, symbols and footprints in some magically standardized format. My twopad and dilpad CGIs were designed for this, sort of. You fill in whatever parameters the datasheet decided to give you, it generates a suitable footprint. ___ 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 Fri, 20 May 2011 22:37:58 -0400 DJ Delorie d...@delorie.com wrote: Ok, then how do we generate the thousands, if not millions, of symbols we'll need? I've been thinking about that, and to be blunt, I have no frickin' clue. ;-) Maybe some clever scripting against a set of generic parts (similar to what I did with those footprints I just submitted). Yup, I also figured you'd need some sort of database-driven scripting to generate them all. [...] Then we replace the database with a CGI at digikey... ;-) At first, I laughed, but then I began to wonder about that Of course, we just reversed this for the M4 footprint library. Mostly because M4 is a bad choice these days, though, not because scripting itself is bad. The only fair way to handle this is to use gschem to conduct a sort of extended poll I wouldn't want information about user's schematics leaked, the privacy issues are too dangerous. I suppose that's true. However, we could collect stats about things downloaded from, say, gedasymbols. Perhaps we could have a small number of starter libraries on gedasymbols, and the geda installer prompts you to pick one to download. We track how many downloads of each, and use that to decide which to include in the distribution. That's a good idea, as long as the symbols are easy to install - probably a good idea to add an option to download and install them, sorta like Firefox's add-ons manager. How about adding these options to the library browser: - Show symbols where footprints are... [...] Well, this looks like either (1) multiple available libraries, pick one, or (2) what I proposed for the component database model. It would probably require a database, yeah. Still, I was thinking of it in terms of filtering the view against the entire library, and the user could have all checkboxes ticked if they want to see everything all at once (i.e. like now). It sounds like we're agreeing that geda needs a way to manage libraries, at least, rather than having a library. We *do* have the option of changing our symbol-footprint library into a symbol-metadata-footprint scheme. Maybe gnetlist is feeling left out, and wants its own library and GUI :-) Careful, you'll incur John Doty's wrath. ;-) I've always thought of gattrib as gnetlist's GUI but they're not *that* related. True, but in this case I was thinking of his argument that adding GUI options to something automatically breaks it. :-) -- 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: Solving the light/heavy symbol problem
However, we could collect stats about things downloaded from, say, gedasymbols. Perhaps we could have a small number of starter libraries on gedasymbols, and the geda installer prompts you to pick one to download. We track how many downloads of each, and use that to decide which to include in the distribution. That's a good idea, as long as the symbols are easy to install - probably a good idea to add an option to download and install them, sorta like Firefox's add-ons manager. I think we should start thinking in terms of libraries, not individual symbols. Adding a gedasymbols library should be as simple as downloading some metadata about the library (title, author, url, copyright, index, description) and then choosing if you wanted to download a tarball for local access, or talking to gedasymbols directly (automatic updates might break your schematic though). Such libraries can be as small as a few parts, or as big as a digikey database, but we should expect them to include both symbols and footprints, and if we got the metadata route, the metadata. I.e. make them self-contained. or libraries could have a depends-on tag in them for other libraries, I suppose. A Renesas MCU symbol library could depend on a generic chip package footprint library. We should still support individual symbols and footprints, of course, but I'm thinking the expectations work better if we prefer groups of self-consistent symbols and footprints. For example, a transistor from the Vanessa library would use footprints from the Vanessa library, even if same-named footprints were available elsewhere. Hmmm... we'd have to keep track of the chain of origin for each symbol/footprint, so if you modify a Vanessa footprint and store it in your local library, the tools know to use that one instead of the original Vanessa one. It would probably require a database, yeah. Still, I was thinking of it in terms of filtering the view against the entire library, and the user could have all checkboxes ticked if they want to see everything all at once (i.e. like now). Yup. I figured you could have site rules, project rules, and if that doesn't narrow it down, a popup telling you what choices remained. The project rules would be your checkboxes, either a custom menu that turns into a database query, or data-driven pick from the following like digikey's search engine. With clever database choices, they'd both be the same anyway :-) But if we're adding support for multiple libraries, that complicates things. I'm not sure if such a feature (multiple libraries) belongs in geda/pcb themselves, or hidden behind some data server that combines the available libraries and presents one unified library to the tools. But enabling/disabling libraries could serve the same function as your filter box, if the libraries are set up right. Maybe we'll end up needing both. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
