
GRiSP 2 – Erlang and Elixir on bare metal - lelf
https://www.kickstarter.com/projects/peerstritzinger/grisp-2
======
Ixiaus
This is neat, I would have loved to see this a few years ago when I was
working on a touchpad dimmer that I used Erlang on (the hardware was
originally designed to run Linux so it was easy to put Erlang on there but
having a lower-cost solution by not requiring Linux would've been great).

Erlang's remote RPC, high-quality CRDT libraries, and hot-code loading made it
an incredible technology for implementing IoT software product features.

~~~
marci
Would something like this[1] worked for your project?

[1] [https://medium.com/@Bettio/atomvm-how-to-run-elixir-code-
on-...](https://medium.com/@Bettio/atomvm-how-to-run-elixir-code-
on-a-3-microcontroller-b414773498a6)

~~~
Ixiaus
Possibly.

------
elcritch
This is great! I haven't tried the boards (yet) but it's difficult to find
good industrial ready boards out there. Combine that with the difficulty of
handling precise & consistent timing below 1 ms in Linux then these boards are
a real gem!

~~~
amelius
Question about Erlang: is it possible to send large blobs of binary data (e.g.
video frames) from one process to another with the guarantee that the data is
not serialized and the transfer is close to instantaneous?

~~~
viraptor
If your binary is over some threshold (video frames almost certainly qualify)
and the processes live on the same node, then the binaries should stay on
binheap / refcounted memory and not get copied.

~~~
amelius
Ok, that's good to know. How would that work for a large tree with many small
nodes? Is structural sharing possible between the two processes?

~~~
jlouis
Not a priori. In practice, I'd guess that if we destructure a typical video
frame, it will have a header which is somewhat tree-like and a payload which
we are not going to touch and decode. In that case, we avoid the copy for the
heavy parts of the frame, i.e., the payload.

A good trick is that if you have a full frame from the network, keep a pointer
to the full frame. Then decode the header as needed on top. This way, since
the frame is full, you are guaranteed that no copy will occur for the frame
while you are processing it. Also, the redundancy of the header is likely to
be small in overhead with this approach.

About 10 years ago, I did some work in Erlang where I was moving around 16
kilobyte blocks of data. I managed 800mbit at that time on that generation of
hardware. The hardware on the board notwithstanding, I think Erlang is much
better at handling this nowadays.

As for the structural shaing between nodes: it _is_ possible but only for data
which is written very rarely and read quite often. In practice, the copying
overhead in typical usage scenarios tend to be much cheaper than what people
fear. One reason is that _after_ the copy, you obtain cache locality, though
also potential increased cache pressure.

------
opwieurposiu
I'm not sure this counts as "bare metal" since it runs in a VM. Though doing
it this way is probably cheaper then using an FPGA.

~~~
dnautics
I'm not 100% sure but I think it's not running on a VM in the virtualization
sense; by VM they probably mean BEAM, which is a VM in the same sense that JVM
or python are VMs.

~~~
wiml
I was hoping they'd actually made a bare-metal BEAM implementation like the
Lisp and Forth hardware that people have made in the past. This device looks
like it's Erlang-on-BEAM-on-RTEMS, which is undoubtedly a more practical and
useful thing, but less intriguing.

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

~~~
TickleSteve
If RTEMS is controlling the execution of your code, your running _on_ or _in_
RTEMS.

Direct hardware access isn't really "bare metal" in the same manner as
software running in DOS is not bare-metal. direct-hardware access is provided
in both.

~~~
e_proxus
RTEMS isn't "controlling" the execution of the code, it just supplies
implementation for OS-specific utilities (effectively the POSIX API). The BEAM
VM code is compiled to machine code and runs directly on the CPU. As peerst
explained, if you write your own C code in an Erlang port driver for example,
you don't have to use RTEMS at all.

~~~
anonymousDan
Is there the ability to run multiple OS processes or is the BEAM VM the only
thing running after boot?

~~~
e_proxus
You can only run one process in RTEMS (hence the name The Real-Time Executive
for Multiprocessor Systems), however you can simulate other processes via
threads. This is how we run the network stack and Wi-Fi configuration tools
among other things.

------
ElijahLynn
Love the bookshelf in the background of Peer Stritzinger's video feed.
FreeBSD, UNIX, and a huge row of O'Reilly books on the bottom shelf! I think
O'Reilly are some of the best, most thoroughly reviewed technical books out
there, I always choose O'Reilly if the topic exists as they seem to vet their
authors quite well and make sure they have competent subject matter experts
actually write and review the books!

#phsycialbooks #FTW

------
tombert
I wonder if this will support Joxa or Lisp-Flavored-Erlang. Those are pretty
much all I use on the Erlang VM nowadays, and I would love to get more into
embedded stuff.

~~~
e_proxus
Because it is the full Erlang BEAM VM it can run any byte code compiled for
it, including Joxa or LFE. However, we only have extra helper tooling for
Erlang and Elixir at the moment. You can create a release manually and include
any dependencies you want though.

~~~
tombert
Oh!! That's super cool, I think I will contribute then.

Assuming that I'm not a completely incompetent at programming (which
admittedly might be a stretch :) ), would you be open to someone making a PR
and adding Joxa or LFE tooling?

------
bobwaycott
This is really cool. You can find out more about the project at
[https://grisp.org](https://grisp.org)

------
nikofeyn
how does this compare to nerves?

~~~
thenewwazoo
Nerves is Linux with an Erlang init(1), built with buildroot, and using sysfs
for peripheral I/O. This is BEAM on an RTOS, which makes it effectively bare-
metal.

~~~
DoingIsLearning
Well to be technical an RTOS is not effectively baremetal. But I agree that it
is extremely 'close to the metal'.

