7 ms·
Run Erlang/Elixir on Microcontrollers and Embedded Linux
- unit149 1y ago[dead]
- burnt-resistor 1y agoTo chime in, this definitely won't run on a μC. No effing way. This is some serious marketing slop posting.
- Zaphoos 1y agoWhat about Gleam?
- nesarkvechnep 1y agoCall us when they implement OTP compatibility.
- worthless-trash 1y agoWhat part of otp do you need. I have supervision working. I have typed message passing.. I write erlang wrapping gleam modules.. its pretty easy.
- trescenzi 1y agoWhat part is missing? I’ve built a little distributed app that has a cluster registry and dns. There’s a tiny bit of Erlang involved but the majority of it is gleam. https://github.com/trescenzi/points https://github.com/trescenzi/points
- jen20 1y agoSeveral pieces: https://gleam.run/roadmap/ https://gleam.run/roadmap/ Much of it can be worked around as you suggest.
- dsincl12 1y agohttps://github.com/gleam-lang/otp https://github.com/gleam-lang/otp ?
- juped 1y agoI'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.
- garbthetill 1y agoyeah 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
- elcritch 1y agoThey support writing RTOS tasks in C as I understand it.
- Joel_Mckay 1y agoReal-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
- hoppp 1y agoPretty 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.
- worthless-trash 1y agoIs this something you do regularly?
- worthless-trash 1y agoNot sure why I'm downvoted, I'd like to know some good practices when using OTP for IOT, its not an area I know about.
- garbthetill 1y agoI 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
- AnEro 1y agoSame, my personal theory where it excels and overachieves is where there is already really fleshed out and oversaturated developer ecosystems (and experienced developer pool) that organizations have alot of legacy software built on it. I think it will gain momentum as we see more need for distributed LLM agents and tooling pick up. (Or when people need extreme cost savings on front facing apis/endpoints that run simple operations)
- zwnow 1y agoFor 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 to me what happens at all times.
- rkangel 1y ago> 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-32-bit-arm-cortex-mcus.html https://www.st.com/en/microcontrollers-microprocessors/stm32... Only the very very high performance ones are >1MB of RAM.
- jdndnc 1y agoRAM 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
- FirmwareBurner 1y ago>RAM on MCUs is getting cheaper by the minute. It really isn't. The RP2040 has 256KB RAM. Far away from 16MB. >now it's measured in MiB Where? Very few so far and mostly for image processing applications, and cap out at less than 8MB. And those are already bordering on SoCs instand of MCUs. For applications where 8MB or more is needed, designers already use SoCs with external RAM chips. >it will only be a couple of years for mainstream MCUs having that amount on board Doubt very much. Clip it and let's see in 2 years who's right.
- jbarberu 1y agoAlso curious what MCUs you're working with to give you this impression? RP2040 is 264k, RP2350 is 520k. I use NXP's rt1060 and rt1170 for work, and they have 1M and 2M respectively, still quite far away from 16M and those are quite beefy running at 500MHz - 1GHz.
- tonyarkles 1y agoWhile I generally agree with you, the RT106x line does support external SDRAM as well. I've got an MIMXRT1060-EVKB sitting here on my desk that has 32MB of SDRAM alongside the on-die 1MB of SRAM.
- whalesalad 1y agoSounds like nerves to me? But with soft realtime added in?
- toast0 1y agoMy 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.
- thenewwazoo 1y agoNerves is Erlang-as-init on Linux. GRISP is Erlang with RTEMS on metal.
- barbinbrad 1y agohuge 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 1y agoBeam 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?
- heeton 1y agoI spoke with Peer (the creator of Grisp) about this at Elixirconf earlier in the year, and I'm not an expert here so I hope I don't misrepresent his comments: 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)
- cyberpunk 1y agoI did the same workshop some years ago with him also, very nice and patient guy, I can recommend attending if anyone is curious how microelectronics actually work :}
- thelastinuit 1y agowould be possible to get my 90's computers and run erlang/elixir for a crypto node... or some version of it??
- asa400 1y agoYes - Erlang/Elixir wouldn't be the bound here. 90s hardware is plenty for them. They were designed for far less.
- dlcarrier 1y agoThe 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.