Run Erlang/Elixir on Microcontrollers and Embedded Linux

[rkangel]

> MCU-class footprint (fits in 16 MB RAM)

That is absolutely not an MCU class footprint. Anything with an "M" when talking about memory isn't really an MCU. For evidence I cite the ST page on all their micros: https://www.st.com/en/microcontrollers-microprocessors/stm32...

Only the very very high performance ones are >1MB of RAM.

[marci]

For squeezing erlang in KiB sized RAM, the AtomVM project is probably a better fit.

https://github.com/atomvm/AtomVM

[PinguTS]

I see their board uses a daughter board from Phytec, a German company too. This is based on very high performance NXP MCU, the i.MX 6UL, with additional external DDR RAM.

[cmrdporcupine]

Eh. It's getting blurry and has been for some time. To me these days the differentiators are: does it have an MMU? Address lines for external memory? Do you write for an OS or for "bare metal" / RTOS kit? Are there dedicated pins for GPIO?

If you choose some arbitrary memory amount as the criterion it will be out of date by next year.

[derefr]

Espressif calls the ESP32 an MCU, and at least 1/3 of ESP32 models have >1MiB of onboard PS ("pseudo-static") RAM (i.e. DRAM with its own refresh circuit.) At least 20 of the ESP32 models do have 16MiB.

(And I would argue that the ESP32 is an MCU even in this configuration — mostly because it satisfies ultra-low-power-on-idle requirements that most people expect for "pick up, use, put down, holds a charge until you pick it up again" devices.)

So, sure, if you mean the kind of $0.07 MCU IC you'd stuff in a keyboard or mouse, that's definitely not going to be running Nerves (or any other kind of dynamic runtime. You need to go full bare-metal on these.)

But if you mean the kind of $2–$8 MCU IC you'd stuff in a webcam, or a managed switch, or a battery-powered soldering iron, or a stick vacuum cleaner with auto suction-level detection, or a kitchen range/microwave/etc with soft-touch controls and an LCD — use-cases where there's more-than-enough profit margin to go around — then yeah, those'll run Nerves just fine.

[TrueDuality]

You don't necessarily need on-package RAM for this. I'm not sure I'd build a project around this, but 16MiB of RAM would hardly be BOM killer.

[jdndnc]

RAM on MCUs is getting cheaper by the minute.

A couple of years ago it was measured in bytes. Before the RP2040 is was measured in dozens of KiB now it's measured in MiB

While I agree that 16 MiB is on the larger side for now, it will only be a couple of years for mainstream MCUs having that amount on board

[hoppp]

Pretty cool. I am a fan of everything Erlang. Managing large clusters of IOT devices running Beam sounds like a good idea not just because of fault tolerance but for hot swapping code.

[garbthetill]

I am the same but for elixir, the beam is awesome & I always wonder why it still hasn't caught on with all the success stories. The actor model just makes programming feel so simple

[worthless-trash]

Is this something you do regularly?

[juped]

I'm interested in the claimed real-time capabilities, but it's hard to find anything about them written there. Still, I like the hardware integration.

[Joel_Mckay]

Real-time is some of the most misused jargon in modern history.

In general, most JIT or VM can't even claim guaranteed latency. People that mix these concepts betray their ignorance while seeming intelligent.

FreeRTOS is small and feasible.

VxWorks if your budget is unconstrained.

LinuxRT kernel (used in LinuxCNC) with external context clocking, and or FPGA memory DMA overlap module (zynq SoC etc.)

Real-time is a specialized underpaid area, and most people have too abstract of an understanding of hardware to tackle metastability problems. =3

[garbthetill]

yeah the claim is ambiguous because the beam itself is only guaranteed soft real time, leaving it open ended might make ppl think hard real-time especially since its hardware

[whalesalad]

Sounds like nerves to me? But with soft realtime added in?

[thenewwazoo]

Nerves is Erlang-as-init on Linux. GRISP is Erlang with RTEMS on metal.

[toast0]

My tldr is grisp is beam on an rtos; nerves is beam on a minimal linux; but they also have grisp allow and grisp forge that are beam on linux. Any of these gives you soft realtime.

[barbinbrad]

huge fan of elixir. and definitely have some dumb questions.

in some of the realtime architectures i've seen, certain processes get priority, or run at certain Hz. but i've never seen this with the beam. afaik, it "just works" which is great most of the time. i guess you can do: Process.flag(:priority, :high) but i'm not sure if that's good enough?

[toast0]

Beam only promises soft realtime. When switching processes, runnable high priority tasks will be chosen before runnable normal or low priority tasks, and within each queue all (runnable) tasks run before a task runs again. But beam isn't really preemptive; a normal or low priority task that is running when a high priority task becomes runable won't be paused; the normal task will continue until it hits its reduction cap or blocks. There's also a chance that maybe you hit some operation that is time consuming and doesn't have yield points; most of ERTS has yield points in time consuming operations, but maybe you find one or maybe you have a misbehaving NIF.

Without real preemption, consistently meeting strict timing requirements probably isn't going to happen. You might possibly run multiple beams and use OS preemption?

[Zaphoos]

What about Gleam?

[nesarkvechnep]

Call us when they implement OTP compatibility.

[thelastinuit]

would be possible to get my 90's computers and run erlang/elixir for a crypto node... or some version of it??

[dlcarrier]

The page says their implementation requires 16 MB of RAM, so a late 90's computer could run it, but even mid-90's computers, like early Pentium models, often came with less RAM than that. If it shipped with Windows 98 or later, it should have 16 MB.

[asa400]

Yes - Erlang/Elixir wouldn't be the bound here. 90s hardware is plenty for them. They were designed for far less.

[burnt-resistor]

To chime in, this definitely won't run on a μC. No effing way.

This is some serious marketing slop posting.