Show HN: Atopile – Design circuit boards with code
Could you imagine the pain of building an entire software product using only assembly code? That’s about how we felt designing hardware. We don’t currently have good ways to describe what we need, reuse existing designs and compile that description down to a product.
We started atopile to fix this. atopile is an open-source language and toolchain to describe circuits with code. The compiler is here: https://github.com/atopile/atopile Docs are here: https://atopile.io/getting-started/ . For a detailed deep dive designing an ESP32 module, see this video: https://youtu.be/eMWRwZOajdQ
We realized this was a problem in our previous jobs. Narayan and I (Tim) had to manually, draw and export all our electronic circuit boards. This lasted until our friend Matt, a software engineer, showed us his development workflow. All his projects were built, tested, and merged automatically via GitHub. So we asked: Can we build the same for hardware?
We observed that the ability to abstract electronics effectively hinged on using a language to describe the requirements, so we came up with the “ato” language. In ato, you can break down circuits into modules, components and interfaces. You can nest and connect those blocks with each other. Here is an example with an RP2040 microcontroller:
import RP2040Kit from "rp2040/RP2040Kit.ato"
import LEDIndicatorBlue from "generics/leds.ato"
import LDOReg3V3 from "regulators/regulators.ato"
import USBCConn from "usb-connectors/usb-connectors.ato"
module Blinky:
micro_controller = new RP2040Kit
led_indicator = new LEDIndicatorBlue
voltage_regulator = new LDOReg3V3
usb_c_connector = new USBCConn
usb_c_connector.power ~ voltage_regulator.power_in
voltage_regulator.power_out ~ micro_controller.power
micro_controller.gpio13 ~ led_indicator.input
micro_controller.power.gnd ~ led_indicator.gnd
led_indicator.resistor.value = 100ohm +/- 10%
At the moment, atopile is intended to design all types of printed circuit boards (PCB) with low to medium complexity. The circuit complexity that the compiler can handle will steadily increase until it becomes suited for production usage. We often get asked if the compiler is meant for chip design rather than PCBs, but that is not the case. The language is exclusive to PCBs. At least for now..!
A big part of why the software community is so prolific is thanks to open source and open core technology. The ability to share software packages with each other and efficiently chain tools together has made the software world an awesome place for developers. As hardware engineers, we would love our field to benefit from this as well. That’s why we’ve made atopile’s core open source (Apache 2.0). We plan to generate revenue by selling entreprise targeted features, similar to GitLab.
We would love to have your thoughts on the compiler! What’s your story in electronics? What would you want us to build?
299 comments
[ 3.5 ms ] story [ 256 ms ] threadHave you got any plans for defined interfaces/modularity so devices using SPI, I²C, etc. can be chained together without manually defining pin connections? Also, will there be support for importing schematics from other formats?
Interfaces are just a collection of signals eg
you can connect two together like so: micro.i2c ~ sensor.i2cImporting schematics would be possible, but IMO not super valuable as all we could import would be the raw connectivity, a big benefit of our language is being able to add a layer of abstraction on that.
To be fair, idk how much elixir code is in the training set.
Just an anecdote.
In that vein, I'd imagine it would make lot of sense to build a lisp on top of that, macros and sexpr manipulation are very much the strong points of lisps.
The state of electronics tooling has long been extremely bad - 99% of people who put a regulator into their schematic will want an appropriate input and output capacitor as the datasheet demands. 99% of people who put a microcontroller will want a crystal and a programming port and a reset pin pull-up. It's only because of closed source tools stuck in the stone age that the state of the art is to copy out of a PDF.
And multiple people working on the same design and merging their changes? Forget about it!
It'll be very exciting if we can move towards a more modular world, where designs can be composed.
For us hobbyists there's no point in investing years learning something proper like Altium because we won't ever be shipping to production or doing stupidly complex multilayer boards. We need the Tinkercad for PCBs, not Fusion360. Something that can be crude and oversimplified, but quick to use and also simple enough that even middle schoolers can learn it.
hope it works for you!
I dunno. I've used others, and KiCad was no harder to start with than the others (Horizon, LibrePCB, Lepton/gEDA, some others I forgot).
I asked for recommendations a week ago on HN for EDA products, and tried them all.
You know which one I eventually settled on? The one with the most components (symbols + footprints).
Turns out, features are nice (rules checker, etc) but not having to f*&^ing create my own symbols for a mass-produced part, then design the footprint for the same part is a huge timesaver.[1]
For many of us non-professionals designing a board, the UI just isn't as big of an issue as having to create our own components.
[1] At any reasonable hourly rate, having to create a library of just 1 component costs more than whatever you think you'll save with a slicker UI.
On top of that semiconductor vendors don't want to hire people to draw symbols in every possible cad solution.
So you instead have them release symbols in some preferred tool, maybe they also outsource to third party services like UltraLibrarian. There problem with the third party services is they do the laziest conversions possible between format using scripting and often do a horrible job.
This doesn't really explain why creators of new CAD programs (Horizon and LibrePCB are new) invent new data formats.
We've seen time and time again, in every digital domain ever invented, that the most important thing is the dataset.
It doesn't really matter how nice the library manager is if what it manages has limited availability - and no, asking for a community to pitch in and help with the duplicated work is not a solution.
The solution is to pick the largest library and use its format.
We currently support components on JLC, but eventually plan to build out a pretty substantial library. We will also capture a good fraction of information that you would currently need to go to the datasheet for.
Anyway, my 2c worth:
1.
> In our tool, just give it a part number and it will find and download the footprint and create an ato file for the component.
I don't think this is scalable (although, for my use, probably sufficient). There are just too many parts that are in existence, and the rate of new part creation is probably higher per day than your staff and/or community can handle.
It's fixable if you have plugins for each EDA tool's format (KiCad, Eagle, etc).
2. I'm very surprised at the language used - it's very unlike what is normally used (s-expressions) in EDA. Lisp-like languages tend to be highly used in CAD applications, so it would clear a lot up if you were to explain what the advantages ato are over a minimal Lisp-like language.
3. The dependency list (in terms of knowledge required) is a dealbreaker for me[1]. I need to know how to manage Python environments, the ato language and YAML?
Since all of the constructs in all of those languages are a subset of (or can be represented by) s-expressions, perhaps it would have been best if you switched to s-expressions only. Then a) there's only one language to learn, b) that language is already syntax-highlighted and c) it's flexible enough for any future features you want to add in (rules definition, rules-checkers, etc).
From what I can see here and now, the ato language would have to see significant changes if it needs to be used for some serious stuff.
Sorry for the negativity, but I wish you all the luck nevertheless.
[1] I looked for a download link, couldn't find one, read a few of the installation instructions, then gave up.
Not personally a fan of the readability of lisp, but that is just a personal preference. Our assumption is that python is going to be the most familiar language to our users and following a python like syntax will make picking it up easy. Our language is definately still quite immature and we are still figuring out exactly what it should look like.
There is definitely a little bit of a learning curve at the moment, we do have some getting started videos that walk you through the whole process. If there is anything missing or confusing, please point it out! We do want to make it as approachable as possible. It will only get better from here, I promise!
On the downloading, currently we have the package on pypi, which does make it pretty easy to install from a command line, but I can appreciate that will be new to alot of people. In the future we might do an executable download version.
We have a getting started video here: https://www.youtube.com/watch?v=7aeZLlA_VYA
We are very active on discord also if you get stuck or have any questions/feedback, hope to see you there! https://discord.gg/PBq4pS4K3p
Not really. KiCad is open-source and a very capable EDA suite, for example.
The problem is that it's a really hard problem for which no one-size-fits-all solution exists. There's basically an infinite number of properties which are important when designing electronics, many of which will have to be nudged depending on your design. Capturing all that in a data format is virtually impossible, and any attempt to do so is likely to degrade into something unusual quite quickly once you get past the trivial stuff.
In my experience reading it out of a PDF is usually not that big of a deal, once you get used to it. For things like schematics symbols and footprints there are data interchange formats available - and there's a pretty decent chance these days they'll be openly available for the part you are using. But they always contain mistakes, and I find it way faster to just roll my own from the PDF than to copy it ready-made from a 3rd party and fix the errors.
Not really, IME.
Let's say I want a SMPS. Something basic, say 12-24v in 3.3v out at 1A. I can buy a module and solder it onto my PCB, or copy a reference design out of a PDF, or vendors like TI have tools like webbench to help me generate a custom design.
The vendor wants to hand me a proven design and have me buy their chips. I want to be handed a proven design and know my project's going to work right first time. But no, the likes of Altium have got to have their vendor lock-in by making copy-and-paste absolutely as difficult as possible.
There's no great skill or inventiveness in me drawing out the world's billionth SMPS design. I'm not "solving a hard problem" - it's drudgery.
> and there's a pretty decent chance these days they'll be openly available for the part you are using. But they always contain mistakes,
So you'd agree, then, that when a human copies from a PDF manually there's a substantial chance of them introducing errors?
Are you and I not equally vulnerable to making such mistakes? Frankly I find it absurdly wasteful that the industry has transistors in the same package but with different pinouts and the 'solution' to keeping this stuff in order is... senior engineers checking junior engineers' work against PDFs manually.
In terms of decoupling designs etc., the reason nobody has come up with a better solution is firstly that it doesn't actually take up enough time in the scheme of things to bother, and secondly that you often have to deviate. For variable regulators for example, the output capacitor (and inductor if it's not included in the device) are chosen based on output voltage, the switching frequency you choose, and sometimes other variables. You often want to deviate from the recommended circuit in the application notes for various reasons.
I'd think of a circuit board production as more like putting together a magazine than working on a software codebase, where you'd have a bunch of people working on overlapping parts of the code.
I mean even for a lot of boards we do (even quite complex ones) we'll just have one design engineer and one layout engineer, but for things where multiple people work on the schematic we just have people work on their own sheets and then somebody brings them together into the final design - kind of like where you might have an overall designer/editor that pulls a magazine together but individual people having put together individual articles. But it's pretty common that it would still be mostly laid out by a single engineer unless you're doing something extremely complex...
People have tried many times to build a universal router with physics awareness for decades. The issue is in the real world there are countless edge cases where the EE must make a decision on the layout.
For low speed digital design... routers have partially worked since the 90's, but for most other things the edge cases make it counter-productive to automate.
EEs are good people to have around, and some know how to build things reliably.
Have a wonderful day, and I really hope the project does well. =)
Our goal generally is to automate tasks that are boring/repetitive like multi-day reviews of big schematics to see if anything accidentally changed. Definitely building a lever for EEs, not a replacement.
Thanks!
We also noticed that most EEs we've worked with were a bit put off by the syntax and preferred something a bit more terse, but more intuitive and easier to read.
There perhaps an analog here in software - where we started with assembly (~ SPICE), moved up through things like C and now languages like Python and JavaScript are prolific and accessible.
The open source aspect was really important to us. We are hoping that ato modules can become a convenient language for the community to share modules with each other, in a similar fashion to python and pypi.
Having an open code base also makes it more convenient for our users to chain tools together. This is currently hard to achieve with the existing close source standards we are dealing with in hardware.
ato is also a markup language (like markdown or latex) more than an actual programming language. We think this makes it more readable and helps guide the user writing code that compiles.
I set up a CI pipeline for the hardware company I worked for. It automatically generated things like gerbers and board renders for each commit, and made them available as PNGs. I added a little tool which made it really easy to view the results side-by-side, and see both the front and the back. It definitely saved us from some really expensive mistakes a few times!
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...
I'm just starting with electronics, following the Make Electronics book with my kid. And this seems super useful to understand circuits better (at least for people who code), do you have the plan to make a series of lessons for beginners with the app? Like going from the simple battery-led to complex things? Feel free to email.
Really love that. My dad gave me a piece of wood with some basic components like LEDs, motors, resistors and light bulbs and a battery that I could connect those to and understand how they worked. Glad to see you are doing something similar :)
We do have a couple videos and certainly plan to make more: - Get started guide: https://youtu.be/7aeZLlA_VYA - ESP32 module: https://youtu.be/eMWRwZOajdQ - Logic gates kit: https://www.youtube.com/watch?v=hSeDv3QqRc0
We are also hoping for the package registry to become a place where you can get access to pre-designed modules to put together into a circuit: https://packages.atopile.io
Feel free to reach out per email or discord if you need help setting things up!
When I was thinking about it, a couple of further directions I had in mind were 1) ecosystem/library/sharing of modules, so something like the voltage divider example is not something you'd need to do (even once) for every project; if it really took off the pipedream would be that application notes examples were just provided as modules, so you could take whatever IC wnd just import the module if you were using it in a standard way; 2) if you did a similar thing for layout constraints, you could then have that as part of the same module, and when you compile the whole thing (in hand-wavey generalised theory if sufficiently constrained) you could generate the overall layout for a project with say a SMPS and also sensitive analogue circuitry in a way that makes sense without either of those modules having to know that the other is in use, just because they have rules like distance from transistor, bypass cap to IC could be fully constrained, so you always get exactly the same sensible-looking layout, etc.
Anyway, looks great, I look forward to trying it properly some time!
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 thumb rather than rely on simulation.
I was also blown away that the state of the art autorouter for traces seems to be from the early 2000's -- no recent AI magic going on here.
Where is my "autoplacer"? It seems like an AI trained on millions of schematic/pcb combos, even just gerber files via image ingestion, ought to be able to generate a pretty decent layout + routing given constraints.
Or perhaps I'm spoiled coming from software and web because it's so much further removed from physics. But it's still the case that there are a ton of modular components with "API's" that should have a templating language, so very much bravo to this project.
For the autolayout part, one thing we realized is that it’s very hard for a computer to do a good job at it when there is a lot of implicit requirements that are not baked into the schematics. We are hoping that by capturing those through code, auto layout can be improved.
On the design check, we aren’t doing a lot there for the moment but the comment above also applies: if you have clear requirements in the code, it becomes easier to test if the solution fits those requirement.
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.
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
Yup, almost 100% this. Most parts of most boards are pretty trivial, and the design decisions you make don't really matter all that much. Unless you're working at a company the size of Apple, it really doesn't make sense to spend several hours of engineering time to figure out if that $0.001 decoupling capacitor is really needed.
And in the end it's often a lot easier to just build the thing and test if it works. We see the same in programming: it's technically possible to mathematically prove that some programs are correct, but in practice you can get 99% of the way there for all programs in a fraction of the time by just writing a bunch of unit tests.
Simulation is definitely done, but it's limited to the really hard stuff like antenna design or high-speed signalling.
100% agreed about the ecosystem too. We've already created a perhaps-too-scrappy package manager, but it works! https://packages.atopile.io/ We're pretty convinced that the awesomeness of the software ecosystem is a function of its openness and open-source and atopile largely came from working out how we could seed a similar shift in the hardware world. I can't wait for the day I can `ato install` SMPS, filters, radios and servo-drives with the confidence they'll just work!
Import from public GitHub libraries could be fun.
Differential pairs.
Impedance controlled traces.
Going further, if I have one supplier's stack up with controlled impedance lines, and I need to switch to a different supplier's stack up, what netclasses would change?
On the language side there are additional features we would like to work on like traits and types (types would include diff pairs and impedance).
[1] https://doc.akka.io/docs/akka/current/stream/stream-graphs.h...
The equivalent of atopile signal would be port with Akka I think. A combination of ports gives us a shape. A source shape is just one OUT port. A flow shape is one IN and one OUT port, etc.
I'm very new to electronics so I don't know if it makes sense, but connecting all these ports with directional arrows was really helpful to understand the data flow.
I wonder if with directional arrows, instead of writing "out ~ switch.in; switch.out ~ power.gnd", we could write "out ~> switch ~> power.gnd" instead?
But without distinction between in and out ports it may not be possible to check if connections are valid ones.
Anyway, this project really makes me want to learn electronics! Congrats!
I understand that auto-routing is not a solved problem by any means, but there should be more efficient tools to make it easier. I shudder to imagine laying out some big LED matrix without more advanced tooling.
The only issues I've had is how it outputs circular things for cutting - it does a series of polygons (configurable number), rather than an arc/circular - places like send-cut-send won't accept it, claiming it causes issues with their machines.
Found a script[0] that does this for DXFs in a github issue[1].
[0]: https://github.com/nophead/Mendel90/blob/master/dxf.py [1]: https://github.com/openscad/openscad/issues/4605
The last thing I want to worry about is having malware in an M5 bolt.
Is this meant sarcastically?
No I don't mean it sarcastically, why do you ask? Do you not see Lady Ada as a shining light of the industry?
Lady Ada is one of the industry's greatest hardware designers and I would value her opinion on this.
If you don't know who she is, her name is Limor Fried and she founded AdaFruit.
I don't have current stats but from 2016: Revenue US$45 million (2016)[1] Number of employees 105
Front page of Make Magazine:
https://blog.adafruit.com/2017/05/08/limor-ladyada-fried-on-...
Front page of Wired:
https://www.wired.com/2011/03/wired-magazines-cover-features...
Front page of Smore magazine:
https://www.adafruit.com/product/3920
Front page of Hackspace:
https://www.flickr.com/photos/adafruit/40061387915
I'm not interested buddy, you can take your sneering elsewhere until you show me the multi million dollar company you have created, the hundreds of commercial quality boards you have designed and sold for real money, the driver software you wrote to make them usable and the industry accolades you have received - on merit.
Calling her "greatest" seems odd, for implementing breakout boards with datasheet circuits.
"Lady Ada" and Adafruit certainly are good at price gouging. They often charge exorbitant prices for the same stuff we can get elsewhere at a fraction of the cost. No, providing datasheets and some instruction isn't enough, there's a thousand other sites with better instructions in most if not all cases.
The only places that sell same or similar items for drastically less than Adafruit are places like Aliexpress (or the same foreign sellers selling on Ebay), and there are many reasons why Adafruit is more expensive than those places...
Some of the stuff Adafruit sell is likely sourced from Aliexpress (or perhaps from Alibaba if they're buying in large enough quantity) and is indeed priced higher at Adafruit, but that's because if they price it the same or lower they make no money. So we know for those items, they must mark them up. But how much they need to be marked up is kind of complicated. Buying lots of things in order to resell them is more complicated than buying just one or two things for yourself, especially when the seller is on the other side of the world. Simply put: there's a lot more overhead when buying for resale that you don't have to worry about when buying low quantities for yourself. One big difference is that they need _reliable_ suppliers with large quantities consistently available, and those are rarely the same sellers selling things for pennies. (I could go into more differences, because there are many, but this reply is already getting pretty long. Ask me if you want to know more, or google for info about how to open and run a retail business.)
Also, bear in mind that some of that stuff that you can get elsewhere at a fraction of the cost than Adafruit are actually Adafruit's own designs being directly cloned, like a lot of their breakout boards. In those cases, you really can't blame Adafruit, since the reason those items are cheaper elsewhere is because someone's specifically trying to undercut them (often at the expense of overall quality and sometimes even at the expensive of authentic correctly-working parts).
They charge ridiculous prices for LED strips, the same strips you can get anywhere.
Here's one example:
https://www.adafruit.com/product/1461
Black LED strip. 60 LEDs/meter.
1 Meter = $24.95
4 Meters = $99.80
And they advertise 4 meters as a "full reel" when everywhere else 5 meters is considered a full reel. What jerks!
Same exact thing, except 5 Meters, $22.99:
https://www.amazon.com/LOAMLIN-WS2812B-Individually-Addressa...
So, let's calculate this price gouge.
Adafruit price per meter at 4 meters/roll = $24.95
LOAMLIN price per meter at 5 meters/roll = $4.60
Adafruit is charging 5.42 times the price.
And if I want to wait a few days more to get it delivered, Aliexpress has the same thing for $11.26 per 5 meter roll!
https://www.aliexpress.us/item/2255800689099192.html
Every LED Adafruit sells comes from China, they do not make their own LEDs. They just mark up the price to a ridiculous extent and they prey on well meaning but clueless electronics hobbyists. There are many other examples, but I think I've spent enough time on this topic.
>I'm fairly confident that if you looked and found a bulk wholesaler for this item that offers terms, the per unit cost is going to be closer to the Adafruit price than to the Aliexpress price you quoted.
Confidently incorrect.
We're talking about Adafruit gouging hobbyists. Not wholesale bulk purchasing.
For the average person buying a few or a dozen rolls of LEDs, Adafruit is the worst possible choice of vendor. Paying ridiculous prices for the same exact product is insanity.
Your tome trying to justify it is just tl;dr; nonsense. I'm sorry but it just is.
>But that still doesn't mean that Adafruit is price gouging.
Yes, they definitely are price gouging, and your mental gymnastics don't change that at all.
We're really done here, you obviously have an agenda and no amount of obvious proof will convince you of anything that might shatter your nonsensical world view. I'm not interested in you moving goalposts anywhere you want to win pointless internet arguments. Have a nice night.
The only explanation I can think of for your strong opposition to what I'm explaining is that I think you might be working with a different definition of "price gouging" than is commonly accepted. Price gouging is when a seller raises prices unnecessarily due to an increase in demand or a decrease in supply (like when some places raised the price of toilet paper early during the covid pandemic). I've repeatedly tried explaining why that is not what's happening in Adafruit's case -- Adafruit's prices are a result of the fact that they're a very different business than no-name Chinese sellers on Aliexpress and the costs that they're getting goods for can be higher due to their needs (this is why I was talking about the wholesalers that Adafruit deals with). It's perfectly rational and not "mental gymnastics" -- this is common business. This is also why most stores that are not national chains have higher prices than national chains (and Amazon, for that matter, though that's messier since they also have third party sellers). Again, this isn't price gouging -- they just can't get the goods they sell for as cheap prices as national chains.
We're not talking a few cents or dollars more. We're talking about more than 5x more the price of what they actually should cost.
You can call it whatever you want, but Adafruit prices are ridiculous. I gave one example of many. Go ahead and throw your money away if you really want to, I don't care.
You absolutely are doing mental gymnastics to try to justify 5x price difference, when they get the LEDs from China. It's the same stuff.
Nothing you can do can explain this, so just give up. I'm done with this, you're wasting my time with your tl;dr;s
That is unless all you do is high speed FPGA work and that's all you consider to be "industry".
Are you fully open source today? How has the community aspect been going?
We did use skidl for a little while as we were figuring things out (see a project here: https://gitlab.atopile.io/pew-pew-and-friends/sizzle-sack). But we later ended up moving away from it towards ato for mainly two reasons:
- Baking a description of a circuit into python describes how to obtain the circuit, but doesn't really describe what the circuit is. Skidl projects quickly become hard to read. The user is also not guided towards writing code that compiles since you need to deal with all the complexity of Python as well as the circuit itself. - Contributing to the project and adding features was non trivial
I'm also curious if you're able to use an autorouter to minimize board layers. Seems like it should be pretty straightforward to apply some graph theory to this and state the minimal number of layers for a given board, but this also might be NP-hard? I haven't kept up with the theory here.
I think I see the entry point for auto routing to be taking advantage of the fact that layers have become pretty cheap (atleast for prototyping) and engineering time is the expensive bit. If the tool can help me layout a board in half the time, particularly for test hardware or the likes, that would be huge. Eventually I think we will get to a place where computers will do a better job of layout than most people, but thats a ways off.
I tooled around with a similar idea sometime back. There are clear advantages of code over graphical-schematics when it comes to automatic generation of component values / re-use of elements / speed of development / automatic SPICE testing / etc.
The primary issue I ran into was that: electronic circuits are inherently graph-structured and the traditional circuit schematic is well suited, optimal even, for displaying this kind of information. Trying to understand an analog circuit that is described as code seems awkward.
I think a viewer would be nice ultimately. But we haven't exactly figured out how the solution might look like. ideally something that allows you to create datasheet-like snapshots of part of your design?
Side-by-side schematic symbol view / code view that are actively synced to one-another in real-time. Schematic view allows basic arranging of parts, editing interconnects, triggering jump-to-reference within the code view, adding probe points for SPICE, displaying SPICE output graphs. Code side does all the heavy lifting like creating new parts, scripted behaviors, editing component values, all the cool shit that would be a nightmare to sort into a GUI.
Much easier said than done, of course.
For the spice graphs, having a jupyter notebook-like interface would be great to document why your design looks the way it does.
If you have specific ideas or drawings of how this might look like, please send them over in our discord server :)
This would make it easy to implement a fancy optimizer. Each component tends to have certain acceptable thresholds for their dependencies like input voltages, current limits, external resistor/capacitor/inductor values/ratings, etc.
Then, each component could have different implementations. You can have different manufacturers produce the exact same inductor/capacitor/resistor in different packages. You can link it up to your existing BOM or hook into vendor APIs to get pricing.
Imagine optimizing for cost, removing redundancy, simplifying footprints, and prioritizing in-stock inventory over new order components.
This could be a huge deal, looking forward to its progress
Here's some of the basics Tim was playing with earlier: https://github.com/atopile/atopile/blob/d25686952534e0f96582...
I'm doing a lot of home automation work, and I absolutely hate that I need to use breadboards, hunt for pre-assembled components, or to spend days designing a PCB for simple things like relay modules with customized IO.
E.g. I have ratgdo for my garage door opener, but its power supply is an ugly buck convertor taped to the box. I'd love to just re-make the ratgdo board, but with a built-in 12V-to-3V buck convertor.
I tried that, but PCB manufacturing with custom component placing requires just too much work.
Is there a way to donate to the project? I'd love to support it.
Have a look at packages.atopile.io. We have a package with power supplies that you can just add to your board with
https://gitlab.atopile.io/packages/regulatorsBest way to support us right now is to try the project and give feedback on where you'd like to see this going. The project is open source so feel free to raise issues or contribute as well :)
Eventually it would be amazing to import (for example) a buck converter circuit with a wide voltage input, fixed output suitable for RF, and have it automatically check available components at JLCPCB and then lay it all out with, adhering to best practices (ground planes & capacitors right next to pins etc.) If the available components change, it can tweak the footprints and layout without having to start from scratch.
Good luck, I’ll be following closely!
However I do want to mention that I think it might be necessary to be able to "cross-compile" to visual schematic format, and back. Or perhaps there is an open schematic tool that can be extended?
The issue is that I think electrical schematics are significantly more familiar to EE types, contain more legible information. Instead of reinventing the wheel there, it'd be nice to see a system that can switch back and forth between text and visual schematic.
How are schematics described as files currently? Is there an open standard? Can it be converted to atopile format, and back?
What we discovered is that:
- making a visual viewer is a non trivial endeavor. It takes a lot of time but the value add is marginal for an average viewer. - people tend to spend a lot of time making the viewer look good instead of improving the circuit
We think that in the long run, a viewer could be awesome to inspect what is going on or get a general understanding of the circuit. But it’ll be difficult to justify the time spent on it early on in the project.
We also think that there might be better and more interesting ways to view your data, for example maybe you want to just see all the power paths through your circuit, or investigate how a signal travels from your input to your adc through filters, protection etc. Often on big designs these things might be strewn across multiple sheets and a bit hard to follow.
edit: just wanted to double down on this being very cool though. i dont mean to deflate this project and I'm about to design a pcb for a personal project - I might give this a go for fun. the promise is there and asthe project and feature set grows i can see it being the way forward.
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.
It wasn't so much "pc board by code" so much, but it was more a "pc board by CLI" approach.
And by that what my goal was, was to offer primitives and utility functions that would build the board up over time, but it was to be done incrementally in a Lisp REPL.
My use case scenario, was ancient AutoCAD.
Back in the day, while you could hook up a tablet or other pointing device (I'm talking pre-mouse here) to make AutoCAD drawings, a lot of it was done simply through typing in commands, in AutoLISP.
(lineto 100 100) kind of thing. And the drawing would appear on the screen over time, you'd save the data model, and manipulated with the REPL. If you wanted 10 lines:
(HN does not have a paren matching editor, apologies...)Where it broke down for me was coming up with a graphic rendition using CL.
If emacs had anything reasonable regarding graphic support (its SVG support is Not Good), I'd have done it there.
Rethinking it, it just occurred to me I could have probably gone a good way using ABCL in a Java GUI shell.
But the key point is that I think using a REPL for building up something like a circuit can actually work, actually be efficient for users, especially if it's extensible (i.e. (defun grid ...) ). Especially a hybrid (like clicking on a line pastes an identifier into the REPL).
My experiences with KiCAD drove me down that mad hole.