Welcome to the AtomVM Forum

Hello, and welcome to the AtomVM forum on Erlang Forums. We’d like to use this space to answer questions and hash out issues in AtomVM, a BEAM implementation targeted for tiny systems.

AtomVM is currently under active development an is soliciting volunteers to help get involved with development, testing, documentation, release management, and more. There are currently no commercial sponsors for AtomVM, so ownership is purely community-driven.

If you are interested in running Erlang and Elixir on small, cheap (like, $2) hardware, AtomVM might be the place for you. If so, welcome aboard!

11 Likes

That sounds very cool Fred!

Do you have any examples of that hardware? I’m wondering what could be achieved with a couple hundred of them working together on something :lol:

AtomVM implements from scratch a minimal Erlang VM that supports a subset of ErlangVM features and that is able to run unmodified BEAM binaries on really small systems like MCUs.

What is/isn’t included?

(That’s from GH btw).

What kind of things have you used it for already? Or what kind of things or areas do you see it being used?


I pinned this thread for you btw, so whenever anyone visits the section it should show at the top - I also made the first post a wiki, which means anyone at TL1 can edit it - so you can the rest of the team can edit it and keep it up to date etc (whenever anyone edits it you will receive a notification, so you can reverse changes if need be - however if you’d prefer it wasn’t a wiki just let me know).

1 Like

First time I saw about AtomVM was a ppt slideshow somewhere over the internet some months ago, I don’t remember what I was googling for it to show up like this in some random website, probably it was about some presentation that I never managed to found a video for.

Since then I’ve the repo starred on my Github, but I was not visiting the repo to see if there was any news.

If you’re looking for volunteers, I’m on.
However my C is very rusty (if it was ever good at all), and I’m not sure how I could help, but if there is something I can do, the team can count on me!

3 Likes

Do you have any examples of that hardware? I’m wondering what could be achieved with a couple hundred of them working together on something :lol:

Right now the primary target is the Espressif ESP32 and the ST Electronics STM32 microntrollers, though honestly the ESP32 has gotten a lot more attention, because it is cheap, readily available, has built-in WiFi and Bluetooth, and a pretty active user community. The VM also runs on MacOS/Linux/FreeBSD, for testing.

What is/isn’t included?

Here is a sneak peek at some of the documentation:

Currently, AtomVM implements a strict subset of the BEAM instruction set, as of Erlang/OTP R21. Previous versions of Erlang/OTP are not supported.

A high level overview of the supported language features include:

  • All the major Erlang types, including
    • integers (with size limits)
    • limited support for floats (not supported on all platforms)
    • tuples
    • lists
    • binaries
    • maps
  • support for many Erlang BIFs and guard expressions to support the above types
  • pattern matching (case statements, function clause heads, etc)
  • try ... catch ... finally constructs
  • anonymous functions
  • process spawn and spawn_link
  • send (!) and receive messages
  • bit syntax (with some restrictions)
  • reference counted binaries

In addition, several features are supported specifically for integration with micro-controllers, including:

  • Wifi networking (network)
  • UDP and TCP/IP support (inet, gen_tcp and gen_udp)
  • HTTP server
  • Peripheral and system support on micro-controllers, including
    • GPIO, including pins reads, writes, and interrupts
    • I2C interface
    • SPI interface
    • UART interface
    • LEDC (PWM)
    • non-volatile storage (NVS)
    • deep sleep

While the list of supported features is long and growing, the currently unsupported Erlang/OTP and BEAM features include (but are not limited to):

  • Arbitrary bingnums (integers > 64 bits)
  • SMP support
  • epmd and the disterl protocol
  • Hot swapping of code
  • Read-Eval-Print-Loop (REPL)
  • Numerous modules and functions from Erlang/OTP standard libraries (kernel, stdlib, sasl, etc)

As such, it is highly unlikely that an existing Erlang program targeted for Erlang/OTP will run unmodified on AtomVM. And indeed, even as AtomVM matures and additional features are added, it is more likely than not that Erlang applications will need to targeted specifically for the AtomVM platform. The intended target environment (small, cheap micro-controllers) differs enough from desktop or server-class systems in both scale and APIs that special care and attention is needed to target applications for such embedded environments.

That being said, many of the features of the BEAM are supported and provide a rich and compelling development environment for embedded devices, which Erlang and Elixir developers will find natural and productive.

I should also add that there are some downstream extensions that are not part of the AtomVM codebase, including support for:

  • MQTT client
  • ADC
  • (NEMA-based) GPS sensors
  • BME280 temp/hum/pressure sensors
  • DHT temp/hum sensors (via bit banging)
  • BH1750 Luminosity sensors
  • SSD1306 OLED displays
  • SX127X LoRa modems
  • ESP32Camera
  • WS2812 (Neopixels)

among other minor enhancements, some of which should make their way into the VM.

I look at AtomVM as being geared for the hacker/maker community, and maybe a way to bridge the maker community with the Erlang/Elixir communities. Getting Erlangers interested in hacking hardware and makers interested in Erlang and Elixir as a development platform would be a fantastic outcome!

4 Likes

If you’re looking for volunteers, I’m on.

Thanks! I think at this point we need a lot of help with release planning, including testing, documentation, continuous integration, and web presence. If you are still interested, let us know!

2 Likes

Thanks for the info Fred! I looked around and found some for a fiver :lol:

Is that the correct one?

Something I’ve wanted to have a go at making myself is a keypad or Bluetooth door entry system. I am thinking of building a gym in my workshop and want to give some of my friends entry to it (so they can use/gain access to it without disturbing me) and a keypad entry system would be great and I was thinking might be a nice little project for something like this. Can the ESP32 and AtomVM be used for something like this?

Maybe a RFID reader might be better/easier?

1 Like

We do not currently have integration with the IDF SDK Bluetooth APIs, but that is probably not that hard to do. Mostly involves implementing what AtomVM calls a “port”, which is basically an Erlang process implemented in C, since typically communication with the Bluetooth APIs involves some kind of state management. It is subtle and can be complex, but is doable and should be on the roadmap.

I am more curious about what your plans would be for managing locking/unlocking a physical device, such as a door bolt. That I would expect would require some kind of interaction with a servo motor. The LEDC APIs can do some of that, but I have seen in IDF SDK 4 there is a new API dedicated to servo motors, so that, too would require some integration.

RFID would require some kind of additional device with which the ESP32 would communicate – 2-wire I2C or 4-wire SPI, or something like that. This tutorial hints at SPI.

Upshot: currently, I don’t think this would work out of the box and would involve considerable design and integration effort. That doesn’t mean it’s not worth it, and parts of this would probably end up being a contribution to the AtomVM project.

2 Likes

[BromleySat Link] Is that the correct one?

Yes, that is the ESP32 Devkit. A decent kit for getting off the ground, indeed!

2 Likes

I think a few people have done them with a Raspberry Pi hence wondered whether it might work with an ESP32. Let me see if I can find an article…

Found this video - he has 3 factor auth too :lol:

For my purposes just them putting the phone near the lock would have been ideal, hence wondered about RFIDs.

The idea first came to mind when the health club I was a member of at the time wanted to get a new membership and entry system - doing the recurring payments/membership side would have been easy enough but I wasn’t sure about the entry system (probably would have gone with some sort of card reader).

That could be a business idea for someone - create and sell such a system for gyms and health clubs :003:

1 Like