I basically dont write ato code when designing modules any more, claude code + rules file + a few decent examples and an MCP for basic functions like building, finding parts and inspecting library components is able to do a pretty great job. As an example, claude one-shotted this MPU6050 design: https://github.com/atopile/packages/blob/multi/adafruit_heis...
Currently working on a pipeline to generate a whole bunch of these automatically, stick them on some big test boards and make sure they actually work. We will be selling razor blades, and will have the test data to show they work.
I think there is actually some really neat stuff to be built here. I think layout engineers would love to be able to write down their 'style guide' that is basically a set of parameters modifying the footprint. We would have a 'common' representation, basically a definition of the package itself that would be transformed to whatever you might like for the pad/silk shapes. Something very similar to having a linter in code that would enforce company best practices.
We already provide the 'plug and play' version which looks quite alot like LCSC data and is certainly good enough for playing around with. Id really like to put some effort into standardizing this in the mid-term, seems pretty crazy to me that there are way more footprints designs out there than actual packages.
Our vision is not schematic capture, but intent capture. Once you can capture intent it can trickle down to schematics, layout, BOM selection etc. The language is pretty simple at the moment and building out from the 'minimum useful product' which is basically replacing the schematic.
The schematic is not most of the work, but it is the place that most of the work is relying on as a source of truth. Everything from firmware header files, end of line testing, reliability tests to service manuals. Today as an engineer you end up in the middle of that. Once you have a complete description, much of the boiler plate work can be automated.
We have done quite alot on the components and routing section of the work as well, we can generate most components for you automatically without leaving the IDE and have a growing list of fully auto-selected components. Instead of going to digkey to find a 10kohm 1% 0402, you can just give those specs to our tool and it will automatically pick the most suitable one for you, considering things like price and stock (plus eventually any other filtering you might care about, including custom libraries). For layout we currently just to layout reuse blocks, which is actually a crazy time saver for how simple it is. https://packages.atopile.io/ currently has ~10s of parts, but we are growing it over the next few weeks to ~thousands, so most parts you want to use will have a reference design + layout you can install and use in your project, just like you would NPM/pypi.
We think both are pretty important. For most people, the ato language should be sufficiently powerful, for module designers we have a python interface that allows for more complex designs.
For example the INA228 from TI has a funky addressing scheme that is not possible to describe in ato, so we create a hybrid module:
Fair enough! We definitely need a better landing page, we are just coming out of a long period of building, will all be getting some much needed polish soon!
For sure, the way I see the component library is ability to capture progress. In the current paradigm how many times have schematics, symbols and footprints been drawn up for common ICs/circuits? I would expect 100s or in some cases many thousands of times. Our hope is by providing an open source and shareable format we can reduce this. If people really hate code and want to write a tool to convert to altium/kicad/cadence format, go for it! At the same time, I think the way we share component data is pretty dated, PDF datasheets do not adequately capture component information in a way that can be apples to apples compared in any automated fashion, best we have is something like a digikey search. In the future I would like to be able to have much more sophisticated requirements that automated search tools can use to help me find the best components for my use.
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.
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.
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.
Indeed! We do support quite a few parameters for component selection today, but definitely want to add a lot more. I think this opens up some exciting possibilities, for example not needing to explicitly call out a part number for generic components in your source code, retaining information about what the requirements of that part are. Of course in production you would want a lock file to make sure things are not changing arbitrarily, but I personally would have loved something like that while I was dealing with chip shortages a few years back.
I am curious to hear that you dont see any value in bringing software workflow to hardware. I found in previous jobs we spent a huge fraction of our time dealing with things like release, version management and reviews. Thanks for your thoughts!
For sure, our goal is to solve the toughest problems in electrical engineering, we are starting with the low hanging fruit. Confident reuse of designs that can be verified and validated before a chip is placed sounds pretty exciting to me!
BOM generation and abstraction have definitely not made it to PCBA design yet, so that is where we are starting.
For sure, we have been pretty focused on the low level part of the language, I think it will be interesting to see how our language evolves as we are able to abstract away more of the low level connectivity and configuration. I think eventually we will end up building something like a python library on top of ato to get the best of both worlds.
Indeed, we think the community aspect of this is super important. Being able to reuse high quality work confidently is very nice. Our export is pretty cool already! We build outputs in CI on a server, ready to drag and drop directly into JLC, including BOM and PNP files.
Being able to use git was our fundamental motivator, we all previously worked a big companies and found it maddening that we couldnt work in parallel on projects without breaking everything.
On parts specs, for sure, we currently capture all the data you would see on JLCs website. We do have dielectric and voltage ratings for caps. Eventually we plan to scrape a bunch of datasheets to build out a high quality dataset, I am very excited about this!
Thanks! We definitely want to get involved on the education side. Currently we are super focused on building out the tool and growing a community around it. We are looking for people to use our tool and give feedback on what works and what sucks. Would be excited to chat about what you would want to see from an education standpoint!
We had a look at a few options before doing our own. A few thoughts;
Building a DSL allows us to keep it really simple to start, we tried using SKIDL ( a very cool python project) and found it was pretty easy to get your self in a weird spot, the language would let users do things like create a component and not hold a reference to it.
Units and tolerances are core to our language, the physical world is 'fuzzy' and having a good way to deal with those we think is pretty important.
We are also trying to make it as readable and friendly as possible, our expectation is our users will likely have some experience with python and perhaps a little C back in school, so making it clear and approachable is front of mind.
Very open to critiques on our choices! We still very much in development.
They do have this, its called EasyEDA. In my experience its not as good as kicad and definitely not as good as the 'professional' tools like cadence and altium. Our tool does basically do that though! We have a big library of kicad components that can be used in your designs as well as an import just about any JLC component just using its JLCPN. We love their service, would love to see that model proliferated to other companies also, so hard to beat having parts available and in stock.
For fun I did have a play with GPTs doing a little fine tuning on some ato code. Definitely not my domain, but pretty amazing how quickly it kinndaa worked. Our focus at the moment is building out the layer that designers (human or otherwise) can operate on. I do think that we need some pretty solid testing infrastructure for us to get to a place where we would ship 'black box' pcbs. Maybe one day.
For sure, there will always be some 'user' type requirements that we need to build a way to input, for starters it will be something like a lock file with component positions of things you need in a particular spot. I see alot of value in automating things you just dont care about, particularly if 'sensible' rules can be applied. For example if the tool could automatically determine trace widths, not just at a net level, but for each link based on how hot you were happy for it to get and what loads it would see.