napowderly
Joined 3 years ago
Karma
95
Submissions
56
Member since
Oct 3
Recent submissions
Comment · 1 month ago
I think the amount of reuse is a big difference. IC tools build on characterized cells with a lot of the rules already encoded. With PCBs, even when you're reusing a reference circuit, you're often manually carrying over the constraints and figuring out which layout decisions mattered. A lot of the engineering gets repeated rather than traveling with the design. That's something we're trying to improve with atopile.
Comment · 1 year ago
Comment · 1 year ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
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.
Comment · 1 year ago
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:
atopile for the main structure: https://github.com/atopile/packages/blob/multi/adafruit_heis...
compose in an 'addressor' python module: https://github.com/atopile/packages/blob/multi/adafruit_heis...
Comment · 1 year ago
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!
Here is one of our more recent demo projects you can check out that shows how a larger project is structured: https://github.com/atopile/nonos/blob/main/elec/src/nonos.at...
And an example of modeling a component: https://github.com/atopile/packages/tree/main/packages/archi...
Comment · 2 years ago
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.
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
Comment · 2 years ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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!