A blinky PCB made from code

[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!

[tychob]

Do you have any plans for how you plan to encode requirements for nets? For example, different families of logic have different high low voltages, can I encode that this chip emits at least 4.5v for high voltage, whilst this one can't handle more than 3.3v on its input. These requirements are often dependent, for example, must not be higher than Vcc  (where a chip may have multiple Vcc rails).

Also, what about parameterized modules based on use? For example, I would love to be able to just declare a Sallen–Key filter, based on f0 and Q, and a) have the module work out the values for me, and b) have some validation that the resistor and capacitor values are appropriate.

[mawildoer]

Some plans, but we're also expecting there to be some exploration in that area!

Totally agree that there's a lot that's oriented around the node on the net, and that's our primary focus to begin with. The nets (or links as we express them in atopile) are nothing more than a conduit!
There seems to me to be two distinct categories of requirements/specs in that area; binary (is a type of signal) and continuous (voltage, current, signal speeds etc...).

Definitely excited about parametrised modules as well!! In the midst of working on allowing symbolic equations, toleranced variables and unit support.
Once those are in place, the plan is that we should be able to describe the topology of our circuits, the relationships between all the variables and the bounds of those variables, and then for the engine to solve and check the circuit. We too want to trivialise filters, regulators and the likes for most applications - obviously there are corner cases.

[cosmicray]

Are these available for order via JLCPCB ? I have a (new to me) recumbent that would benefit from having a rear light such as this.

TIA

[Kean]

Are these available for order via JLCPCB ? I have a (new to me) recumbent that would benefit from having a rear light such as this.

TIA

They mention this at https://gitlab.atopile.io/community-projects/blinky#manufacturing-the-circuit

The gerber files (& BOM?) are available for download under "Artifacts" - e.g. last successful build at https://gitlab.atopile.io/community-projects/blinky/-/jobs/6266/artifacts/browse/build/default/

[nctnico]

Some plans, but we're also expecting there to be some exploration in that area!

Totally agree that there's a lot that's oriented around the node on the net, and that's our primary focus to begin with. The nets (or links as we express them in atopile) are nothing more than a conduit!
There seems to me to be two distinct categories of requirements/specs in that area; binary (is a type of signal) and continuous (voltage, current, signal speeds etc...).

Definitely excited about parametrised modules as well!! In the midst of working on allowing symbolic equations, toleranced variables and unit support.
Once those are in place, the plan is that we should be able to describe the topology of our circuits, the relationships between all the variables and the bounds of those variables, and then for the engine to solve and check the circuit. We too want to trivialise filters, regulators and the likes for most applications - obviously there are corner cases.

But can you also create a schematic? At some point somebody will need to debug & test a circuit. For that a schematic is necessary as a netlist is just too far away from the actual implementation.

I see a lot of parallels to FPGA development where I use the schematic representation made from the VHDL code to check if everything is connected the way I expect it to. And bringing up VHDL: why not use VHDL? As VHDL (or more precisely: VHDL-AMS) is also suitable for describing analog circuitry. Building on an existing standard has a better prospect of being picked up compared to developing yet another programming language people have never heard of (and likely the language will change due to new insights which then breaks compatibility with existing code; see PHP and Python as prime examples).

[cosmicray]

Are these available for order via JLCPCB ? I have a (new to me) recumbent that would benefit from having a rear light such as this.

TIA

They mention this at https://gitlab.atopile.io/community-projects/blinky#manufacturing-the-circuit

The gerber files (& BOM?) are available for download under "Artifacts" - e.g. last successful build at https://gitlab.atopile.io/community-projects/blinky/-/jobs/6266/artifacts/browse/build/default/

The part that I could be missing somewhere is the programming. Even if JLCPCB can make & assemble the boards, there is still firmware to be loaded ? How does that happen.

[DavidAlfa]

Not a good idea, if it lights up by the IMU (When you're already braking), it's too late!
You want to warn about your braking intentions even if you're not actually braking, so it should turn on at the lightest touch of the brake so the people behind you can avoid riding over your body .
The design is nice, but not practical nor safe!

[Kean]

The part that I could be missing somewhere is the programming. Even if JLCPCB can make & assemble the boards, there is still firmware to be loaded ? How does that happen.

There is a firmware folder in the GitLab repo.
I imagine you’d need to load it yourself.  A good learning experience!

[Kean]

Not a good idea, if it lights up by the IMU (When you're already braking), it's too late!
You want to warn about your braking intentions even if you're not actually braking, so it should turn on at the lightest touch of the brake so the people behind you can avoid riding over your body .
The design is nice, but not practical nor safe!

I believe it is always lit up, but it changes colour when braking (decelerating).  So that adds some extra warning compared to a basic rear light.

I wouldn’t say it is unsafe, and not sure how practical it is. It is just intended as a demonstration project not a real product.