Skip to content

About us

  • in About us
  • 2 min read

Why on earth did you create a new language? 🫣

It's a good question! Making people learn something new is a huge barrier to entry, ignores the wealth of community support from existing languages and can be a bit of a pain to maintain.

This iteration of the project actually came after first working with and then modifying an awesome project called SKiDL (https://github.com/devbisme/skidl). SKiDL takes the approach of using Python. 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.

We are 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. Ideally some parts of code should "look" like the schematic, eg. power.vcc ~> resistor ~> led ~> power.gnd.

Units and tolerances are core to our language, the physical world is 'fuzzy' and having a good way to deal with those is pretty important. There's a few operators and first-class language features we wanted as well, (like units and tolerances eg. 3.3V +/- 100mV) that just aren't the same when embedded in a string, or class init method.

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.

Worth noting; we're probably going to try make our language more like Python, than less over the coming little while.

Happy coding! 🚀

-- Matt

  • in About us
  • 2 min read

Make hardware flow

My dad taught me the technical details of everything for as long as I can remember. For my 7th Christmas, I got a lawn-mower - to tear the engine off and turn into a go-kart. I was absolutely stoked.

As Narayan and I grew up, we spent every weekend building things. We were always scheming about the next project, and we were always building something. We built a CNC machine, a liquid-fueled rocket motor, and a drone. We were always trying to make things better, faster, and more efficient. We were always trying to make things work better.

More than any of the individual projects, the thing that I always got most stoked about was new tools. We converted a milling machine to CNC an axis at a time by first 3D printing and then machining each of the axes brackets. We had to take a second pass at the first two axes because the 3D printed parts were sloppy enough that the machined brackets they created still had too much play for comfort. Man, that was a great project. And the endeavour landed us more offers for contract work (as ~17 year-olds) than we could handle.

One specific part of that project I wanted, and wanted for years, were low-cost tightly integrated servo drives. I wanted to make a PCB with 4 servo controllers on it that meant I would only need to run cables out to the motors and I could control the whole system form a single PCB - similar to 3D printer controllers. We're finally getting close! https://github.com/atopile/spin-servo-drive

My subsequent decade through university and industry made me consciously realise why people kept trying to pay us - it's far too hard and slow to make hardware fast enough to stay in a flow state and learn fast enough that failing is acceptable.

atopile will make high-quality hardware engineering flow the same way great software development does - and make engineers everywhere feel like how our scrappy younger selves did.

  • in About us
  • 3 min read

From Weekend Projects to Reinventing Hardware Design

Early Days: Can we build a predator drone?

Matt and I met at camp when we were thirteen and quickly became mates. We chatted the whole twelve hour bus ride home, scheming about the enormous drone we were going to build, looking back at it, we were a bit ambitious.

The next decade of weekend weekends Matt and I spent together stand out. They weren't filled with typical childhood pastimes; instead, we immersed ourselves in building and creating. Our projects were modest – from simple drones to CNC machines. I'll never forget our attempt at a liquid-fueled rocket motor. Igniting it was a disaster, but everything else from the servo-controlled throttling to the large blast shield worked quite the treat - not bad, for about a week's worth of evenings after work!

Stepping into the Professional World

Our first proper tech jobs were at Tesla and Lilium. We were eager to translate our weekend tinkering to the real world. At these companies, we learned a lot about manufacturing and bringing products to market. The technology and talent were inspiring, but we noticed the pace of innovation was slower and more traditional than we expected.

Facing Industry Realities

Eventually, we both ended up at Tesla together, during which time we met Tim. We quickly found common ground in our experiences. Even though we were part of some exciting projects, the reality of day-to-day work often meant dealing with a lot of repetition and slow-moving processes. The job started to feel less about innovation and more about navigating through routine procedures. It wasn't the dynamic environment we had dreamed of, it was becoming just a job.

A Shift in Perspective: The Seed of an Idea

Continuing the trend of the CNC machines we built growing up - our personal projects often revolved around making things to make things. It was clear there must be a better way to describe hardware. Mulling this led to pivotal realization: What if we could streamline hardware design using language-based descriptions? In my day job, our team was managing 10+ designs each disconnected from the other, meaning it could take us years to roll out improvements across all of them. The idea of simply making a PR for each to update that particular module sounded too good to be true.

Our Vision: A Humble Hope for Change

We’re not claiming to have all the answers or to revolutionize the industry overnight, but we do have a vision: a future where tools keep engineers in their flow state - whether working on teams small or large, no matter how complex the project. We believe this will make the design process significantly faster and less costly, bringing us closer to the agility and joy of those weekend projects from our youth.

An Invitation to Join Our Journey

This journey is just beginning, and there’s a long road ahead. We’re sharing our story not just to talk about our idea, but to invite collaboration, feedback, and shared learning. Together, we can explore ways to bring a new level of dynamism and creativity to hardware design. We’re excited about the future and we hope you’ll join us in this endeavor.

Narayan