This video https://youtu.be/TBrPyy48vFI?t=1277 is a few years old, but it covers how the GRiSP platform combines Erlang and RTEMS Real-time OS [1] to overcome Erlang VM's soft real-time limitations and achieve hard real-time event handling.
I suppose having the small DRAM footprint is required to meet extremely low power requirements. How low power is it? The CPU has a 18.6 μA/MHz Run mode at 3.3 V [1], so 61μW! I wanted to know more about the power harvesting applications though.
The development was funded by a research project where the coordinator was a manufacturer of thermal energy harvesting devices. That's why we focussed on power most.
That requires certain choices for CPU, RAM.
We also have a lot of energy management hardware on the board: All PMODs can completely switched off. There is a separate wakeup logic that triggers when the capacitor that gets charged by the harvester has reached a certain charge level and many more.
The challenge with using Erlang for systems like that is that it has a boot phase which it needs to get through until we can manage energy from the Erlang level. So we either need to have enough charge to get through the whole boot or we need to manage the boot process to and do it in chunks then sleep again.
That's what we want to find out with this hardware but first we needed to squeeze in Erlang VM, RTEMS, TCP Stack and all of the Erlang objects to be useful (first goal was reach the shell). That's where we are right now.
I met Peer at Lambda Days in 2023 briefly. We didn't chat for super long (about 5-10 minutes), but (and I do genuinely mean this as a compliment), he was one of the most enthusiastic geeks I've ever met. He seemed so genuinely passionate about Erlang and GRiSP and technology in general, it was outright delightful to talk to him.
I love people who can stay excited and optimistic about stuff; it's so easy to be cynical, it's refreshing to meet someone who hasn't had the life sucked out of them.
I need to pick up a GRiSP Nano one of these days. I have the GRiSP 1 and even managed to get Lisp Flavoured Erlang working on there [1], but I haven't played with it much since then. I should fix that.
> I love people who can stay excited and optimistic about stuff; it's so easy to be cynical, it's refreshing to meet someone who hasn't had the life sucked out of them.
Is 16 MB "only" for Erlang? I thought it started like something made for embedded hardware decades ago? Wikipedia says 1986.
Makes me curious at what pace and why the size has grown from 1986-2025 and how long ago the line was crossed that made 16 MB seem like a that is now a small runtime?
It's an evaluation board for a technology stack. That's its "use". We wanted to explore the design space towards smaller/low power/cheaper and find out where we can still squeeze a fully functional Erlang VM. We are working on distributed computing that benefits when we can run the same BEAM files (Erlang VM object files) everywhere from IoT to Edge to Cloud
I love the idea of elixir/erlang in robotics/embedded environments, and so from my research I can confidently say very few. As far as I can tell, when people do use it it's primarily for industrial equipment, and the main selling point is liveview/scenic for displaying information about the equipment.
I want to believe we'd someday see erlang/elixir all over the place, especially in flight software, due to their use of "lightweight processes" and high fault tolerance, but I don't see it happening any time soon, and I certainly don't see people hiring for it. I think it could solve some legitimate industry issues but it's too big of a change for too subtle of benefits
[+] [-] plainOldText|8 months ago|reply
[1] https://www.rtems.org/
[+] [-] jswny|8 months ago|reply
[+] [-] signa11|8 months ago|reply
--
thanks !
[+] [-] kristianp|8 months ago|reply
[1] https://www.st.com/resource/en/datasheet/stm32u5f7vj.pdf
[+] [-] peerst|8 months ago|reply
That requires certain choices for CPU, RAM.
We also have a lot of energy management hardware on the board: All PMODs can completely switched off. There is a separate wakeup logic that triggers when the capacitor that gets charged by the harvester has reached a certain charge level and many more.
The challenge with using Erlang for systems like that is that it has a boot phase which it needs to get through until we can manage energy from the Erlang level. So we either need to have enough charge to get through the whole boot or we need to manage the boot process to and do it in chunks then sleep again.
That's what we want to find out with this hardware but first we needed to squeeze in Erlang VM, RTEMS, TCP Stack and all of the Erlang objects to be useful (first goal was reach the shell). That's where we are right now.
[+] [-] unknown|8 months ago|reply
[deleted]
[+] [-] tombert|8 months ago|reply
I love people who can stay excited and optimistic about stuff; it's so easy to be cynical, it's refreshing to meet someone who hasn't had the life sucked out of them.
I need to pick up a GRiSP Nano one of these days. I have the GRiSP 1 and even managed to get Lisp Flavoured Erlang working on there [1], but I haven't played with it much since then. I should fix that.
[1] https://medium.com/@tombert/working-with-lisp-flavoured-erla...
[+] [-] czhu12|8 months ago|reply
How true that is
[+] [-] 3036e4|8 months ago|reply
Makes me curious at what pace and why the size has grown from 1986-2025 and how long ago the line was crossed that made 16 MB seem like a that is now a small runtime?
[+] [-] jacquesm|8 months ago|reply
[+] [-] voicedYoda|8 months ago|reply
[+] [-] bushytop|8 months ago|reply
[+] [-] peerst|8 months ago|reply
[+] [-] guywithahat|8 months ago|reply
I want to believe we'd someday see erlang/elixir all over the place, especially in flight software, due to their use of "lightweight processes" and high fault tolerance, but I don't see it happening any time soon, and I certainly don't see people hiring for it. I think it could solve some legitimate industry issues but it's too big of a change for too subtle of benefits
[+] [-] Xunjin|8 months ago|reply
[+] [-] victorbjorklund|8 months ago|reply