X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 20 Jul 2015 08:27:51 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] pcb-rnd: parametric footprints (status update; wall-of-text) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk Hi again, I've finished most of the infrastructural work on pcb-rnd regarding to the new parametric footprints. Summary of the major changes since the last mail (see rationale at the bottom): 1. Default.pcb: vanilla pcb stores default sytles and layers and sizes in a settings file. pcb-rnd does not do that, but always loads a default.pcb with all the settings when a new pcb is to be created. There is a setting for the path of the default.pcb, the user can change that from the command line. 2. gsch2pcb-rnd uses the same default.pcb 3. Finished moving static footprints (file elements) from newlib to pcblib; I tried to keep only common footprints. 4. Added more parametric footprints (check them: http://igor2.repo.hu/cgi-bin/pcblib-param.cgi). Added funky little parameters to RCY, ACY and ALF: options on marking the polarity or type of the device. 5. I've decided about footprint generator policy vs. geda footprint convetions: I went for the least surprise, so there are no jumps in sizes above specific pin numbers. This is unfortunately not compatible with the footprint naming convention linked earlier in this thread. This decision affects only the stock parametric footprint generators - anyone can easily add new generators doing things differently (see rationale). 6. Link against multiple GUI hids and don't mix them up. I am not sure how vanilla PCB does this. I had to rewrite parts of the mechanism during the scconfig transition. The way pcb-rnd handles it: it is possible to link multiple GUI HIDs to a single executable and it will be possible to select the hid to start in a command line argument. I plan to finish the install scripts this week, test the stuff on clean systems and roll a new release. Rationale: 1. and 2.: gsch2pcb had its own defaults (I think derived from gnetlist's gsch2pcb output). If I had another tool that had to generate a PCB, it'd suffer from the same problem: it either loads PCB setting files or has its own defaults. In the new setup, the external tool only needs to insert default.pcb. Most often it's a blind copy. In worst case some tools may need to understand some parts of default.pcb, but these tools should already have an understanding on the PCB format so this is better than getting them to learn the settings format too. The way vanilla pcb handles the default font is very similar to the above mechanism, so there has been a precendet for this in pcb already. 3. Libraries shipped with the software should be small and should contain only the most common footprints. Extra footrpints should be downloaded by the user. Deciding what counts as "common" is subjective, obviously. 5. Selecting the footprint for a new device is always an extra effort. This effort can not be saved with any sort of defaults. The process should involve looking at the 2..3 major dimensions in the datasheet and checking whether they match the footprint in PCB. If this step is necessary, I find it more convenient to have footprint generators always do the same, not having sudden jumps in sizes/behavior at specific pin numbers but let the user explicitly (and easily) specify the main dimensions. This means a dip(8) is as narrow as a dip(40). A wider variant is dip(8, 600) or dip(40, 600). The user needs to check the width anyway: - with geda conventions to make sure the tools won't introduce an unwanted jump in width; - with my footprints to make sure the width matches or to specify the exact width. I also prefer the actual numbers instead of M or N suffixes - the dimension can be looked up in the datasheet, while custom suffixes require an extra step of checking against tool conventions. I've implemented the same policy in SO*, SSOP*, TSSOP*, etc. There is a mechanism so that a footprint generator can call another with setting up some of the parameters. This means for those who prefer the "jumpy" convention, it is easy to create a wrapper that changes the parameters (deriving them from pin number or whatever other parameters) and then calls the original generator. 6. Especially useful for testing: don't have to compile and run different binaries to test whether all GUIs are still working on my developer system. For an end user having a GUI hid and the batch hid selectable from tthe command line may be useful too. Feedback, testing, contribution are welcome. Regards, Igor2