GRiSP – Erlang-based IoT hardware platform | Hacker News Reader

GRiSP – Erlang-based IoT hardware platform

grisp.org

188 pointspjmlp48 comments

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.

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.

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.

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

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 [2] http://www.hoperf.com/upload/rf/RFM95_96_97_98W.pdf

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

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.

Take a look at the RadioHead library [1]. It supports mesh networks on low power radios and runs on Arduino or pi's.

As mentioned in my sub comment, it'd be great to be able to either interface via ports or a nif. However, it gets trickier because the smallest erlang vm is either Grisp or LingVM. So if you want to use micro controllers you're out for erlang/elixir. Since I had another project at work relying on interacting and buidlding mesh networks on nerves devices, I figured starting with a Bert-rpc inspired Arduino library would be good a good start [2].

Let me know if you'd be interested in helping on an erlang/elixir native port of Radiohead or a ports wrapper. I'm thinking a nice BSD/MPL project would be a boon for others too... Plus how would you think OTP supervisors would help setup a mesh network?

[1]: http://www.airspayce.com/mikem/arduino/RadioHead/ [2]: https://github.com/elcritch/NanoBERT

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.

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

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

flash/RAM == size, cost, and power

Look at a die microphotograph of an ARM Cortex M4.

The RAM takes up more than half the die area. Flash is about a third of the die area. ALL the functional units and processing cores takes up less than 1/4 of the die area.

Very good point. For IoT widgets and perhaps even wearables, I'd rank things by power, size and cost coming in a bit later. The old way had cost first but people are seeing the light.

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.

I agree, but it is a matter of cost/comfort.

For many use cases, going to a PIC doesn't make sense if just a few units are to deployed, with the price difference being just a few euros.

forth? :)

though it's a bid of a different mindset. Thinking Forth is great book ( not just in terms of forth ) which really sells the idea.

I wish people would quit promulgating Forth.

Sorry, but it is not a production language. It is a puzzle language. Many things which are straightforward in even the worst programming language are a brain teaser to figure out how to organize in the "Forth Way(tm)".

Scheme and Lua come closest to my ideal.

However, I just can't deal with 1-based indexing from Lua. Sorry. Too many things talk to C API's.

Scheme is okay, but almost none of them are truly small anymore. Even the ones like picobit (https://github.com/stamourv/picobit) require quite some grunty support from a desktop machine outside the processor.

Shame no one told NASA what a useless language Forth is.

http://web.archive.org/web/20101024223709/http://forth.gsfc....

I would be very interested to hear from someone using Forth in production (especially for something like the above link) on their personal experience wrt its advantages compared to other available options.

one of my very first jobs we had products for monitoring underground petrol tanks and petrol (gas, even though it's not a gas ;-) ) pumps. All written in forth, while a bit obscure, actually was quite cool.

as an aside, The guy who was primarily responsible for that now has a FRP library ( http://sodium.nz/ ) and written a book on FRP using petrol pumps as an example

It was also used for some of the drivers of a probe in the Rosetta mission (I think, at the very least it was a probe made by the ESA)

With 16k RAM, you won't get much. But the ESP8266 has 64k + 96k RAM and runs things like Lua and MicroPython. So now imagine what you can do with the ESP32, which has 416KB RAM.

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)

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.

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

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.

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.

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.

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

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)

As does using C for more complex applications ;-)

Somewhat similar to http://nerves-project.org/

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.

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

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.

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.

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)

> Both require BEAM, of course, plus the actual Erlang application itself.
Exactly - that part is not tiny, so I wonder what the two look like in comparison.

Entirely dissimilar. Last I looked, NERVES is a set of utilities that build Erlang to run as PID 0, and interact with Linux' sysfs subsystem.
RTEMS is an RTOS with a Posix layer. Peer has written a pure-Erlang epmd and ported BEAM to RTEMS.

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?

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

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

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

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

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

It's far lower power than something like Nerves, which runs a full linux kernel on top of something like a raspberry pi. Power usage is relative. At the end of the day this opens up new applications for Erlang/BEAM languages.

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.

Reply on news.ycombinator.com