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.

Thanks for your detailed reply. What are the uses for that kind of thing? Does bluetooth low power fit into that kind of power budget?

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

It's all relative. Hard Realtime vs Soft Realtime is not clearly delineated. Because on anything real world there is always a probability distribution for every deadline.

Our observation is that Erlang's "soft-realtime" is already getting much harder once Linux stays out of the way. We have a master thesis worth of research on having multiple sets of schedulers in one Erlang VM that run on different hard real-time priorities plus research on a network of message passing and garbage collecting Erlang processes can be doing Earlies Deadline First scheduling.

However that stayed prototypical because we found relativeness of vanilla Erlang on RTEMS was good enough for all practical customer problems we solved.

For very high performance hard real-time we drop down to C and we are currently working on a little language that can be programmed from the Erlang level that avoids that.

With Linux we can only run on larger embedded CPUs that support virtual memory well enough. With RTEMS we can go towards much smaller platforms.

Addendum: we have Buildroot and Yocto based platforms too. Not clear on the website right now but we have three platforms actually:

* GRiSP Metal - aka just GRiSP (Erlang/Elxiir + RTEMS)

* GRiSP Alloy - Buildroot Linux based, starts the Erlang/Elixir runtime as process 1 similar to Nerves but more language agnostic (Nerves is for Elixir only) and we support RT Linux and running multiple Erlang Runtimes at different priorities

* GRiSP Forge - Similar to alloy but Yocto based.

The idea is that from the high level language level they are more or less interchangeable.

ah ! indeed it can. do such platforms have 18m of memory and then some ?

Its not really „on RTEMS“, its more side by side. RTEMS is not a layer between the BEAM and te hardware its just helping by providing threads, TCP stack and file access. From a Erlang NIF or port driver (thats what we use to access the outside world in Erlang and Elxir) you have direct access to hardware registers and e.g. CPU interrupts.

If RTEMS is controlling the execution of your code, your running on or in RTEMS.

Direct hardware access isn't really "bare metal" in the same manner as software running in DOS is not bare-metal. direct-hardware access is provided in both.

RTEMS isn't "controlling" the execution of the code, it just supplies implementation for OS-specific utilities (effectively the POSIX API). The BEAM VM code is compiled to machine code and runs directly on the CPU. As peerst explained, if you write your own C code in an Erlang port driver for example, you don't have to use RTEMS at all.

Is there the ability to run multiple OS processes or is the BEAM VM the only thing running after boot?

You can only run one process in RTEMS (hence the name The Real-Time Executive for Multiprocessor Systems), however you can simulate other processes via threads. This is how we run the network stack and Wi-Fi configuration tools among other things.

Yes we boot the BEAM on the hardware.

RTEMS supports all 32bit hardware architectures. We also run it on a PowerPC controler for a customer project, but it also runs on Sparc, Mips all Arm and many other architectures.

We don’t use the MMU so we don’t need it, some embedded chips have even small MMUs that allows it running Linux size OS but since they have very small translation lookaside buffers it needs to traverse the in RAM page table very often and performance is quite poor then

Back then it was only running on customer specific hardware and was entangled with application code.

Building this special hardware for it we can offer better user experience than with just a code release. Once we ship the board all of the software will be released

As does using C for more complex applications ;-)

This is a eval board, which is optimized for developer time.

In practice low power and performance are interchangeable (you try to race as fast as you can to the next point where you sleep as deep as you can). The CPU has decent sleep modes so when the system idles it can be made considerably low power.

So since Erlang is a language running on a VM you give up some sequential performance (power consumption). But in real world embedded systems you see a similar effect than with Erlang on the server: it reacts quite quickly on external events which is what most embedded systems do most of the time.

So the same which can be achieved on a server counterintuitively more performance you would expect looking at the sequential Erlang performance one can get in a embedded system. And this can be translated to power consumption directly and indirectly: quick reaction then sleep longer, possible reduction of clock speed or smaller CPU.

where I am ( www.outpostcentral.com ) we look for extremely low power, so we have micros dedicated to that. Most sleep currents of processors like this are just too high for frequent battery operation. However we do use a higher power ARM processor for comms / high level processing functions, but that gets completely turned off for the majority of the time.

So this is still really cool, conceptually, this brings a very good platform to probably the lowest level that's practical. I've put it on the list of things to consider for one of our new product designs.