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 ;-)
I have a project planned which when funded will give us hard realtime guarantees for certain Erlang processes.
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).
