> 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.
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.
Run Erlang/Elixir on Microcontrollers and Embedded Linux
31–40 of 55 posts
Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#32Pretty 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.
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
Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#33Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#34Earlier quoted context omitted.
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
For me its the complete opposite of simple. I am a fan of BEAM and OTP but im a horrible programmer. I have constant fear of having picked the wrong restart strategy in a supervisor. Or about ghost processes or whatever. I have no mentors and learn everything myself. I have no way of actually checking whether my implementations are good. With my skills id manage to make an Elixir system brittle because its not clear…
We were doing all sorts of things wrong and not idiomatically, but things turned out ok for the most part.
The fun thing with restart strategies is if your process fails quickly, you get into restart escalation, were your supervisor restarts because you restarted too many times, and so on and then beam shuts down. But that happens once or twice and you figure out how to avoid it (I usually put a 1 second sleep at startup in my crashy processes, lol).
Ghost processes are easy-ish to find. erlang:processes() lists all the pids, and then you can use erlang:process_info() to get information about them... We would dump stats on processes to a log once a minute or so, with some filtering to avoid massive log spew. Those kinds of things can be built up over time... the nice thing is the debug shell can see everything, but you do need to learn the things to look for.
Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#35huge 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?
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…
Grisp puts enough controls on the runtime that soft-realtime becomes hard-realtime for all intents and purposes, outside of problems that also cause errors in hard-realtime systems.
(Also, thanks Peer for being tremendously patient with a new embedded developer! That kind of friendly open chat is a huge draw to the Elixir community)
Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#36Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#37Earlier quoted context omitted.
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
Bigger processors with more RAM have always been available. The question has always been whether you're going to use a $20 processor when you could do the job with a 50¢ one. It's the difference between your product being cheap and disposable, and you getting to choose your margin based on your strategy; and not being able to move a unit without losing money, hoping to sell yourself to someone who knows how to do mor…
Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#38> 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.
(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.
Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#39would be possible to get my 90's computers and run erlang/elixir for a crypto node... or some version of it??
Re: Run Erlang/Elixir on Microcontrollers and Embedded Linux
#40I'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.
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