1–10 of 68 posts
I designed my LED matrix PCB with code
docs.tscircuit.com
Nice idea.
Horrendous routing
As you did this, a graphical window would show your components and traces. I considered similar to a legacy AutoCAD, way back before pointing devices were commonplace.
I had a whole simple dialect to easily identify traces, which you would continuously split with points, then nudge them around or anchor next to other points.
I honestly felt, especially for the small board project I was working on that writing this from scratch would have been faster than fighting KiCAD or any of the similar tools.
But I was stymied with finding a good way to get graphics out of CL on my Mac. I even considered doing it all in SVG with some kind of auto reloading file, and just rewriting it each time.
Obviously I did not put a lot of effort into it, had enough friction to move on to something else.
Even with better results, the big issue with tools like these is that they simply don't match with the kind of development style that's needed for the problems at hand. You see the same issue with those drag-and-drop visual programming languages, or scripted modeling like OpenSCAD: they end up making fairly trivial details slightly easier, while significantly complicating the meat-and-potatoes. Nobody cares about a neat little part placement for-loop if it generates a living hell of autorouted spaghetti you can't possibly interpret and fix manually.
In reality the low-hanging fruit has already been covered by existing tooling. Automatically generating symbols and footprints from textual descriptions is routine practice, and software like KiCad already has a reasonably usable scripting API and a well-documented file format. A lack of code-based code-based EDA hasn't stopped projects like Ergogen[0] from popping up. The main limitation for additional automation is a lack of reliable input data, and user-side tooling can't fix that.
i scaned the article but didn't see this. declarative netlist is probably ultimately the right thing. but one place where I got alot of leverage was writing generators for footprints. its so much nicer to say 'this pad is 0.8 x 0.3" and i'd like two rows of them separated by 4mm with a 1mm pitch than to draw little rectangles with the mouse and getting them all to line up. i dont know if more professional tools do th…
The datasheets often show measurements like the horizontal distance between the leftmost side of the left-row pads and the rightmost side of the right-most pad, and the distance between the rightmost side of the left-row pads and the leftmost side of the right-row pads.
Converting that into the stuff you need to enter in the editor (width of pad, distance between center of pad and center of footprint) isn't hard, but it is cumbersome and error-prone. Being able to directly enter it as constraints[0] would make it literally an order of magnitude easier to input, and it would allow for a simple 1:1 comparison with the datasheet for verification.
[0]: Something like https://wiki.freecad.org/images/thumb/7/71/FC_ConstrainedSke...
i scaned the article but didn't see this. declarative netlist is probably ultimately the right thing. but one place where I got alot of leverage was writing generators for footprints. its so much nicer to say 'this pad is 0.8 x 0.3" and i'd like two rows of them separated by 4mm with a 1mm pitch than to draw little rectangles with the mouse and getting them all to line up. i dont know if more professional tools do th…
Honestly? I want a footprint editor with constraint-based modeling. The datasheets often show measurements like the horizontal distance between the leftmost side of the left-row pads and the rightmost side of the right-most pad, and the distance between the rightmost side of the left-row pads and the leftmost side of the right-row pads. Converting that into the stuff you need to enter in the editor (width of pad, dis…
