this is pretty cool
Show HN: Atopile – Design circuit boards with code
171–180 of 300 posts
Re: Show HN: Atopile – Design circuit boards with code
#172I like the idea in general, but I absolutly hate it when people invent their own weird programming language instead of using a well defined existing one... Why not just use Python?
Sir, this is Hacker News.
Re: Show HN: Atopile – Design circuit boards with code
#173Earlier quoted context omitted.
We do agree. We built an early version of a viewer in the project but later moved away from it because it wasn't good enough to interact with. We might come back to it with something that is more targeted at inspecting only sections of the circuit or provide a block diagram level representation. But we don't think that just outputting a schematic the way they look today is the right solution.
You might find this a stumbling point for adoption. My first thought is this could be a good tool for me to use, but how can I send a design to someone else to get feedback on if I’m not going to expect them to also also learn how to use this or how can I get my design manufactured if the tools can’t export out the, normally very visual, layout files.
I do think that is fair. The reason that we don't have a visualizer is not that we don't want one, but rather that the value to effort ratio is quite low (and really because the effort is high, not because of low value). I'm sure we'll get there at some point. But at the moment there are more pressing issues for the people who are ok dealing with no visualization (like typing, language server, equations etc...).
Re: Show HN: Atopile – Design circuit boards with code
#174I like the idea in general, but I absolutly hate it when people invent their own weird programming language instead of using a well defined existing one... Why not just use Python?
Great question! We hope we have a few good reasons.
This iteration of the project actually came after first working with and then modifying another awesome project called SKiDL (https://github.com/devbisme/skidl).
It's based on Python - but we found that since it's procedural, turing complete and has a rich eco-system - people use to that and there aren't standard composable ways of designing things. Instead of describing your board, you (practically) write a script that generates your board. It entangles your targets with your source-code and can make it difficult to understand the ultimate outcome of what you've written.
Additionally, since it's a potentially very long program, it was hard to write good language support around (a language server for VSCode, a schematic visualiser etc...) that were snappy, responsive and lent to examining modules as well as the whole program.
There's a few operators and first-class language features we wanted as well, like units and tolerances (3.3V +/- 100mV) that just aren't the same when embedded in a string, or class init method.
Re: Show HN: Atopile – Design circuit boards with code
#175Earlier quoted context omitted.
Specifically on the layout section, I have been thinking along the lines of start with sensible 'seed' layouts that users will contribute, then mutate the layouts with a physics driven solver. Imagine links between components as a spring and repulsion forces to model creepage/clearance distances, you could imagine the layout warping into a suitable shape for your board. I am pretty excited to get to this bit.
As someone who just taught themself Kicad to make a simple MIDI controller PCB usi an STM32F4, I was totally blown away, coming from software, how "manual" everything was, how abstruse and arcane. It's quite difficult as a beginner to know that a design is "correct", or perhaps "correct enough", with respect to component placement and EMI. It seems like even top EE who specialize in board design utilize rules of thum…
Yes, it is like 90% rules of thumb and experience. The reason being simulation is expensive: not just in the software itself, but in the time it takes to learn how to use it, set it up for a particular design, and then run through it and understand if it's actually reflecting reality or not. I've been working on some projects where we really care deeply about noise performance, and even the super-expensive packages which exist (which we can't really afford) don't seem to actually be able to answer the questions we have about the design. Autorouting is similar, autoplacing is basically a disaster here.
I am confident a lot of this is an accessibility and UI issue: if you want to disrupt this you could focus on making simulation and auto-placement tools that are cheap and actually usable, and help inform the rules-of-thumb. But that's a very big investment and mostly orthogonal to making a different way to specify your netlist.
Re: Show HN: Atopile – Design circuit boards with code
#176Could you please explain the difference between Atopile and Jitx ( https://www.jitx.com/ )? Both seem to provide software-defined hardware development.
Our language is also a markup language more than a programing language. The goal here is that we would want the code to become a description of what the circuit is, instead of how to obtain it. The obtaining part is the job of the compiler. Not the human.
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...
Re: Show HN: Atopile – Design circuit boards with code
#177Earlier quoted context omitted.
As someone who just taught themself Kicad to make a simple MIDI controller PCB usi an STM32F4, I was totally blown away, coming from software, how "manual" everything was, how abstruse and arcane. It's quite difficult as a beginner to know that a design is "correct", or perhaps "correct enough", with respect to component placement and EMI. It seems like even top EE who specialize in board design utilize rules of thum…
Yes, it is like 90% rules of thumb and experience. The reason being simulation is expensive: not just in the software itself, but in the time it takes to learn how to use it, set it up for a particular design, and then run through it and understand if it's actually reflecting reality or not. I've been working on some projects where we really care deeply about noise performance, and even the super-expensive packages w…
We share similar thoughts about the core of the auto-routing/placement/simulation issues being UX! We're a bit more bullish on code being able to fix that as well.
Noticing that these tools are infrequently even configured because it's simply too much of a pain to do so for every new design - we're hoping the expressive, reuse-focussed code-based-approach means people need to capture these things once and then everyone gets to reuse them.
This is all a while away, but after we're able to get design currently captured in schematics working smoothly we certainly plan to tackle auto-routing/layout as well
Re: Show HN: Atopile – Design circuit boards with code
#178Earlier quoted context omitted.
You might find this a stumbling point for adoption. My first thought is this could be a good tool for me to use, but how can I send a design to someone else to get feedback on if I’m not going to expect them to also also learn how to use this or how can I get my design manufactured if the tools can’t export out the, normally very visual, layout files.
I do think that is fair. The reason that we don't have a visualizer is not that we don't want one, but rather that the value to effort ratio is quite low (and really because the effort is high, not because of low value). I'm sure we'll get there at some point. But at the moment there are more pressing issues for the people who are ok dealing with no visualization (like typing, language server, equations etc...).
I’d definitely consider not letting some basic visual schematic outputs fall too far down the priority list.
A lot of existing EE is basically just the visual diagrams and a lot of existing EE people will expect the tools to give them the visual diagrams they work with somehow… like even just including the compiled schematic as an SVG in with the compiled outputs of netlist, gerber, etc… something that other software can be used to convert to PDF without extra complexity in your tool and can be used to interoperable with the existing talent pool of EE people who have not just no idea how to use your tool… but know how to read typical style circuit diagrams.
Re: Show HN: Atopile – Design circuit boards with code
#179This is an amazing concept.
You still need heavy EE understanding to know how to develop PCBs, so it’s not going to turn every software engineer into a PCB pro, but it could totally change the game for EEs that can learn to code.
This is definitely a step in the right direction though and I’m wondering how much of a PCB can be represented in an abstract syntax tree or something similar. Are there edge cases, or could you completely describe a PCB layout using code?
Re: Show HN: Atopile – Design circuit boards with code
#180This is an amazing concept. You still need heavy EE understanding to know how to develop PCBs, so it’s not going to turn every software engineer into a PCB pro, but it could totally change the game for EEs that can learn to code. This is definitely a step in the right direction though and I’m wondering how much of a PCB can be represented in an abstract syntax tree or something similar. Are there edge cases, or could…
Definitely agree this isn't taking away EEs - anytime soon or ideally ever! The goal is to make EEs far more potent, rather than bring SWEs to hardware (although letting them easily tweak existing board's filter constants, vdivs etc... would be awesome too!)
We're honestly not sure how explicitly we want to describe a layout in code, or if it's a more declarative thing. Currently we're leaning more towards the declarative approach (eg. this trace carries 100mA of current) rather than the imperative (this trace is 0.150mm wide) since it should scale more intuitively with equations and layer better with DFM specs etc...
Have you got some ideas?