| blob | 95316d24fabfde5945b9d51f4cb8d793bfc29532 |
3 <html>
4 <head>
5 <title></title>
11 </head>
12 <body>
15 <h1 class="sectionedit1375"><a name="what_s_the_best_way_to_learn_to_use_geda" id="what_s_the_best_way_to_learn_to_use_geda">What's the best way to learn to use gEDA?</a></h1>
18 <p>
19 The first thing to do is to read and understand Bill Wilson’s excellent <a href="geda-gsch2pcb_tutorial.html" class="wikilink1" title="geda-gsch2pcb_tutorial.html">gschem -> gsch2pcb -> PCB</a> tutorial and/or the DJ Delorie’s <a href="http://www.delorie.com/pcb/docs/gs/gs.html" class="urlextern" title="http://www.delorie.com/pcb/docs/gs/gs.html" rel="nofollow">pcb tutorial</a>. This should get you started.
20 </p>
22 <p>
23 Also be sure to check out the other <a href="http://geda.seul.org/wiki/geda:documentation" class="urlextern" title="http://geda.seul.org/wiki/geda:documentation" rel="nofollow">gEDA documentation</a> available on this website.
24 </p>
26 <p>
27 However, the best way to learn the gEDA Suite is to download it and try it out yourself! If you consult Bill Wilson’s tutorial while trying the suite for yourself, you will become an expert in no time!
28 </p>
30 </div>
31 <!-- EDIT1375 SECTION "What's the best way to learn to use gEDA?" [1-646] -->
32 <h1 class="sectionedit1376"><a name="what_does_the_design_flow_in_geda_look_like" id="what_does_the_design_flow_in_geda_look_like">What does the design flow in gEDA look like?</a></h1>
35 <p>
36 Here is a quick graphic for simple PCB design flow using the gEDA Suite:
37 </p>
39 <p>
40 <a href="media/geda/design_flow.jpg" class="media" target="_blank" title="geda:design_flow.jpg"><img src="media/geda/design_flow.jpg" class="media" alt="" /></a>
41 </p>
43 <p>
44 In words, the design flow for a simple PCB proceeds as follows:
45 </p>
46 <ol>
48 </li>
49 <li class="level1"><div class="li"> Check your schematics with the DRC checker. Learn about it <a href="geda-faq-attribs.html#how_do_i_check_my_schematics" class="wikilink1" title="geda-faq-attribs.html">here</a>.</div>
50 </li>
51 <li class="level1"><div class="li"> Assign reference designators to your components using “grenum” or “refdes_renum” (or just attach them manually from within “gschem”).</div>
52 </li>
53 <li class="level1"><div class="li"> Assign other component attributes (such as component footprints) using “gattrib” (or just attach them manually using “gschem”).</div>
54 </li>
55 <li class="level1"><div class="li"> Create a preliminary layout file and netlist using “gsch2pcb”.</div>
56 </li>
58 </li>
59 <li class="level1"><div class="li"> Output Gerbers from within “pcb” using “File → print layout”, and select “Gerber/RS274X” as the output file type.</div>
60 </li>
61 </ol>
63 <p>
65 If you make changes, or add to your schematic or attributes while in layout, update your board file like this:
66 </p>
67 <ol>
68 <li class="level1"><div class="li"> Edit your schematic and/or attributes (”gschem” or “gattrib”).</div>
69 </li>
70 <li class="level1"><div class="li"> Check your schematics with the DRC checker. Learn about it <a href="geda-faq-attribs.html#how_do_i_check_my_schematics" class="wikilink1" title="geda-faq-attribs.html">here</a>.</div>
71 </li>
73 </li>
74 <li class="level1"><div class="li"> From within “pcb”, update your components using “File → load layout data to paste buffer”, and then click on the drawing area to place the components.</div>
75 </li>
76 <li class="level1"><div class="li"> From within “pcb”, update your netlist using “File → load netlist file”.</div>
77 </li>
78 </ol>
80 <p>
82 Usually, users invoke the individual tools from the command line. A project manager (”geda”) exists, but needs improvement.
83 </p>
85 </div>
86 <!-- EDIT1376 SECTION "What does the design flow in gEDA look like?" [647-2322] -->
87 <h1 class="sectionedit1377"><a name="what_limitations_exist_for_the_geda_tools" id="what_limitations_exist_for_the_geda_tools">What limitations exist for the gEDA tools?</a></h1>
90 <p>
91 The most important thing to keep in mind about gEDA’s limitations is this: GEDA is an open-source software project. It has some limitations, but unlike many instances of commerical software, its limitations are not artificial, arbitrary, or driven by marketeering. That is, gEDA is neither nagware, crippleware, demoware, nor “limited student edition”-ware. Any limitations to the gEDA tools exist because the programmers haven’t yet implemented that particular feature. Since the code is open for all to see and modify, anybody is welcome to implement a new feature or remove a limitation, and then submit their patches to the project. If you are a hacker and are interested in making a contribution to the gEDA project, consider tackling one of the limitations listed below! You will make a lot of friends, and earn international exposure!
92 </p>
93 <ul>
94 <li class="level1"><div class="li"> Hierarchical bus support: Support for hierarchical busses doesn’t exist yet.</div>
95 </li>
96 <li class="level1"><div class="li"> Net and pin attributes in gattrib: Attaching routing attributes for nets and pins in gattrib remains TBD. (Net attributes are useful for high-speed design. For example, it’s often important that all tracks in a bus have the same electrical length. Unfortunately, it’s not clear that PCB will support these routing attributes right now.)</div>
97 </li>
98 <li class="level1"><div class="li"> Backannotation from PCB to gschem. Support for pinswapping and modification of the design file in pcb with subsequent backanno to gschem is TBD.</div>
99 </li>
100 <li class="level1"><div class="li"> The project manager “geda” is out of date, and needs an update.</div>
101 </li>
102 <li class="level1"><div class="li"> Layer count in PCB: Currently, the layer count in PCB is limited to 16 layers plus two silk layers by default. This is more than adequate for small- and mid-sized projects. If necessary, the number of layers can be increased arbitrarily at compile time. </div>
103 </li>
104 </ul>
106 </div>
107 <!-- EDIT1377 SECTION "What limitations exist for the gEDA tools?" [2323-4138] -->
108 <h1 class="sectionedit1378"><a name="what_local_configuration_files_are_used_for_a_project" id="what_local_configuration_files_are_used_for_a_project">What local configuration files are used for a project?</a></h1>
111 <p>
112 A typical PCB design requires the following config files in your local directory:
113 </p>
114 <ul>
115 <li class="level1"><div class="li"> gafrc: This holds configuration info for the gEDA/gaf programs (i.e. gschem, gattrib, gnetlist, etc.). It should hold pointers to your local symbol directory (if any).</div>
116 </li>
117 <li class="level1"><div class="li"> attribs: If you use “gnetlist -g bom2” to create a project BOM, then you need this file in order to specify which attributes are written into the BOM.</div>
118 </li>
119 <li class="level1"><div class="li"> projectrc: When going to layout, “gsch2pcb projectrc” is a convenient way to specify paths to local footprint directories, as well as hold other configuration information for “gsch2pcb”. Note that this file may have any name you choose; I like to use projectrc since its name is suggestive of its function.</div>
120 </li>
121 </ul>
123 <p>
125 Further detailed information about each configuration file is provided in the <a href="http://geda.seul.org/wiki/geda:documentation" class="urlextern" title="http://geda.seul.org/wiki/geda:documentation" rel="nofollow">documentation</a> for each facility.
126 </p>
128 </div>
129 <!-- EDIT1378 SECTION "What local configuration files are used for a project?" [4139-5103] -->
130 <h1 class="sectionedit1379"><a name="what_are_the_names_and_locations_of_the_rc_files_used_with_geda_gaf_applications" id="what_are_the_names_and_locations_of_the_rc_files_used_with_geda_gaf_applications">What are the names and locations of the RC files used with gEDA/gaf applications?</a></h1>
133 <p>
134 The various gEDA/gaf applications (gschem, gattrib, gnetlist, etc.) use a set of RC files to set various configurable options in the tools themselves. These RC files are read in by each application upon start-up. Philosophically, there are three places where a gEDA/gaf application looks for RC files:
135 </p>
136 <ul>
137 <li class="level1"><div class="li"> In the system installation directory: <strong><code>${prefix}/share/gEDA/</code></strong>. This location holds RC files which are global to the entire system, and are common to all users. These RC files must be found and successfully loaded for the gEDA application to work properly. <strong><code>${prefix}</code></strong> is set to the path where you installed gEDA/gaf.</div>
138 </li>
139 <li class="level1"><div class="li"> In the user’s home directory: <strong><code>$HOME/.gEDA/</code></strong>. This location holds RC files which apply to all of this user’s projects. <strong><code>.gEDA</code></strong> is a directory. These files are optional. Do not just place a copy of the system-gschemrc (or whatever) into this directory; this will not work properly. The right thing to do is to override specific things you want to change.</div>
140 </li>
141 <li class="level1"><div class="li"> In the local project directory. This location holds RC files which apply to the local project (which also lives in this directory). These RC files provide specific overrides, such as component or source libraries. This file is also optional. Do not just place a copy of the system-gschemrc (or whatever) into this directory; this will not work properly.</div>
142 </li>
143 </ul>
145 <p>
147 The RC file system has evolved over time. Originally, each gEDA/gaf application used its own RC file (for example, gschem used gschemrc, gnetlist used gnetlistrc, and so on). However, as the number of gEDA/gaf applications grew, it became clear that the individual RC files held a lot of redundant information, and that new users were confused by all the different RC files. Therefore, the different RC files were consolidated into a single file, called “gafrc”. However, because gschem needs all kind of special customizations, we decided to keep the system gschemrc in addition to all the gafrc files. Also, in order to preserve backwards compatibility, the old RC file system is still maintained in the system directory. Accordingly, the current RC file configuration looks like this:
148 </p>
149 <ul>
151 <ul>
152 <li class="level2"><div class="li"> <strong><code>system-gafrc</code></strong> – This contains most of the global gaf settings.</div>
153 </li>
155 </li>
157 </li>
158 <li class="level2"><div class="li"> <strong><code>system-gschemrc</code></strong> – This contains lots of settings specific to gschem</div>
159 </li>
161 </li>
163 </li>
164 </ul>
165 </li>
166 <li class="level1"><div class="li"> In the user’s <strong><code>${HOME}</code></strong> directory:</div>
167 <ul>
169 </li>
170 </ul>
171 </li>
173 <ul>
174 <li class="level2"><div class="li"> <strong><code>gafrc</code></strong> – This should contain your local overrides, such as pointers to locally defined symbols.</div>
175 </li>
176 </ul>
177 </li>
178 </ul>
180 <p>
182 Also loaded by the system-gschemrc is the gschem-darkbg or gschem-lightbg color definitions.
183 </p>
185 <p>
186 Finally, note that gEDA/gaf applications will look for up to six configuration files upon startup:
187 </p>
188 <ol>
190 </li>
191 <li class="level1"><div class="li"> <strong><code>system-gschemrc</code></strong> (or whatever)</div>
192 </li>
194 </li>
195 <li class="level1"><div class="li"> <strong><code>${HOME}/.gEDA/gschemrc</code></strong> (or whatever)</div>
196 </li>
198 </li>
199 <li class="level1"><div class="li"> <strong><code>./gschemrc</code></strong> (or whatever)</div>
200 </li>
201 </ol>
203 <p>
205 If you get a warning that your app can’t find one or another of these files, don’t worry. Most of them are optional. The only required files are the system RC files.
206 </p>
208 </div>
209 <!-- EDIT1379 SECTION "What are the names and locations of the RC files used with gEDA/gaf applications?" [5104-8482] -->
210 <h1 class="sectionedit1380"><a name="what_about_a_project_manager" id="what_about_a_project_manager">What about a project manager?</a></h1>
213 <p>
214 The individual components in the gEDA design suite do not have the concept of an end-to-end project. Rather, they deal with their own files (e.g. “gschem” → .sch, “pcb” → .pcb). However, there is a project manager, called “geda”, which you can invoke from the command line. It’s goal is to help manage your design as a whole as you take it from concept, through schematic capture, attribute attachment, layout, BOM generation, and so on.
215 </p>
217 <p>
218 Unfortunately, development of “geda” has not kept up with the rest of gEDA/gaf. In particular, “geda” does not use the latest tools or methods to accomplish the individual design tasks. Therefore, we recommend that user simply invoke the individual tools (e.g. gschem, gattrib, gnetlist, gsch2pcb, etc) from the command line. Meanwhile, if your are a hacker are looking for a smallish project to adopt, polishing up “geda” would make a nice introduction to the gEDA Suite, and you would make a lot of friends by doing so!
219 </p>
221 </div>
222 <!-- EDIT1380 SECTION "What about a project manager?" [8483-9518] -->
223 <h1 class="sectionedit1381"><a name="can_we_change_geda_to_use_an_xml_file_format" id="can_we_change_geda_to_use_an_xml_file_format">Can we change gEDA to use an XML file format?</a></h1>
226 <p>
227 We have a recurrent debate about <acronym title="Extensible Markup Language">XML</acronym> file formats on geda-user every two or three years. I think it has to do with how long it takes us to lose our institutional memory due to churn on the mailing list.
228 </p>
230 <p>
231 It's unlikely the gEDA Project will ever switch to an <acronym title="Extensible Markup Language">XML</acronym> file format for schematics or symbols, so get used to it. Some reasons against <acronym title="Extensible Markup Language">XML</acronym> are:
233 </p>
234 <ol>
235 <li class="level1"><div class="li"> GEDA/gaf already has a fixed, well documented, <acronym title="American Standard Code for Information Interchange">ASCII</acronym> file format. It's over 8 years old as of 2007. It's well used and well tested.</div>
236 </li>
237 <li class="level1"><div class="li"> We already have a parser for our file format. It's lightweight & thoroughly debugged.</div>
238 </li>
239 <li class="level1"><div class="li"> There are lots of legacy designs using the file format out there already. People would scream if we switched file formats since their old designs would become obsolete. And supporting two file formats – old and new – would be a major <acronym title="Pain in the Ass">PITA</acronym>.</div>
240 </li>
241 <li class="level1"><div class="li"> <acronym title="Extensible Markup Language">XML</acronym> is a generalized file format. Therefore, <acronym title="Extensible Markup Language">XML</acronym> files tend to become bloated pigs. The gEDA file format is light & well adapted to its purpose: representing graphical information pertainent to schematic diagrams in electronics.</div>
242 </li>
243 <li class="level1"><div class="li"> One purported benefit for <acronym title="Extensible Markup Language">XML</acronym> files is that there are lots of open-source parsers for them available, making integration into libgeda trivial. That's the theory, but in reality the job of a parser is to analyze and parse the input, and then stick it into datastructures suitable for use with the rest of gschem's code. An open-source parser does about 1/3 of the job we need (i.e. reading & analyzing the file, and creating some kind of parse tree). The rest of the job involves putting the stuff in the parse tree into libgeda's data structures. That's lots of work. Therefore, the purported advantage of the freely-available <acronym title="Extensible Markup Language">XML</acronym> parser is a chimera. Yes, <acronym title="Extensible Markup Language">XML</acronym> may be of interest for a new program written from the ground up, but not for an existing program like gEDA.</div>
244 </li>
245 <li class="level1"><div class="li"> GEDA developer time is better used on implementing new features like backannotation. Using developer time on porting our file format to <acronym title="Extensible Markup Language">XML</acronym> is a sideways move which doesn't provide the end user any more utility, but soaks up valuable developer time.</div>
246 </li>
247 <li class="level1"><div class="li"> The other benefit of <acronym title="Extensible Markup Language">XML</acronym> is that it is more-or-less human readable. I'll grant that this is a valid assertion. Our current file format is not readable by a human who has never read the documentation. However, our current file format *is* <acronym title="American Standard Code for Information Interchange">ASCII</acronym>, and is completely documented, so an essential reason for readability – the ability to write scripts against the file – is already taken care of. Also, a human can certainly read the file format once he has taken the time to <acronym title="Read The Fine Manual">RTFM</acronym>. Human readability – without knowing the file format – is a “nice to have” which isn't high on my priority list.</div>
248 </li>
249 </ol>
251 </div>
253 </html>