
GRiSP – Erlang-based IoT hardware platform - pjmlp
https://www.grisp.org/
======
thenewwazoo
This project is quite interesting, and very promising, if it's actually
available. RTEMS is an very well-characterized RTOS originally designed by the
military (a Real Time Executive for Missile Systems was the original meaning),
and it conveniently has a POSIX layer. I've built some things out of RTEMS and
found it to be a pretty enjoyable experience, once you get a build environment
set up (and don't touch it when you do!).

I have to wonder though, has Peer actually released any code yet? I implored
him to release a couple of years ago, and wasn't successful in convincing him.
At the time, he was insisting on some drivers to exist before he'd be willing
to. I was quite disappointed.

~~~
oomkiller
I haven't seen anything related to the Erlang changes, but the grisp github
project has an RTEMS app which I assume is for running/compiling your Erlang
apps with. The progress is really promising, I believe he just has a very high
bar for releasing things.

~~~
peerst
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.

------
edejong
Just a couple of days ago I was searching for Erlang implementations for low-
power mesh-networks.

Personally, for connectivity I wouldn't mind using a RFM69HW module or RFM9x
[1] (868 Mhz / LoRa)

Creating a mesh-network with supervisors using Erlang seems like aa
interesting and feasible idea. It's a good method to introduce actor systems
to a new audience.

[1]
[http://www.hoperf.com/upload/rf/RFM69HW-V1.3.pdf](http://www.hoperf.com/upload/rf/RFM69HW-V1.3.pdf)
[2]
[http://www.hoperf.com/upload/rf/RFM95_96_97_98W.pdf](http://www.hoperf.com/upload/rf/RFM95_96_97_98W.pdf)

~~~
thenewwazoo
I suspect you could accomplish this with NERVES without too much trouble. I'd
start with an Erlang port[1] that uses Linux's built-in SPI support to
interact with the device itself. If you need something a bit higher-level, you
might adapt the RadioHead library.

[1]
[http://erlang.org/doc/tutorial/c_port.html](http://erlang.org/doc/tutorial/c_port.html)

~~~
elcritch
Actually, nerves has decent API support built in! The tricky part is getting
all of the registers setup correctly for the radios. Alternately, there's a
C++ library for it, that's gpl, but could be setup as a nif or a port.

------
bsder
300MHz/64MB of RAM on an M7 doesn't exactly qualify as IoT in my book.

I pine for something that runs in 64KB flash/16K RAM that doesn't suck.

~~~
fra
I think you're using the wrong metric. It's not flash/RAM that makes something
"IoT", it's size, cost, and power.

~~~
keithnz
when it comes to power, low end chips win by order of magnitudes ( for example
[http://ww1.microchip.com/downloads/en/DeviceDoc/30009941G.pd...](http://ww1.microchip.com/downloads/en/DeviceDoc/30009941G.pdf)
). But it all depends on what your power constraints really are

------
davidw
Cool stuff - Peer has been working on this for a while, I think. He's a bright
guy.

It'd be nice to see what's been built with it, and also get a better idea of
what kind of hardware it runs on.

------
MrBuddyCasino
This is a super interesting concept. But also kind of the definition of niche.

Anyone tried this? Escaping C usually comes with a steep cost...

~~~
dxhdr
Tried Erlang? It's fantastic for everything except number crunching. The VM is
basically an OS and makes a lot of sense for embedded devices. I remember
reading about some guys programming drones with Erlang a few years ago, they
demo'd hot code reloading mid flight (an Erlang feature you get out of the
box), very cool.

However! Erlang doesn't have any hard real time guarantees so that may limit
applicability. Generally doesn't seem like it'd be an issue for IoT.

~~~
qohen
_However! Erlang doesn 't have any hard real time guarantees_

But this, from the end of the GRiSP page, is interesting:

* When Erlang is running on RTEMS there is very little latency between something happening on the hardware and a reaction on the Erlang level. There is strict control over what can pre-empt the Erlang VM: only hardware interrupts allowed. In practice, this means Erlang’s soft real-time is not as soft as on normal operating systems.

For the future, we plan to provide hard real-time processes on the Erlang
level; GRiSP-Base will be the main test platform for this. _

~~~
vvanders
That's really exciting especially with respect to how Erlang's GC model works.
I haven't used it in anger but everything I've read seems that Erlang doesn't
have a need to stop-the-world GC since there's no shared state and processes
can just drop their pool when they die without the need to collect.

~~~
naasking
Pauses for GC are per-actor for the Erlang VM, so indeed no stop-the-world, or
if there is, it's a very low latency sync point where the GC to switches mode.

There are plenty of soft and hard real-time GCs though suitable for use with
any GC'd language. For instance, the CHICKEN collector in [1] is an absurdly
simple copying collector with an observed maximum pause time of 120
microseconds with average pauses of 1 microsecond.

Low-latency GC tends to sacrifice a little throughput though, which is why
it's not more widely used. Relative to a standard concurrent MS, CHICKEN adds
up to 30% in execution time, although the average seems to hover around
10-15%.

[1] ftp://ftp.inf.ufrgs.br/pub/geyer/PDP-
Pos/Artigos/PDP-2011-2-TL1-artigos/PDP-2011-2-TL1-GT-A%20Study%20of%20Concurrent%20Real-
Time%20Garbage%20Collectors.pdf

------
pmontra
Somewhat similar to [http://nerves-project.org/](http://nerves-project.org/)

~~~
oomkiller
Somewhat, but it's very different in that it uses RTEMS, not Linux. RTEMS was
built for embedded computers on missiles, and is commonly used in space
applications. Nerves is a distribution of Linux buildroot, and has quite a bit
of fat compared to something like RTEMS. I can't wait to see Elixir running on
RTEMS, from my conversations with Peer, it seems he's ported the Erlang VM to
RTEMS directly, much like the OSE port.

~~~
davidw
I wonder what the difference looks like in terms of the total system
footprint.

~~~
thenewwazoo
Massive. NERVES requires Linux, plus system libraries. I've built RTEMS
applications in the tens of kilobytes. Both require BEAM, of course, plus the
actual Erlang application itself.

~~~
elcritch
Nerves is around the 10-20 MB range. The main downside of the Grisp system I
could see would be that nerves has a really nice two phase firmware update
story, and that isn't mentioned in Grisp that I've found. IMHO, the remote
firmware update and tooling is a "killer" feature of nerves.

~~~
peerst
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)

------
future1979
Newbie question: why isn't releasing beam source files for an existing popular
rtos(e.g. Freertos) an easier path to take? Is the issue posix support by the
underlying rtos combined with tool chain headaches?

------
revoltingx
Sounds awesome, and something I'll be looking into in the near future. Wonder
if it can run Elixir apps.

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

------
petra
Why not use c/c++ based actor systems , in a size more fitting small
microcontrollers , like [1] ?

[1][http://www.state-machine.com/doc/concepts.html#Active](http://www.state-
machine.com/doc/concepts.html#Active)

~~~
oomkiller
Go right ahead, use C/C++ based actor systems! This project is to allow Erlang
([http://erlang.org](http://erlang.org)) to run on low power embedded devices.

~~~
keithnz
this isn't low power ( well not in terms of what low power means in the
embedded world )

~~~
peerst
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.

~~~
keithnz
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.

