So, hello everyone, today I'm going to talk about that on the M, but before that I will briefly introduce myself.
I'm David Beteo, I've been tinkering with hardware and the baddest systems for quite a long time.
And also I, since always been very passionate about open source software.
And in 2017 I discovered the Lixir and they fell in love with it.
And the same year later I created the Atom Vian project.
And before starting with Lixir and Langa and Glenn, I would like to briefly talk the user experience with C++.
And first of all I would like to talk about, for example, multiple cores on microcontrollers.
As soon as you realize that recent microcontrollers have two cores, you want to use concurrency, for example.
But concurrency, if you know C, it can be very tricky.
And it's easy to get it wrong.
And there is a lot of manual stuff that has to be done.
And also, if we think about something different, like parsing banners that are coming from some kind of wire format, or maybe some kind of remote services, you hand doing binary parsing by hand.
That in the best situation is just boring, but it can be also security concern.
And also, as soon as you interact with some kind of remote service, you hand making some multiple cores, so you have to wait one rapidly before making another call or whatever.
So you hand having a synchronous code that turns pretty quickly into maybe some kind of call back health.
And let's not even talk about memory management.
And you hand pretty easily asking yourself, did I free that memory and transfer is usually no.
So I will talk about Elixir Langangling.
And those are functional languages.
They are functional languages that have been designed to run on the beam that is the reference Erlang VM.
And those languages have been designed for writing that highly testable software to write software for distributed system and reliable system.
And the first of those languages that appeared is pretty ancient actually that is Erlang.
It has some kind of prologue syntax, but actually is very good at writing software for distributed systems or reliable system.
And that there was some kind of modern twist and Elixir appear.
Elixir has a ruby-like syntax, and it is a highly productive language.
And the last one that appeared is the Glim language.
The Glim language has a modern take to types, and so it introduces static typing to the beam ward.
All these languages, as you can understand, they have different strengths.
But at the end of the day, they share the same kind of basic infrastructure that is the Erlang VM.
And they share a lot of features together.
So the first thing I would like to talk about is the actor model.
And when you talk about actor model, you end talking about processes.
And the question is, what I can do with processes, how they work on the Erlang VM.
Basically, on the Erlang VM, you can spawn as many processes as you like.
You can end having on an old like million of processes for free, nearly for free,
because processes on the Erlang VM are very cheap.
And actually, you can do that, because processes are VM processes.
They are not threats, they are not operating system processes.
They are just virtual machine processes.
And the other interesting thing is that you don't have shared memory.
If processes want to talk together, they have to resort to message passing.
So since you don't have shared memory, also all the concurrent stuff gets simplified, of course.
And this works also very well with functional languages, because basically a process is an infinite recursion that consumers messages and produces other messages.
And as you can see, as you can understand, making a synchronous software is very natural.
So this is definitely something we want to have in our IoT stack.
And another feature that I would like to talk about, that is very deeply rooted in the Erlang VM,
is the fault tolerance by the fault.
That means that we have to get back a little bit to the beginning of Erlang.
Erlang has been created from Ericsson for telephony switches.
And if you think about telephony switch, when you have to handle an emergency call, any kind of downtime is unacceptable.
So the point is that you cannot completely remove crashes or avoid all errors.
They can happen anyway.
So the idea is to deal with crashes, to deal with errors.
And that is what the Erlang VM and the old Erlang ecosystem is doing.
What it offers you is a very solid set of paradigms, set of APIs and pools for dealing, for example, with crashes.
And for instance, you have, for example, supervised or module that allows you to respond any process in a very controlled way.
As soon as you have a crash, you can even set policies.
So you can decide how to restart them, how when not to restart them in which way.
And this is something that also would like to have in our embedded projects because we want them to be very solid.
And something else that really I would really like to show you is pattern matching is another feature shared across all those languages.
And it is provided by the VM.
Basically, when you do pattern matching, you don't care about manual checking each value.
What you do is designing, deciding to shape of the data you expect.
For example, if we think about our factorial example, you will notice that we are defining the same function two times.
But which actual function we are going to execute is not up to us.
The virtual machine will pick up the right definition.
So for example, for the factorial one, we do a function definition for zero that always returns one.
And then we define the function again for any other value.
So the VM for us will decide the right version that will be executed.
We can even have more complex stuff.
In this kind of example, I handle replies and replies are mean we have several options.
And all those options are picked by priority.
And we have some kind of routing and the structuring together.
So fields are also extracted when there is a match.
So we can route everything to the right handling logic.
Again, the virtual machine does the job for us.
We don't have to worry about this.
And the interesting thing is that pattern matching applies to all data types, including binaries.
And binary things get very interesting because you can actually design them in memory layout of a binary.
And you can do pattern matching down to the single bit.
You can even decide if you are going to match against a little onion, vegan,
an integer float or maybe also integers with very odd sizes.
And everything is handled again by the VM.
And the interesting thing is that we can add some additional logic on top of them.
So additional constraints.
And we can just focus in writing the handling logic for binaries that matches what we need.
So we don't have to worry about handling any other kind of binary that maybe is not well formed.
So code gets very simple because this prevents us from writing those lines of code.
And this is another feature that definitely we would like to have in our VM.
And let's talk briefly about microcontrollers as well.
And a long time ago we had Arduino with first at the mega ones.
So Arduino was very small powerful but very limited because had few kilobytes of RAM.
Nowadays we have devices that have internet connections.
And they can have like 100 of kilobytes of RAM or even some megabytes.
But still they are quite limited if we compare them to our station.
We don't have the same amount of resources.
So this means that we cannot run the regular Erlang VM on them.
We need to resort to something different.
So the very big question here is, do we have any tool?
Can we in any way use out the feature?
I just described and many others that we love from the Elixir Erlang and Blimeco system on those devices.
And that's unfortunately yes.
For this reason I created that on VM that is lightweight virtual machine that runs on microcontrollers.
And allows you to run unmodified Erlang, Elixir and Blimeco code.
And the idea behind that to VM is that it is a virtual machine written from scratch with some key tradeoffs that has been set.
And the most important one is saving memory and also being very flexible and easy to port.
And so what I'm talking about is not science fiction.
This project is already available on GitHub.
You can already use it.
And I would say that it's production really and you can use it for making your next project.
And it includes also you can run also quite complex application.
And it includes also advanced features.
We have just in time but also we have an Erlang distribution.
So you can even make a cluster of microcontrollers with processes talking together.
Maybe on the same PCB and features like that.
That is pretty crazy.
And personally I later used atom VM for doing some home automation.
And experimenting with the lower nodes that feels very natural.
I mean using a language such as Elixir.
But actually you can do any kind of embedded IoT or automation project using atom VM.
And I think it is a pretty solid alternative to software stacks such as Arduino or maybe micro Python or many other.
And you can even use this project for making.
I mean if you need to embed an virtual machine in some kind of other constraint environment.
Actually it has been done for the browser.
But and it is very interesting because we cannot run Elixir.
For example as on the browser as a frontend.
But this is another story.
This is not this talk.
And if you want to know more about atom VM you can of course visit the website.
But you can also get in touch with us on Telegram and Discord.
And also since this year I am working full time on this project.
So if anyone has any kind of advice about how to make some kind of project that works.
I mean how to say that.
If you have any to make sustainable.
If you have any advice about this please reach me.
Also sponsors are of course welcome.
And thank you for your attention.
Do you have any quick question.
Questions from the audience.
Thanks for your talk and the work that sounds interesting.
If you say you support different mic controllers.
What does it mean in terms of the peripherals that are on the mic controllers.
Do you already have some kind of interface that you can.
Whatever talk to the I2C bus from Elang or Alex here or is that something that still.
Welcome progress.
Okay if and this is correctly.
You have you have a PIs for you talking with SPI experts.
See for handling GPOs all that stuff has been already implemented.
So if you want to to write a device driver for example for.
Temperature sensor you can use just any of the languages I mentioned.
You don't have to resort to the languages.
And the only reason to use in times the language if you want to drive.
Very hyper formats.
Staffware timing is very crucial.
Otherwise Erlang Elixir and Glimma are super fine for this kind of task.
And I can assure you that performances are pretty good.
And if you need more performances just in time.
And I have time compiler is available.
You can even translate everything into native code before shipping it to the device.
Thanks.