The Nerves core team is focused on microprocessor-based embedded devices, so supporting a Cortex-M0 device is not something that we’d take on. That’s not to say that what you propose wouldn’t be interesting.

The two routes I know that might support the Pico are:

1. Porting AtomVM which is a small BEAM bytecode interpreter
2. Using Lumen to compile Elixir to machine code.

The RPi Pico is based on the RP2040-Microcontroller, which is a Cortex-M0+. While its the biggest M0 I know of (lots of RAM, Flash, MHz) its still a very limited design, most notably: it has no FPU.

The most lightweight option AtomVM offers is a STM32F4 which is a Cortex-M4 with FPU.

https://github.com/bettio/AtomVM/blob/master/README.STM32.Md

Maybe they can go smaller? But M0 - doubtful!? If its possible this would be indeed a great opportunity and I’m sure the AtomVM-team will take it.

see here for a comparison (Table “ARM Cortex-M instruction variations”)

You should have a look at https://www.grisp.org/ if you are interested in BEAM on smaller platforms.

EDIT: Just found this: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/is-cortex-m4-the-strongest

Hey folks, sorry to resurrect this thread, but it appears that AtomVM now supports the Raspberry Pi Pico: Getting Started Guide — AtomVM 0.7.0-dev+git.f42fb232 documentation

Does this mean that Nerves might support the the Pico as well?

No, it means you can run Elixir on the Pico via AtomVM. You might be able to pull some Nerves libraries in but if they rely on anything from Linux you are out of luck.

I haven’t looked but I would assume there isn’t a regular network stack in AtomVM.

I think we will explore shipping AtomVM builds to microcontrollers such as the Pi using NervesHub. But I would be very surprised if Nerves gets adapted to the point that it will run on the Pico.

If you read what actually AtomVM does:

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.

This implies that a lot of features of the VM we use and love might be not present or work differently, so I can bet that even native functionalities from OTP (like :tcp) might not work at all.

I would go ahead and safely assume that integration with nerves is impossible and it might be subject to undefined behavior as some core things we imply about the VM might not be true anymore.

Maybe it should be highlighted that even while we talk about nerves as an elixir project a lot of nerves is wrapping an elixir release in a linux system and making that a shippable unit + elixir libraries to help integrate with that linux OS. Remove the linux part and the question becomes what nerves is supposed to bring to the table in the first place. The atom vm would basically be the counterpart to both the linux os and the beam vm on a nerves system.

This is not to say that nerves as a whole might not hold desireable features like tooling over atom vm, but those things are not stuff that could be simply pulled over.