peerst's comments

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.

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.

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.

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.

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.

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.

Of course it can. It runs everything that runs on BEAM, Elixir, LFE, erlua and Erlang

Firmware update in the field is important but only a small aspect of a embedded system (one that really needs to work).

But Erlang already offers a lot around releases out of the box and in our case The VM + the whole "OS" is just one file to swap so we don't have a lot of problems one has if Linux + Erlang + Application needs to be updated.

FWIW: for larger Embedded systems we use FreeBSD + nanobsd wich solves a lot of the above mentioned problems. Update image verification and running the update is about 200 lines of Erlang code. And nanobsd comes with the normal FreeBSD system (builds disk/flash filesystem images with multiple partitions for easy update -- runs from one swap to the other)

Yes that also means the latency is not very long since in normal Erlang processes the process heap is also quite small so it doesn't take long to collect. Even without our planned extensions to the Erlang VM its astonishing well behaved in real world realtime applications.

Soft/hard realtime was always a spectrum and basically the point of hard-realtime is never reached in practice (if your hardware dies or glitches you miss your deadline, caches are hard to model but you't want to switch them off etc).

Even without changed VM one can enforce garbage collection at certain points which moves Erlang on the throughput/realtime spectrum more towards realtime. Not worth it if a non realtime OS schedules you but of value when controlling exactly who can preempt you (under RTEMS no-one is feasible)

If you ignore the external memory the SAMV71 on the Grisp-Base has 384k on chip memory ...

We plan to use this for the inner loop of the Erlang VM since its much faster than external memory. But thats a optimization for later after we can actually ship boards (QI 2017)

Well with RAM and flash you can either fit everything in on chip memory or you need external memory.

Once you have external memory 64MB is the smallest that you can get and be confident that you can obtain it for the next years. Its also not a big cost factor.

Grisp-Base is a evaluation board to get people easily started with Erlang running directly on hardware so not much use artificially limiting memory here. The board size is also larger than minimal to have all these nice PMOD connectors with enough room for the PMODs around them. Normally one would build some prototypes or smaller applications < 100 boards. When this works its fairly easy and cheap to build a customized board only the parts needed for the actual IoT application.

There are new SoC automotive controllers who will be able to run a Erlang VM without connecting any external memory which we plan to target for the future.

64K flash/16K RAM will never be able to run a Erlang VM so its outside of our scope. IoT trends are to move more calculation towards the edge since the cloud can't grow enough.

Actually we have Erlang on RTEMS in production since Erlang R16B03 on a MPC8309 embedded cpu (200MHz) this is running a controler for industrial manufacturing transport system with attached RFID antennas and a distributed PLC language that compiles to beam files also.

The main work that is done at the moment is the expectedly Wifi driver stack where there was a bit unexpected extra work to do -- longer story but we needed a from scratch new USB driver which needed us to upgrade the FreeBSD network stack to the most current, currently getting Wifi connections but the FreeBSD driver we use needs some adaptions still.

The porting Erlang part is mainly rebasing to the current Erlang version and disentangling of some customer code. But we already know it generally works quite well.

"require guarantees that erlang can't give" ... at the moment, working on it.

In the meantime note that the percentage of stuff that really needs hard realtime in many systems is quite low. What I do at the moment is run Erlang on RTEMS (see my other posts) keep the hard realtime parts as simple as possible (always a good idea), write them in C and run them on a higher prio than the Erlang runtime which handles all the complicated things. Works like a breeze in practice

Soft is the new hard ;-) If you reason about hard realtime you pretty soon end up with the question: how high can the probability be that it misses a deadline. If you run on modern embedded CPU's with pipelines and caches its often all you can do (I am aware that some are modeling the CPU with caches, memory and everything to achieve 100% but thats very expensive and if you switch CPU's there is half a year worth of modeling down the drain)

The real world hard realtime systems often are built like: lets test it (with deadline miss triggering a failure) and if it works make sure we still have 10% of safety margin (which will later be melted down because of features ;-)

Well Erlang is running on RTEMS in production in industrial control systems http://www.grisp.org

Hard realtime processes to come