Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reusing code / generating multiple footprints per file #80

Open
matthijskooijman opened this issue Jan 30, 2015 · 1 comment
Open

Reusing code / generating multiple footprints per file #80

matthijskooijman opened this issue Jan 30, 2015 · 1 comment
Milestone

Comments

@matthijskooijman
Copy link

I just stumbled upon madparts and it seems to close to what I was looking for. IIUC, now every part needs a full coffeescript program to generate. This seems a waste, since a lot of parts are really similar - a single program could just generate all DIP-xx footprints. This would mean you can just trivially generate all DIP footprints that are in use, and also easily add a new one.

I could see two ways to handle this:

  • Allow defining library functions / parametric parts and call those from other parts. This means you'd have a DIP-8 part, that calls generic_dip(8), where the latter handles the generation. This is still a bit cumbersome since you need a separate file and metadata for each footprint. The upside of this is that you can easily add DIP-1234 in your own code if you stumble upon a really weird DIP footprint without having to modify anything.
  • Allow a single file to generate multiple parts. Then you can just write a for loop over 2, 4, 6, etc. and generate DIP-x parts on the fly. This would require the metadata to be generated by code as well though, since (some of) the metadata will be different between parts.

Ideally, you'd have both options: Have a single DIP file that contains a loop, in which it calls to a generic_dip library function to do the actual work. This means only 1 or 2 files involved, but also easy reuse of code later.

You can also imagine multiple levels of reuse and generalization - the pins of a DIP footprint really are just a two-dimensional pin array with a particular pitch, and could reuse the same code as for a simple pin header footprint.

@andete
Copy link
Owner

andete commented Jan 30, 2015

Hey Matthijs,

I fully agree some kind of parametric footprints would be really nice.
Option one has already been discussed once in another comment.
I'm not so keen on having multiple parts generated by one file as I tend to more specific footprints rather then less specific ones lately.
Another option is having the parametric part and having to fill in the parameters on export.

@andete andete added this to the 3.0 milestone Aug 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants