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$...
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.
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.
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.
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]
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.
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.
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.
Sorry, your nit might be wrong :) As elcritch covered the GRiSP case I'll just try to add some useful context.
Nerves stacks the BEAM on top of a small Buildroot Linux setup. The general rule I hear from the Nerves team is "if it runs Linux, it can run Nerves" which is mostly true.
I was considering whether Nerves could run on something like the ZSA Moonlander keyboard and then we run into a limitation of the BEAM apparently. Frank Hunleth of Nerves said the BEAM requires a device with an MMU. This is above my paygrade so I'll take his word for it ;)
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?
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?
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
I am a casual observer at best, but Nerves (more importantly, the BEAM) doesn't scale down to true embedded hardware. This looks like an attempt to build a new VM for more resource-constrained environments.
If you look at the supported targets, they're Raspberry Pi (or similar) computers, not microcontrollers.
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.
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.
I'm more interested in 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.
28 comments
[ 4.4 ms ] story [ 37.1 ms ] threadBut 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$...
The ESP32 is much better than most 16bit home computers, it just misses a companion blitter and sound chip.
- 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.
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.
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
[2] https://github.com/picolibc/picolibc
The Rust project is a step in the right direction.
Might be of use to those of you interested in this.
Nerves stacks the BEAM on top of a small Buildroot Linux setup. The general rule I hear from the Nerves team is "if it runs Linux, it can run Nerves" which is mostly true.
I was considering whether Nerves could run on something like the ZSA Moonlander keyboard and then we run into a limitation of the BEAM apparently. Frank Hunleth of Nerves said the BEAM requires a device with an MMU. This is above my paygrade so I'll take his word for it ;)
Frank do a good overview of "known" projects in the second part of this talk https://youtu.be/bkLABs04k5o?t=1173
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
If you look at the supported targets, they're Raspberry Pi (or similar) computers, not microcontrollers.
https://hexdocs.pm/nerves/targets.html#supported-targets-and...
If AtomVM supports hotloading, that's always nice.
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
[2] https://grisp.org/specs/
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.