
AtomVM: Erlang on Microcontrollers - alex7o
https://github.com/bettio/AtomVM
======
mikepurvis
I'm interested in this as well, as a long-time Cortex/STM32 user. The barrier
for me historically in exploring alternative languages/toolchains (especially
in a work context) has always been uncertainty around tooling and peripheral
support. Questions like:

\- Am I going to get a network stack with this, and will it be as battle-
tested as lwIP? What about support for USB, CANopen, etc? Will the USB stack
look like it's working on a quick test but then have weird intermittent
failures in the field? (hello stdperiph)

\- Am I going to have a sane story for bootloading and in-system programming
with this platform?

\- What is debugging/logging going to look like with this platform? Will I be
able to use tools like Tracealyzer without doing a ton of integration work
myself? Is something that looks like GDB/OpenOCD with a standard JTAG dongle
going to more or less just work?

\- Quite apart from barriers in learning the new language itself, will it be a
pain to get the tools set up for other developers on my team? Will people be
building stuff from source and/or will I have to do packaging work?

Admittedly, some of these don't have great answers in the gnuarm world either,
but to the extent that I've hacked around them already, it's a sunk cost.
Anyway, I say all this not to be a downer, but to open a discussion about
these kinds of issues and whether others have been impacted-by or have
overcome them.

~~~
R0b0t1
Having followed scores of these projects, the answer for all of them is likely
no unless you do the work yourself.

There is an interesting gap: the C code for the HAL/stdlib of a device is
typically machine generated from the VHDL and register descriptions. If you
could get at that machine description, or e.g. use clang to parse the headers,
you could make some good inroads into this.

As it is I typically avoid microcontrollers because of all the pointless
plumbing I am required to do.

~~~
snops
SVD is this machinine readable description, and is available for most ARM
micros, as it is needed for the peripheral register view in debuggers.

svd2rust [1] is an project that generates a (very low level) Rust API for a
specific micro from this file.

Generally the file generated from this is known as the header files (as it is
just C headers to access the registers directly) and the HAL is an abstraction
layer on top, and is actually written manually by the microcontroller designer
as it contains higher level functions (e.g. a function to calculate the clock
settings to get a specific UART baudrate).

The STDLib is often supplied by the compiler vendor instead, or is an open
source project like picolibc [2]

[1] [https://github.com/rust-embedded/svd2rust](https://github.com/rust-
embedded/svd2rust)

[2]
[https://github.com/picolibc/picolibc](https://github.com/picolibc/picolibc)

~~~
R0b0t1
If you look it seems like portions of the STM HALs are autogenerated in some
way, even if it's by stitching pieces of code together. If not there is a lot
that _could_ be automated, and my general complaint is there is a lot of
manual work that is unskilled and no fun to do to get an MCU target up and
running.

The Rust project is a step in the right direction.

------
oomkiller
This is a very cool project, running Erlang on an ESP32 is impressive. The
supervisor trees and other parts of OTP make the platform a good fit for
certain embedded projects. Nerves is a great tool as well but of course it's
much higher level, with a full Linux distro running under it on a Rasperry Pi
or Beaglebone Black, which are much much more power-hungry than an ESP32.

There is a middle ground developing in the GRiSP[1] project as well. It uses
the RTEMS RTOS to provide basic POSIX compatibility that allows the full BEAM
VM to operate on lower powered hardware[2]. Work on GRiSP 2 seems to be
progressing slowly, but it's a cool project and definitely worth a look if you
find projects like AtomVM interesting.

[1] [https://grisp.org](https://grisp.org)

[2] [https://grisp.org/specs/](https://grisp.org/specs/)

------
simongray
This ESP32 chip seems to be getting a lot of language support. We also
recently saw a Clojure implementation:
[https://blog.tindie.com/2020/07/clojurescript-on-
esp32-why-n...](https://blog.tindie.com/2020/07/clojurescript-on-esp32-why-
not/)

~~~
raxxorrax
Nice chip. It is so crazy what you get for the price of 2 cokes.

But I am not surprised it gets a lot of language support. 160Mhz for a µC...
My first PC I got was ancient when I got it and it had 166Mhz. Single core of
course. At least it had 4x the RAM. And all that now cost < 10$...

~~~
ampdepolymerase
For a BOM, 2 cokes is not exactly cheap once you scale it to tens and hundred
of thousands. Imagine a SaaS where you are charged for every single database
row, that is the reality of hardware unit economics.

~~~
pjmlp
As shown by Arduino and Raspberry PI success, not everyone wants to scale up
to tens and hundreds of thousands.

~~~
ampdepolymerase
Those aforementioned products are designed for prototyping, for production
Atmel chips are fairly competitive.

~~~
pjmlp
There are plenty of "production" projects done by maker community.

------
svrtknst
Microcontrollers aren't really my thing, so this might not be a perfect fit,
but: Elixir Nerves is an Elixir project/platform that targets embedded
systems.

Might be of use to those of you interested in this.

~~~
lawik
Just to note that Nerves is for devices that can run Linux. So it covers a
different case compared to AtomVM.

~~~
thomasfortes
Just nitpicking, but devices that run the BEAM, not Linux, don't know what is
the state of the project, but the GRiSP board runs erlang in the metal.

~~~
elcritch
GRiSP runs on an RTOS using POSIX compatability. So baremetal-ish? Still you
can apparently program RTOS tasks and control them from Erlang land. :-) Also
Nerves supports the GRiSP board itself not the RTOS; pretty sure Nerves runs
it using Linux IIRC.

------
rkangel
I'm more interested in Lumen
([https://github.com/lumen/lumen](https://github.com/lumen/lumen)). Lumen is a
compiler for the VM+Application rather than an embedded VM running bytecode
directly. It's targeted at WebAssembly but it's an LLVM backend so most
embedded targets should be possible.

Maybe my reasoning is faulty and I don't have data to back it up, but my
expectation is that it will have better performance (code size, run speed,
memory usage) than the Atom approach.

------
holidayacct
Can anyone explain what the benefit of Erlang is with respect to
microcontroller development?

~~~
toast0
I haven't used it in embedded (I didn't notice that ESP32 had a Erlang VM, so
I got ESP8266 for my experimental stuff, because it was cheaper), but I would
guess supervision is nice. Binary pattern matching is also very nice and
probably useful in an embedded context, although the readme says binaries are
poorly supported in AtomVM.

If AtomVM supports hotloading, that's always nice.

------
non-entity
I've always heard people mention Erlang being used in embdded applications but
I don't think I've ver seen or heard of an actual instance. Is this actually a
thing?

~~~
di4na
It is. Farmbot, System76, LeTote, some naval systems, etc etc.

Frank do a good overview of "known" projects in the second part of this talk
[https://youtu.be/bkLABs04k5o?t=1173](https://youtu.be/bkLABs04k5o?t=1173)

------
vaer-k
I'm becoming interested in microcontrollers but I know next to nothing about
them. Would anyone care to explain the fundamental difference between this
project and Nerves?

~~~
romanoderoma
This project aims to run Erlang on very low power/low memory system, we are
talking about MHz for CPUs and megabytes of memory ( even hundreds of
kilobytes)

These systems have no real OS to rely on and developers have to handle almost
everything manually

Nerves requires a system who can at least run Linux and the real BEAM, like a
Raspberry PI which is many times more powerful than an ESP32 board

------
bobowzki
Very nice to see work in this area. Erlang is a very interesting platform for
building robust systems.

