[hsgw] built a macropad in Python, and that’s not a strange language to choose to program the firmware in these days. But that’s just the tip of the iceberg. The whole process — from schematic capture, through routing and generating the PCB, and even extending to making the case — was done programmatically, in Python.
The macropad itself isn’t too shabby, sporting an OLED and some nice silkscreen graphics, but the whole point here is demonstrating the workflow. And that starts with defining the schematic using skidl, laying out the board with pcbflow, which uses a bunch of KiCAD footprints, and then doing the CAD design for a case in cadquery, which is kind of like OpenSCAD.
The result is that the whole physical project is essentially code-defined from beginning to end. We’re not sure how well all the different stages of the workflow play together, but we can imagine that this makes versioning a ton easier. Coding a PCB is probably overkill for something simple like this — you’d be faster to lay it out by hand for sure — but it doesn’t really scale. There’s definitely some level of complexity where you don’t want to be clicking an pointing, but rather typing. Think of this as the “hello world” to designing in code.
Some of the tools in the workflow were new to us, but if you’d like an in-depth look at cadquery, we’ve got you covered. [Tim Böscke]’s insane CPU made from 555 timers (yes, really) uses pcbflow. And if you’d like to dig back a bit into the origins of Python PCB design, this post introduces CuFlow, on which pcbflow was based.
Based upon XIAO RP2040 ( https://wiki.seeedstudio.com/XIAO-RP2040/ )
An important piece of Skynet is its ability to upgrade its own hardware
I had a look at SKiDL several years ago, and it’s a project I like. It also makes a lot of sense for some types of schematics. For example a big LED array can be made (including wire connections) with a few nested loops. It can also make a lot of sense for some digital circuits, for example an FPGA. A schematic of a (medium to big) FPGA often consists of big schematic symbols with nothing but labels connected to them that bugger off to other pages of a schematic. Doing that textually makes a lot of sense, and I see also room for integration with the FPGA synthesis tools, so the netlist can be extracted directly from those tools.
I have not looked very deep into SKiDL though, because for the work that I do, a visually oriented schematic fits much better.
I can not imagine a textual approach to PCB layout to work in any sensible way though, but I was curious enough to have a look at this “pcbflow” thing, (apparently a fork of “cuflow”) and tried t have an open view about it. Both the pcbflow and cuflow on github fall short of laying the copper tracks. A bit later I found it uses “turtle syntax” to draw copper tracks, and I saw an example of “r 90 f 2 l 45 f 1 r 45 f 2.5 r 45 f1” for drawing a track. That is horrible to write in the first place, nearly impossible to verify, modify or refactor, and they generate graphical screenshots to look at the PCB if it makes any sense at all. Compare that with KiCad and it’s wonderful interactive router that can push existing tracks aside to make room for other tracks.
I understand and accept it is worthy of a Hackaday article, but I still can’t see how this can have any practical use.
The turtle scares me too, at least for PCB layout. (It’s a fun way to teach kids about programming…)
For digital circuits most HDLs, like verilog and vhdl, have generate statements and loops, so you can do something similar to what you are describing. A lot of FPGA design isn’t about looking at schematics, instead it is about writing hdl and running simulations, so I’m not sure it is really all that useful for that. Some sort of generate or tiling function for making schematics though may be useful.
As for the PCB design and creating the copper traces, I think that using these tools would be one of the worst ways to do it. You would be much faster drawing the traces using normal tools like kicad, that way you can easily see what goes where and adjust it very easily too, if you were just writing code I think it would be difficult to visualise where the traces are, stop them from overlapping and it would be very difficult to adjust them.
Autorouters also generally are not very good, so that isn’t much of an option either.
Haven’t used schematic design for FPGAs since the early 1990s!