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.
I think relying on "we have a big set of components" is never going to work though. There are literally millions of components, often with unique footprints. You'll never cover even them all or even close to it. It needs to be easy to make your own.
Anyway good luck. PCB EDA could definitely do with some modernisation.
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!
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.
I wanted to give your tool a good look before I responded, hence why I am responding so late.
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.
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.
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!
The value is mostly in the software workflow, not in the software tooling.
Store your KiCad files in Git. Make a script which automatically adds a revision tag to the PCB. Create a CI pipeline for Gerber generation. Export PNGs so you can do visual diffs.
If you're collaborating on some project which consists of artwork made in Photoshop you aren't looking for a text-based drawing program either - you are looking for a better way to do diffs.
Here's something that has been true for decades: Storage is cheap and always getting cheaper.
When you are dealing with complex multidisciplinary designs (a full machine), the concept or a release takes-on a very different meaning.
Scenario: You update a single circuit board, or the code that runs on a single microprocessor.
The release descriptor for the product, the machine, must include every single element that goes into making that machine. If all you do is commit the software update to Git, you very well run a chance to create a very serious problem for manufacturing, qualification, testing and post-sales support.
It has been my experience that, because storage is cheap, a release due to any change is a full annotated copy of all design files for the entire design; electrical, firmware, software, mechanical, testing, manufacturing, etc. In some cases we've had to save entire virtual machines with working code because workstation and system software can mutate and things break. We recently had a case where a Windows 10 automatic update (don't get me started) broke code that used to work in a last month's Windows version.
If we accept that storage is cheap, then the concept of releases at the product level, are simple copies along with a set of relevant "readme" files describing release details. You can come back to this three years later and all is well.
In the era of little Arduino boards it is sometimes easier that, more often than not, electronics don't exist just for the sake of electronics but rather as part of a much larger, and often far more complex, multidisciplinary product. In that context, schematic entry is an insignificant burden. The same is true of hyperventilating about what code editor to use. Some of these things are truly rounding errors in the product life cycle.
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.
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.