Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Atopile – Design circuit boards with code

news.ycombinator.com

Post reply on HN
Print view View original

271–280 of 300 posts

Re: Show HN: Atopile – Design circuit boards with code

#271

Post by epcoa »

Timot05 wrote: post #252
tcherasaro wrote: post #246

Earlier quoted context omitted.

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 de…

Thanks for your detailed answer! Tons of information in there. To your point about how the work gets divided, I don't think that work will necessarily be distributed amongst many people for a given design but code gives you a couple of benefits: - you can branch and merge the changes you make, which means that you can design a given feature and have your team review only this change instead of reviewing a batch of ch…

> you can branch and merge the changes you make

I don't think this a fundamental exclusive benefit of "code" (ie text). I am skeptical how textual merging, especially default automated, can be applied in this domain except in trivial ways. This is a usually easy sell for software because you can structure your system to localize effects (even if there it isn't perfect). The big guns have very sophisticated workflow and tooling for this.

https://www.altium.com/documentation/altium-designer/collabo...

https://www.altium.com/documentation/altium-designer/using-v...

> code makes it easier for them because more information is captured in the code

I sincerely don't understand. Perhaps it is informative to consider that SPICE has been around for 50 years. The idea of using textual description for circuit design is not new at all, and they are used when appropriate. One must ask why the basic workflow is the way it is when the alternatives have always been possible.

> Currently the schematic forces you to have both the documentation and the implementation baked into the same document

Not entirely onboard with this forcing assertion, but is this necessarily a bad thing? https://en.wikipedia.org/wiki/Literate_programming

Re: Show HN: Atopile – Design circuit boards with code

#272

Post by phkahler »

mawildoer wrote: post #160
addaon wrote: post #112

Earlier quoted context omitted.

Get even a basic equation solver in there and I'll be a user! Have it handle units properly and I'll be a happy user. Have it be able to handle both worst-case and RSS tolerance stackups and I'll be in love.

We're also super stoked about getting topology and equations together in the same file (and even code-base!) The equation solver is soon on our roadmap: https://atopile.io/roadmap/#language-features

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.

Re: Show HN: Atopile – Design circuit boards with code

#273

Post by Timot05 »

phkahler wrote: post #272
mawildoer wrote: post #160

Earlier quoted context omitted.

We're also super stoked about getting topology and equations together in the same file (and even code-base!) The equation solver is soon on our roadmap: https://atopile.io/roadmap/#language-features

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 fro…

Thanks for sharing! We will have a look

Re: Show HN: Atopile – Design circuit boards with code

#274

Post by Timot05 »

assimpleaspossi wrote: post #254

>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.…

Pain might not have been the right word indeed. The aspect we wanted to point to was rather the fact that we had to do it over and over again. And so from that perspective it became a “pain”.

Ultimately we do love electronics. This is one of our attempts to contribute back to the field.

Re: Show HN: Atopile – Design circuit boards with code

#275

Post by Timot05 »

tgirod wrote: post #266

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 me…

Thanks! And glad you are making your way towards electronics.

Yes, we hope for the packages.atopile.io to become a place where you can share your designs and explore what other people have built.

Re: Show HN: Atopile – Design circuit boards with code

#278

Post by robomartin »

tcherasaro wrote: post #246
Timot05 wrote: post #193

Earlier quoted context omitted.

Thanks for sharing this blog post! Super cool to see how things were done early in the industry! Counterintuitively, I do agree with your points. We didn't end up designing the ato language because we actively wanted to end up there but rather because we tried everything else before and none of the solutions we tried worked out. The problem we wanted to solve was: "how does git look like in hardware?". Another way to…

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 de…

> 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.

That's a seriously important point. Open source is filled with just plain horrible code. EE's who are not generally trained in software development can deliver reasonable schematics. There's the potential for utterly unintelligible designs if they had to create them using software techniques. I have seen FPGA code that is most-definitely cringe-worthy and unintelligible without, as you said, stopping to draw a schematic.

One way to think of this --in terms of circuits, not FPGA's-- is that a schematic can stand on its own. A text based netlist, even if sophisticated, requires documentation and, more than likely, a schematic.

Re: Show HN: Atopile – Design circuit boards with code

#280

Post by Mikhail_K »

ss1996 wrote: post #261
Mikhail_K wrote: post #259

Why python? Why sink development effort into an obsolete and deeply flawed language?

Flawed? Sure, although every language has its flaws, some more than others. Deeply flawed? Not really. Obsolete? Lol, what. It's top 3 most popular languages.

> Deeply flawed? Not really.

Python's performance problems are unfixable without wholesale redesign of the language and standard library. Its package management is a bad joke. The developers give no indication that they have any intention to fix those problems, rather than keep stuffing more unnecessary and badly thought-out features into it.

Obsolescence should be gauged by how modern the design of a language is, rather than its popularity. By that measure, Python is manifestly obsolete, and has been even when it debuted.

Post reply on HN