X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Fri, 17 Jul 2015 05:14:13 +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] yet another footprint generator In-Reply-To: <20150716204012.8BCFE8038A34@turkos.aspodata.se> Message-ID: References: <20150716204012 DOT 8BCFE8038A34 AT turkos DOT aspodata DOT se> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 On Thu, 16 Jul 2015, karl AT aspodata DOT se wrote: > Igor2: >> lately there was some activity on collecting footprint generators, so I'd >> add mine to the list. It's part of a bigger happening in pcb-rnd: >> - cleaning up newlib >> - replacing the m4 footprint generator with a language-neutral mechanism > > What are your ideas about "replacing m4" ? > > Mine is directly in perl, so I can use all sorts of programming > constructs to generate mult. footprints, and e.g. keep track of bounding > box around all pins/pads. And I think it's easier to use a prog.lang. > than to define a new syntax just for the fp. generator. If I need > something new, eg. a silk cross, I just make a function for it and it > is readily available, I don't have to write a parser too. > Any thoughts ? I agree with these considerations. For the first sight it may seem that footprints are data, but if the parameters get tricky there may be some decisions and calculations the generator should do. In this very simply connector example I avoid overlapping pin rings by adjusting ring sizes when I detect overlap. I can imagine other cases where overlap is exactly what I want or I even want to calculate the size to get proper overlap. So I fully agree that the simplest way is to use scripts. My approach on "replacing m4", is this: 1. I remove all references to m4 from all the sources (... in my fork, obviously) 2. I make the footprint attribute syntax clearly decide whether the user wanted to have a file element or a generator. If the attribute value contains parenthesis, the user wants a generator and the name of the generator is the token before the "(". If there's no parenthesis, the attribute is a file name. 3. There will be a small C lib (and external tool, a minimalistic CLI binary built around this lib) that can interpret the footprint attribute, decide whether it's a generator or not, apply search paths or run generators. The whole thing will be centralized and implemented only once, so gsch2pcb won't need to reproduce parts of the heuristics/code of PCB. 4. Generators are external programs. They are just ran as-is, the system doesn't care about what language they are. They are not in m4 or perl, they are in anyt language you like or coded in C or assembly, or they are even on an external server (and fetched using svn cat, wget, RPC or dns queries, haha). So PCB, gsch2pcb and whatever other tool that needs a footprint just runs the lib descrbed in 3., which in turn calls system() to handle generators (on windows this may need a wrapper, tho, but that's part of point 3.). 5. My generators are in awk, but that's only because I really like awk. I have a common.awk that provides all the building blocks so a typical footprint gen will run some sanity checks on the arguments and run some loops to generate the stuff. Sidenote: a funny little feature: the footprint-to-png converter is a ~200 lines long awk script that converts a PCB footprint file to an animator script. I compiled a "headless" SDL and a static linked animator for the purpose, so I didn't have to install a lot of dependencies on repo.hu. I originally wanted to use PCB for this but the amount of dependencies (even without the GUI hids) made me play a bit with a render script. > >> svn://repo.hu/pcb-rnd/trunk/pcblib-param > > I see you also have an element_begin and element_end, though mine is > called element_start and element_stop; I also have a element_pin func., > seems we have somewhat similar thought about the generator. Cool! I will have functions to generate pads too. I think the PCB footprint format is pretty simple and straight-forward so these utility functions are sort of directly derived from the format, whatever language one uses. > > ... >> http://igor2.repo.hu/cgi-bin/pcblib-param.cgi > > (Your preview is missing the little diamond, for the origo, though I > realize that it is redunant; just used to see it.) Good point, thanks! I will add it. > Isn't silkmark = square or angled difficult to read when the connector > is mounted ? Thus they are options. The default "square" option is what the original m4 script had and is what we have for headers in PCB normally. I think "square" and "angled" are useful if you populate your boards by hand and you also have a key pin or a mark on the connector. I do it often, sometimes with single sided hobby boards of mine and such silk marking saves the some time flipping the board. > Hmm, looking through my own footprints I see that I mostly only use a > quare pin as a marker. Does it help to have it in the silk also ? For me, sometimes. Especially the "external" variant, when I have a board mounted and want to plug in a header that doesn't have a key. Or when everyting is put together, fails to work and I have to debug. Anyway, with the tricky syntax with optional named arguments it's really cheap to have such options without forcing to user to remember the order of 10 positional arguments or specify them every time, so I think my genertors will tend to have such options. Regards, Igor2