Really cool project, now available in the AUR: https://aur.archlinux.org/packages/atopile

Nice project! Coming from computer science, I've been dabbling with electronics a bit. My path so far has been (sorry if I'm pointing the obvious):

0. computer science

1. arduino programming + very basic circuits

2. adding a few chips and talking to them through I2C/SPI: still in digital circuits territory, sending 1s and 0s

3. designing my frist PCBs with kiCAD: a huge learning step, and things start to get a bit messy (component tolerance, transmission delays ...)

4. looking at analog circuitry / alternative current / signal processing : a HUGE uncharted territory, full of promises and headaches.

This trajectory is probably quite common, and I'm sure atopile has a role to play there, when you start growing out of arduino. Making things a bit smoother, searchable, reusable, being able to learn from other people's design - what a wonderful tool it could be!

>Could you imagine the pain of building an entire software product using only assembly code? That’s about how we felt designing hardware.

I've done both. What you called "pain" I called "fun". I started life as an electronic engineer but am now a software engineer and was very comfortable in both areas--including building from the TTL level. So I'm automatically suspicious of anything that calls such things painful.

My kneejerk reaction is "you've never done this professionally" but it's 3am where I'm at and can't watch the video right now.

Solvespace has a nonlinear algebraic equation solver:

https://solvespace.com/index.pl

It's what underlies the geometric constraint solver which you don't need for what you're doing. It's probably worth a look under the hood. You might also read this post from Michael-F-Bryan implementing something similar in Rust:

https://users.rust-lang.org/t/geometric-constraint-solvers-p...

He based his work on what he learned from Solvespace.

Hi, @Timot05. I’m a former EE with 20 yrs experience working in the industry and have designed dozens of very large complex mixed signal PCBAs 4-32 layers, as well as about the same number of large FPGA SoC designs.

I watched the demo video out of curiosity and here’s my 2 cents, though there is a lot to unpack here:

First if you want to know the current state of “how does git look like in hardware” as far as PCBA design is concerned look at Altium which uses git under the hood now to provide a very nice visual way to show differences in both the schematic and PCB layout between versions that solves some real pain points for an EE and therefore EEs actually want it and use it. There are ways to create reusable, version controlled sub-circuits that get put into libraries as well:

https://www.altium.com/altium-365/hardware-version-controlhttps://resources.altium.com/p/introduction-git-altium-desig...

Whatever open source you build should be modeled after that.

I found the above very nice after years of manually using git to version control PCBA designs developed in other ECAD tools like PADS, Orcad, Cadence etc. I even tried to get a couple EE’s and layout people to use my methods of git version control, documented in the README of course, but to no avail, most strictly hardware EEs (with no FPGA or SW background) either can’t grasp git or don’t see the point in spending the time on it. The same people will quickly pay $10k-15k a seat for Altium to get that slick UI on top of git version control because it makes things more visual, not less, which as others have mentioned is important in PCBA design I’ll get to in a second.

But, I understand better what you actually mean because you phrased it another way “how can groups of people coordinate and share their work in hardware?”

That depends of course how / who are you coordinating and sharing with? How are you dividing up the work?

In my experience, even with a very large complex mixed signal design, there is one guy per board, and in the extremely rare case that a single board is being worked by more than one person it is usually divided up by discipline typically, RF, analog and digital and those people contribute their pages in any number of ways including using sub-circuit modules out of an Altium library.

And, EEs lean heavily on reference designs and eval hardware to do their work. Though they do spend a lot of time reading a lot of data sheets they really don’t have time to read most of them, just reference the ones they need to integrate existing designs and handle the new parts of the design (which need to be minimal). They need to get large parts of the working designs handed to them with eval hardware they can test and vet on the bench, and with reference designs (schematics, layout, firmware and some documentation) provided by and supported, somewhat, by the vendors of the major components. Not some open source developers who can’t really support the major components utilized in their designs effectively because they don’t have access to all the information they would need to do that, talk to the fab etc. They can only talk to FAEs, same as all other engineers outside the vendor.

Also, PCBA design is very process oriented. Even if a company doesn’t have a PCBA design process this will not slow down an experienced EE who I say has learned what I call “The process” with a capital T. Schematic capture and layout are 2 very hard and fast steps in that process with boundaries that been defined by decades of EE college curriculum and EDA development that aren’t likely to see any change in EE in the near future, though I think the EDA industry is in need of some disruption somewhere, it is not here.

I started designing CPLDs and FPGAs right as most people had switched from capturing their chip designs in schematic form to capturing them in verilog and VHDL. It was a disaster. Most EEs in that space (including myself for a time) were really bad at architecting their modules and then structuring and writing the HDL code to make sense and be maintainable. Good documentation and block diagrams were essential for development and maintenance. And, after 20 years, it is still a huge problem for a lot of designs. I really wish someone would make a good tool to aid in the construction of block diagrams from the code of large FPGA designs. Too often I would inherit a legacy design and find myself having to spend a week or two creating block diagrams and other documentation for the design.

I shutter to think what it would be like to try to understand and debug a PCBA for a 20 layer board that was just a bunch of code or text and didn’t have a schematic and some decent documentation. It’s bad enough that EE’s are frequently handed a large schematic and layout with little or no documentation for it except a folder full of the data sheets for each component.

I should probably add this:

One of the most useful things when developing anything at all is push-back or criticism. That's where you find value, insight, ideas and learning. I always value counterpoint far more than anyone who keeps telling me how great I am and that all is well.

Very recent example: I enlisted ten people a few weeks ago to critique a presentation I had to give at a conference in Zurich. One person, when I sent her the first draft, told me it was fantastic and that it sounded great. I never sent her version 2. Others pounded me hard with critique from every angle. They got every version until they had nothing negative to say. The last person stuck with me until the very last draft, she critiqued it until we both agreed it was time to let it go and focus on delivering what I had.

I say this to highlight that what I've been telling you is 100% in the spirit of constructive criticism. People telling you this is great is fantastic, but that never helps you make a better product or understand if you are on the right path. Keep going. Do what you believe is right. You don't have to accept or act on any criticism or push-back, listen to it, take it in and then do what you think is right given your objectives.

Please forgive me if you know this already, but just in case: the terms Declarative and Imperative may be useful here.

Declarative: the code describes the desired result.

Imperative: the code describes the operations to take.

Most programming languages are Imperative, but some are Declarative, and some allow a mix of the two. More here: https://www.educative.io/blog/declarative-vs-imperative-prog...