Thanks, I saw that. I guess I’ll have to experiment with it.
Yes, that’s true. But some of the ESP8266 modules have pins along the top or bottom as well as the sides. I just don’t understand what the package keyword does, what its possible values are, and whether it has other specific fields that control it.
The space of all possible parts is much larger than the space of all possible footprints (e.g., there are hundreds of microcontrollers but they all use a much smaller set of packages). So I’d like to define the footprints separately and then associate them to the appropriate symbol when necessary.
Of course, this is just a suggestion and it may not fit with your design philosophy. Either way, thanks for your efforts and for bringing this tool to the KiCad community.
The package specs appear to be hard coded inside qeda code, so that is powerful but not very flexible for the user if custom design is needed.
I guess QEDA is Linux only? Otherwise the part database is lot like one I had envisaged. I think I would also include 3D models in the database. Also, I have come to the conclusion that version control and support for an engineering change process is essential.
Yes, this is the second (and better) way to describe common component packages. It is not hard coded at all. JEDEC MS-026 AEB is translated to outline/jedec/ms-026.yaml, section AEB: see share/outline/jedec/ms-026.yaml
As you can see, sections support even regular expressions.
In theory one may also describe his own outlines and place them near to PCB-project. But custom outlines are not supported at the moment.
No, QEDA is cross-platform (as Node.js). I have tested it against Windows and OS X some time ago. But Ubuntu support in prioritized due to the Linux being my preferred OS.
3D models are planned to be supported after QEDA becomes web-service (details).
Thank you for feedback. Please feel free to open issues on Github with feature requests.
Now I spend my free time to make documentation more complete in order to facilitate using of QEDA.
It is difficult enough having to rely on third-party to update parts, even harder having to rely on third parties to maintain code. To be useful, I think you need to put package generation into user space.
If you specify ‘pattern: mygenerator’ then utility will not find it in its own pattern/default/ nor in pattern/<style>/ (if style is specified). Last searching place is ./pattern/ subdirectory (relatively to current directory). If you place your mygenerator.coffee or mygenerator.js in this subdirectory then it will be called for pattern generation.