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.
Erlang's BEAM, assuming no chicanery of NIFs, will use reduction counting to eventually yield a scheduler to make sure other Erlang processes get execution time. This gives you kind of a "will eventually happen" property. It can't guarantee meeting a deadline. Just that all things will be serviced at some point.
Right GRiSP has support for creating RTOS tasks in C, IIRC.
Within BEAM itself there’s no priority mechanism, however, on a RPi3 or BeagleBone you could get about an 200 uS average response time to GPIO on Linux, even under moderate load. The jitter was pretty low too, like 10-20 uS on average, but the 99.9% tail latencies could get up to hundreds of millis.
That’s fine for many use cases. Still I now prefer programming on esp32’s with Nim for anything realtime. Imperative programming just makes handling arrays easier. Just wish FreeRTOS tasks had error handling akin to OTP supervisors.
Now Beam/Elixir would be amazing for something like HomeAssistant or large networked control systems.
Just a reminder that commonly "real-time" on stuff like VxWorks isn't hard realtime either. You test a bunch of scenarios, put in some execution CPU head-room you are comfortable with, and call it a day. With enough head-room and some more (or less, if you have money and time) hand-waving, you can more or less guarantee that deadlines will be kept.
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.
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.
[1] https://www.rtems.org/
quick-question: why go the `rtems` route ? would 'isolcpus' not work in this case ?
--
thanks !
I am not associated with the project, so I cannot answer that.
What are the soft real time limitations of erlang?
Erlang's BEAM, assuming no chicanery of NIFs, will use reduction counting to eventually yield a scheduler to make sure other Erlang processes get execution time. This gives you kind of a "will eventually happen" property. It can't guarantee meeting a deadline. Just that all things will be serviced at some point.
Right GRiSP has support for creating RTOS tasks in C, IIRC.
Within BEAM itself there’s no priority mechanism, however, on a RPi3 or BeagleBone you could get about an 200 uS average response time to GPIO on Linux, even under moderate load. The jitter was pretty low too, like 10-20 uS on average, but the 99.9% tail latencies could get up to hundreds of millis.
That’s fine for many use cases. Still I now prefer programming on esp32’s with Nim for anything realtime. Imperative programming just makes handling arrays easier. Just wish FreeRTOS tasks had error handling akin to OTP supervisors.
Now Beam/Elixir would be amazing for something like HomeAssistant or large networked control systems.
Erlang does have a mechanism to modify process priority, with process_flag/2,3.
As of OTP 28 there's also priority messaging that a process can opt in to. Not really related, but it's new and interesting to note.
Just a reminder that commonly "real-time" on stuff like VxWorks isn't hard realtime either. You test a bunch of scenarios, put in some execution CPU head-room you are comfortable with, and call it a day. With enough head-room and some more (or less, if you have money and time) hand-waving, you can more or less guarantee that deadlines will be kept.
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.
[1] https://www.st.com/resource/en/datasheet/stm32u5f7vj.pdf
This is incredible. Kudos on getting it done, and done so quickly!