gEDA-user: geda for open hardware
I've been thinking a bit about gEDA for open hardware lately, and have a few thoughts that I was wondering if people on the list would help me think through: 1) open hardware implies (to me anyways) that someone has produced a PCB and makes available the schematics, layout, symbols, footprints, and BOM. 2) The new user, wanting to modify the hardware, should be able to copy in a few extra components into the schematic and gsch2pcb back to pcb, but the previous layout shouldn't be changed at all, just a few extra components are available to be added. gsch2pcb already supports this pretty robustly. 3) the new user then places the new components and adds/modifies traces as necessary to get it to work. The question is, is there an approved solution for packaging all the necessary materials to ensure someone developing hardware can ensure the new user has everything they need to accomplish 1-3 above? I assume it would extract symbols and footprints and encapsulate the versions of PCB/Gschem used to create the PCB. I also assume that it should somehow distinguish between core symbols and footprints, and custom ones. Of course, then, the core ones would also need a version number, I suppose, in case they change. Thoughts??? Kurt ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: geda for open hardware
The open hardware distributable you are thinking about has the same requirements as the creation of a project archive. Some EDA tools give you a way to create a self-contained project archive which you can put into a database or write out to a CD and stick on the shelf with reasonable confidence that you can return to it some years later, open it up, and everything will be ready to go. Long ago I wrote something called garchive which is part of gEDA/gaf. It only archived schematics. You would call it using one or more .sch files as the args. It tried to pull copies of all symbols you used out of the symbol libs and stick them in a new directory, then it would tar gz up the whole thing into a convenient tarball. Then, to open an archive, you would pass it the name of the project archive tarball, and it would open up the tarball and put everything into place, ready to use. That program had a few defects, most notably that it did not archive PCB files. It also only guessed the symbol lib path, so if you did something screwey, then it would not necessarily find the right symbols. Finally, I haven't touched it in years, so it probably suffers from severe bit-rot now. Anyway, my point is simple: Requirements for an open-hardware distributable are the same as requirements for a project archiver. IMO, the best solution is some convenient method of finding or specifying all dependencies in your project, and then creating .tar files with all dependencies placed into the .tar file. Stuart On Wed, 17 Jun 2009, KURT PETERS wrote: I've been thinking a bit about gEDA for open hardware lately, and have a few thoughts that I was wondering if people on the list would help me think through: 1) open hardware implies (to me anyways) that someone has produced a PCB and makes available the schematics, layout, symbols, footprints, and BOM. 2) The new user, wanting to modify the hardware, should be able to copy in a few extra components into the schematic and gsch2pcb back to pcb, but the previous layout shouldn't be changed at all, just a few extra components are available to be added. gsch2pcb already supports this pretty robustly. 3) the new user then places the new components and adds/modifies traces as necessary to get it to work. The question is, is there an approved solution for packaging all the necessary materials to ensure someone developing hardware can ensure the new user has everything they need to accomplish 1-3 above? I assume it would extract symbols and footprints and encapsulate the versions of PCB/Gschem used to create the PCB. I also assume that it should somehow distinguish between core symbols and footprints, and custom ones. Of course, then, the core ones would also need a version number, I suppose, in case they change. Thoughts??? Kurt ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: geda for open hardware
Note that PCB files are self-contained; you do not *need* to include separate footprints for anything already on the board. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: geda for open hardware
KURT PETERS wrote: I've been thinking a bit about gEDA for open hardware lately The question is, is there an approved solution for packaging all the necessary materials to ensure someone developing hardware can ensure the new user has everything they need to accomplish 1-3 above? I approve of John Doty's project dir oriented method of managing symbol and footprint libraries. Just documenting that method would get you a system usable by free-hardware reference design users. With the project dir method, there is no extracting to do at project end...you've already done it by the time it is complete, and core libraries are still the same as was originally distributed. Adding versions to the symbols and footprints would help with uses of the core libraries and get gEDA past a big complaint of newbies, the standard library seems incomplete! Versions on every symbol or footprint would let core library components be used in a confirmed way. Some kind of error handling coding might be needed for the case of opening a reference design three years older than current gEDA tools. I assume it would extract symbols and footprints and encapsulate the versions of PCB/Gschem used to create the PCB. I also assume that it should somehow distinguish between core symbols and footprints, and custom ones. [jg]May not need. See above. Of course, then, the core ones would also need a version number, I suppose, in case they change. Yes. Stuart Brorson wrote: my point is simple: Requirements for an open-hardware distributable are the same as requirements for a project archiver. IMO, the best solution is some convenient method of finding or specifying all dependencies in your project, and then creating .tar files with all dependencies placed into the .tar file. I think it needs to go further with a documented work style as the suggested way of dealing with reference designs by people new to gEDA tools, perhaps... (nahhh probably 95%) using windows... -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: geda for open hardware
John Griessen wrote: I approve of John Doty's project dir oriented method of managing symbol and footprint libraries. I may be under-caffeinated, but isn't there already a menu/cmdline option to tell gschem to pull symbol definitions into the sch file when they're found/added to a schematic? With that information and version attributes, gschem could ask, I found a newer symbol definition in the system, update the schematic file? at startup. I have recently learned about the really-handy way gschem lets you descend into a symbol definition file from a schematic, so that you can edit it. When I go back up into the schematic, I select Edit|Update Symbol and the display (at least) updates. Seems like that functionality is partially what the OP is talking about. get gEDA past a big complaint of newbies, the standard library seems incomplete! There was recent discussion on this list on ideas to make gedasymbols.org (or something like it) available as a symbol library to gschem/pcb. I think that those ideas (along with a management strategy for the resource) would also help to both reduce the complexity of a default gaf installation and also make it easier to distribute new symbols and footprints. Some kind of error handling coding might be needed for the case of opening a reference design three years older than current gEDA tools. Shouldn't be a problem if the design files also incorporate the footprints and symbols used. So long as the overall syntax of the design files themselves is maintained... b.g. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: geda for open hardware
The solution I always liked was making a simple live CD with the project documentation and all. This is not for distribution it is because about every 6 or 7 years I end up changing tools and can't find anything to read my old stuff. On Wed, Jun 17, 2009 at 10:19 AM, KURT PETERSpetersk...@msn.com wrote: I've been thinking a bit about gEDA for open hardware lately, and have a few thoughts that I was wondering if people on the list would help me think through: 1) open hardware implies (to me anyways) that someone has produced a PCB and makes available the schematics, layout, symbols, footprints, and BOM. 2) The new user, wanting to modify the hardware, should be able to copy in a few extra components into the schematic and gsch2pcb back to pcb, but the previous layout shouldn't be changed at all, just a few extra components are available to be added. gsch2pcb already supports this pretty robustly. 3) the new user then places the new components and adds/modifies traces as necessary to get it to work. The question is, is there an approved solution for packaging all the necessary materials to ensure someone developing hardware can ensure the new user has everything they need to accomplish 1-3 above? I assume it would extract symbols and footprints and encapsulate the versions of PCB/Gschem used to create the PCB. I also assume that it should somehow distinguish between core symbols and footprints, and custom ones. Of course, then, the core ones would also need a version number, I suppose, in case they change. Thoughts??? Kurt ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- http://www.coe.neu.edu/~efoss/ http://evanfoss.googlepages.com/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
