peerst
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.
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.
* 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.
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
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
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.
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)
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)
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)
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.
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.
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
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 ;-)
Hard realtime processes to come
This can only work of course if the underlying OS is also hard realtime capable. I have ported Erlang to the open source RTEMS http://www.rtems.org already. More details under http://www.grisp.org (sorry website not up to date but soon will be).
I'm using Erlang and GPU programming each for its area of expertise. FWIW I even use both together via https://github.com/tonyrog/cl
Erlang is great at asynchronous concurrency which happens to be able to run in parallel well because of how the VM is built.
GPU's solve totally different problems
Especially great is their page archiving ... goodbye link rot and you can even download the archives of your bookmarks