Hi DJ and all, On Sun, 2008-09-28 at 00:06 -0400, DJ Delorie wrote: > > What do people think of the whole idea of running an external program > > (like Cvpcb) to assign footprint information? > > What, like gattrib? ;-) > > I've stated this before, but to recap... > > The schematic symbols should be as light as possible, with some > database mapping symbols to physical devices, so that the user can go > through some multiple choices to choose the device from the symbol. > That implies a range of attributes, such as footprint, pin mapping, > manufacturer, etc. Gschem would need a way of keeping track of which > attributes were user-selected and which were implied by database > search results. > > So when I put in a NAND gate, I can later choose a 74ALS00N or > 74LVS1G00PY or whatever physical chip I want, and it chooses the right > footprint and pin numbers for that physical chip. If I put in a > resistor, I can later choose a 1.00K with 0603 footprint, and let it > tell me which vendors offer the lowest price (if it can't find it in > inventory :) >
IMHO, I think that based on Levente's work this is feasible. However, that is not where the real problem lies, we have to think further down the road. The issues are many-fold: One issue comes with the sheer numbers of mapping data to be put into the "system" of the "external program" and have to be validated (to be of any value) and maintained (in git ?) once the method is created and implemented in gschem/gnetlis/gattrib/(x)gsch2pcb/"yet another unix tool in the gEDA tool chain". Another issue is the maintenance of mapping data. The mapping data has basically the same characteristics and issues that footprints and symbols outside the repositories have, that is symbols and footprints in gedasymbols.org. Maintaining all this content in Git gives the advantage of traceability of the data in the repository (who/what/when/why), being either mapping data, a pcb footprint or a gschem symbol. <shameless plug> Advocating for a git-based system with capabilities like http://github.com here. Github is claiming to offer "social code hosting", let's offer "social gEDA hosting". </shameless plug> Who is going to implement/maintain all this content/information then ? We, the gEDA (user) community :) so let's make things easy for ourselves from the start. Issue #1: a method for mapping data from known physical packages into the gEDA workflow. Possible solution: implementation based on Levente's work (it works for him, doesn't it ?). By who: the gEDA-dev community. Issue #2: content (mapping data). Possible solution: contribution of meta-data from only projects at hand. This is to keep it lean, and free of stuff _nobody_ uses. Only add information if you need it now and in the foreseeable future (do we have all symbols and footprints of all vacuum tubes ?). By who: the gEDA-user community. Issue #3: management of mapping data. Possible solution: git repository for mapping data with peer review (validation). By who: gEDA-dev community for hosting the git repository, gEDA-user community for managing the mapping data. Issue #4: how to keep the "burden" of learning git for the gEDA-user as low as possible. Possible solution: wrappers for pushing/fetching/pulling/committing in a pull down menu (gschem/gattrib) or automated (gnetlist/gsch2pcb/"yet another unix tool in the chain"). By who: gEDA-dev community. Issue #5: how does the user find the mapping data (footprints/symbols) ? Possible solution: I have seen some threads a couple of days ago: http://www.seul.org/pipermail/geda-dev/2008-September/006172.html this is a possible start for the way mapping data (and footprints and symbols) can be browsed. By who: the gEDA-dev community for implementing the browse functionality (with a template with "standard" bookmarks), the gEDA-user for maintaining his/her "bookmarks". I'm sure more issues will emerge once started with implementing stuff. Just my EUR 0.02 on the subject. With kind regards, Bert Timmerman. > Etc. > > > > _______________________________________________ > geda-dev mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
