Electronics > PCB/EDA/CAD

A blinky PCB made from code

(1/3) > >>

Timot:
Hey,

We've been working on a compiler for electronics and wanted to build the equivalent of "hello world!" in the electronics world. So we built a "blinky" circuit! It's basically a blinking LED circuit but with a few added bits to make it more fun: 20 addressable LEDs, an IMU, a light sensor and a li-ion charger.

The project lives here with more details about the compiler, the description language and the circuit: https://gitlab.atopile.io/community-projects/blinky

Curious to hear what you think of it!

dobsonr741:
Love the product idea - the auto break light.
Ato, and how it’s presented posed a few questions/concerns:
Dropping the schematics from electronics design is brave, but not for everyone.
The layout still needs to be done in KiCad, right?
Why not build the firmware with CI too?
Why promoting JLCPCB?

Timot:
The bike light firmware could use some work on the sensor filtration side. It tends to turn RED with shocks sometimes.

On the compiler side:
Yes, the move towards code rather than schematics is a spicy one. We did experiment with getting modularity, reusability and testing using schematics but we did not achieve it. With code, it was trivial to do so.
Yep, for the layout it's as usual. From kicad, just do file>import>netlist and the components and nets will show up.
We definitely could build the firmware in CI. Sadly we haven't got around to implementing it. Platform.io made the local firmware build pretty easy.
We aren't necessarily trying to promote a specific vendor. JLC's automated assembly was quite straight forward to work with, which is why we used it. Actually I'd be great to have contributions to the compiler to support other vendors.

tychob:
What is the benefit of a completely new language, vs embedding in python like https://github.com/devbisme/skidl? At first glance it looks like it is hard to add additional testing and verification capabilities without extending the compilier in atopile.

Timot:
Good question! We actually tried Skidl on a few designs. Here are some of the issues we discovered:
- The code isn't as readable as it could be if it was specifically developed for electronics.
- Since python is a full blown programing language, there is no way to guide the user to write "correct" code. Errors might be related to misuse of python as much as they might be due to an electrical connection error. This is a big problem from a usability and stability perspective.
- The infrastructure developed around python for sharing modules, importing files and version control has not been developed around electronics. Skidl has to inherit from software development workflows (which contain the right ideas but are not implemented for hardware specifically)
- We found it complex to add features to skidl, mostly due to the fact that it was an alternate use of python that could not extend beyond what python was already capable of.

In our case, we tailored the compiler and the language syntax to describe electronic system specifically. You are right that additional features will have to be implemented in the compiler itself. But we have already seen that we can move faster by having our own architecture. And we think users will enjoy the experience more since it was meant for that problem specifically.

Skidl is awesome though. We had fun using it and learned a lot from it!

Navigation

[0] Message Index

[#] Next page