All right. Hello. Hello, everybody. Welcome to the last talk before the
last talk of today. My name is Heather Crespo. I'm from Spain. I work at a company called
the Silver Botics. We designed monitoring devices, remote ones and devices, so low power
usually solar panel and so on, and we designed like from the prototype in phase to mass manufacturing
or at least series of 50-100-200 devices. Today I want to talk about the project in particular,
in which a customer required us to build our new design for the meter, which is a device that
tracks monitors like pollution, and for the first time we decided to use rust for the field work.
So it was for us, it was a big decision because this has to work, this has to work,
and it has to work not only for the prototypes, but for the devices that are deployed
in the middle of nowhere, basically. So, yeah, first of all, a disclaimer, this doesn't intend to
be a deep dive into into rust. There was a dev room for that, there were great talks about
rust and embedded rust this morning, and this afternoon, but the talk is about looking back at the
project and asking the questions, was it the right decision, should we do it again or not?
So, yeah, well, first of all, a few words about like pollution, why is that important?
Our customer was the European Space Agency and the Liberates Space Foundation,
so obviously the may-re some was for astronomy, I don't think it needs any more explanation,
why is that important? But like pollution is also important for, it has any impact in many other
areas such as public health, it has an impact on ecology. There are great resources online trying
to correlate the bird migration routes and the sources of artificial light. And in fact,
our customers today, they are looking into using our device for doing that. It has an impact
on cultural identity and so many other consequences. From the technical point of view to measure
like pollution, pretty much all you need is a photo diode and there are several ways to interface
that with your microcontroller. The one on the left is the one that most of the devices we're
using when we started the project is a chip from AMS that converts the current the output of the photo
diode to frequency-encoded pulses and then you just account edges for giving amount of time.
And the one on the right is the version that we're using now. It's a new chip.
We think, of course, the interface, it has a couple of channels, you can configure interrupts,
you can configure the integration time. But in the end, it's the same. It's a photo diode,
but a bit more powerful. And yeah, I want to, this is really important, the escrow is the interface,
because the project from the system at the same point of view pretty much what you need is an
escrow is the interface and then some kind of connectivity to send the data to the internet.
In our case, that was Wi-Fi. So, for this project, we needed it was Wi-Fi and let's go see.
So, yeah, choosing Rust was not like a big decision of this will never work. It was, yeah,
yes. So, yeah, why Rust? Well, there are many, many language features that are
interesting and relevant for embedded devices. I chose actually this three from the
official website. I'm going to go quickly through them. The first one is the static analysis,
the powerful static analysis, and what happens there, but yeah. So, what that means,
since can define a GPIO, a GPIO is tracked and then depending on whether it's an input or it's
configure an input or as an output, you have access to different functions. So, what does it mean?
For instance, if you declare a GPIO at compilation time, if it is an input, you can only read it,
if it is an output, you can only set it. And yeah, at compilation time, thanks to this is called
the type state pattern. So, no runtime cost, and I think this is really, really powerful.
The problem is when you are trying to understand, if you are new to the language limit,
and you are trying to understand all those, that's really simple, but you can imagine that the
hull of any other, any other crate is much more complex, but it's really powerful.
Memory allocation also really flexible on Rust. You have core Rust, and then you have STD.
So, if you don't want to use dynamic memory allocation, or you have to use to type this,
no STD attribute on top of your main file for instance, and then instead of having access to
defining a declaring a vector on the heap, you have to use some different allocator,
for instance, the heapless allocator, that will have a similar functionality, a heapless vector,
instead of using the heap it will use the stack, or any other custom allocator.
And yeah, concurrency is also really safe in Rust, because of the ownership rules.
To this piece of code from our project, we have to sum to stress one of them is
for sampling the data, and the other one is for networking, because when we use cellular
communications, we want to bring up the modem while we are sampling, so everything is ready
when the data comes out, and of course we share some data between those threads,
and with Rust with the ownership rules, you cannot mess it up. You will not incur into
the data risk conditions. For embedded devices, what you would probably benefit from is in case
of handling interrupts, so it is the same, it is a context switch, and thanks to the same rules,
you cannot incur into the data risk conditions. But for me, so for me the killer feature is not
the language, which it is great, but for me the killer feature is the tooling. Rust includes
cargo, which is a package manager, and it pretty much handles all the project life cycle.
So if you want to build the project, you just do cargo build, no more make files or see make files
all around the project nested, and it is a device placed on the source file, and for most of the
cases of course, and it will compile and build everything together, cargo run, if you want to run
the binary or if you want to flash it to your board, it has support for testing, so if you do the
cargo test, and there are tests into your code, you don't have to, you don't need any other
tool that includes any testing integration testing examples, testing everything, and the most
one of the, well for me, the best feature is the package manager, so this is similar to PIPI,
you can type in your console, cargo are the name of a library or a upgrade, that's called the
code, and you have access to see the realization of data, parsing, logs in a more efficient way,
parsing a bit fields, everything. For embedded systems, that's really important,
because you can do stuff like cargo art and the name of a driver, and this is because the
there is some official working group for embedded devices, and they have been working for,
I don't know how many years, in trying to standardize the interfaces, so everyone pretty
much of the community has agreed with them and is following their advice, and most of the
drivers are compatible with this embedded hull, so that means that if you add a VME, and you have
a compatible hull, which I think it's all of them, do you just have access to a lot of drivers
for free? It would work something like this, you instantiate the S4C bus, you configure it,
and then you type into your terminal cargo, a VME to 80, and then you have access to a
japan instantiate VME to 80 driver, and you pass it the S4C bus, and then you all have to do
this fetch the data. If now you want to another sensor, that's an accelerometer, cargo art the
name of this driver, and yeah, then it's the same, you declare the driver with the S4C bus, and you fetch
the data. So that's all the code, instead of having to, what I would do before is go to get
have at a fruit, find the driver, clone the project, try to compile everything together, here is
just, this is all the work we have to do. This is great, but I mean we all know this comic, so
I guess for embedded developers, modern tools, main modern problems, but we have to live with that,
it's the price to pay, yes. So yeah, the conclusion about this entire rest thing is that the
community is really strong, it's really active, it's really cohesive, so that's really, really good.
The tooling is great, compared to what we had before, as embedded developers,
well, there are some other good tools out there. The documentation is, I mean, I don't like to
write documentation myself, so I'm going to complain about it. And for me, the biggest problem
is the lack of official vendor support. Maybe not for me as a developer, but for the adoption
of a white part of the industry, there are only a few players, so they're expressive and I think
if you know something that really, that are really supporting rest.
Yeah, so about the device itself, the device that we have designed, it has three, well,
it's this is small, this is the device, it has three sensors,
while the BME for a temperature pressure and humidity inside the box,
obviously the delay sensor, which is the one I showed in the first slide,
and then we have an accelerometer to measure to measure pointing.
The main MCU is on USB 32C3, from expressive, they have official support for rest, they have
four, five, six people working full-time on these tools. In fact, they have two different versions,
one with STD and another one with STD. We use STD because it's pretty much a
proper of the USB IDF, and that's really stable, it's really, I mean, everyone uses that and it works.
If you want to use no STD, which you might, that might be the future, and that's what they
are working on, but at this moment, we're using STD. Then we designed two expansion boards,
so the main board with the sensor on the USB 32 communicates through UART and 80 commands to
send you our modem with 2G WiFi and even an GUT, and another expansion board with
support for LERA1. Again, UART and 80 commands. Then we have some extra features for
backtones and so on, but many things. This is the flow diagram, so when the device wakes up,
the first thing it does is take a sample, sampling takes roughly one minute, because you have to
especially for the light, you have to take a lot of measurements, and then you want to
obtain the mean and you have the standard deviation, the same with the temperature, but not so
often, so you want to meet it, and that's why we have two threads, one for sampling and another
one for networking. Then we put the data into a buffer, if the buffer is full,
if there's enough battery we connect to a network and send the data, and finally, depending on
whether it's day or night, and something that you can note because of the GPS location,
and the timestamp, you go to sleep either for five minutes or for the entire day.
But from this slide, what I want you to observe is the all the steps that I put into into the
red boxes, those are external grades, so all the job that we have to do is cargo out,
for instance, they are night, it's just a bunch of equations that you you enter Wikipedia and
do it, but in this case, there's a grade for that, so you just do cargo, cargo out,
sun rays, and that's it, but you have to do it since we integrate that into your code.
The same for the mode and drivers, for the sensors, I mean, well, all we have to do,
some of them, we build the drivers and publish them openly as a different grade, but you know what I mean?
Well, our power consumption, it is a tricky, this is one for cycle at night,
you have to take into account that the device is power on 20% to 25% of the time, so every five minutes,
we take a sample and sampling takes one minute, one point, something minutes,
and then we depending also on how often we want to send the data, we have a buffer, we send the data
every thing or samples, this would be the power consumption, and now we focus on that's one of
the sampling, but no networking steps, this is the power consumption of the sampling thread,
so if you check down here, it's 10, 9.3, and finally, well, sampling and sending the data,
as you can imagine, when you turn on the modem, it's like, this is for cellular, I think,
so once you turn on the modem, it's really, I really high power consumption,
and some of the results, on the top, you can see the battery graph, the battery,
dear in the night, it drains 10%, so if you don't have access to the sound or if the solar panel
is not connected, the battery would last around 10 to 12 days, in the middle you have the temperature
graph of this particular device, this was dear in winter, so it goes from positive 28 to negative 8,
dear in the summer, it goes up to positive 50, 60 degrees, and well, I mean, the light,
you can really analyze the data with the computer and do something much more interesting,
but with just by having a look, you can see that the sensor overflows, you can detect
for instance at the bottom right corner, and that's the move starting to come out.
Actually, well, here I, this is taking from Mr. Laryon, that's the position of the move,
and I don't know if you can see it in the top right corner, just by having a look at the data,
as you can detect how the, how there is a peak of light moving from the beginning of the night
to the end of the night. Yes, so I mean, in the end, it was a really successful project,
the devices are deployed, the Canary Islands, in Madaya, in Greece, there are some devices,
there are some, they are fetching data like every day, there are, we, every night, there are,
I don't know, but we have probably hundreds of megabytes of data of all these devices,
and so far, rest has been a nice adventure. So yeah, that was it. Thank you very much,
thanks to our partners, thanks to the President for organizing that, and yeah, that's it, thanks.
Hi, when you say that the Expressive Support Rust, you mean that it's a binding, or they are
literally held in a real time, when you said that the Expressive Support Rust, you mean a binding,
or is there a real time operating system within a Rust? Yes, so they have two options, they
one with, with, with support for SD, that sub-rupper of the USB IDF, so under it could see,
it is three articles, and they have implemented the post-excompliance, so that's why you,
here you can see, this SDD thread is found something that's actually a free artist task,
okay, so you're actually binding to the C++, right? In that case, yeah, but then they have the
Windows 3 version, which doesn't have any, any articles, and it is I think, so you would have to
use an Icing executor, such as Embesley or any other executor. Okay, but, but it doesn't have a
scheduler from the Ertos, no, the, the bear one, the bear knows the version doesn't have any
any escalator. Thank you. Okay, so I, just a sort of, coming, I saw you monitoring the
battery voltage, and I've also done some work with Rust, with a battery-pad device, and I see
it, like, you're, you're getting up to, you have, sort of, charging Icing, and you have, like, 4.2 volts,
depending on the day. I, you, you worried about that sort of killing the batteries quite quickly,
if you had any issues with that, that we chose to limit the battery voltage to 4 volts,
particularly when it is really hot during the day, we had read very fast degradation on
battery cells, and the voltage was right up to 4.2, but I don't know if you'd seen any issues
with that. Well, I mean, we didn't have that issue, so far, and we have not of this particular
device, but for the devices, we have, I guess, 1,000 devices charging up to 100%. And I guess,
because they are, they are always in the same pretty much full, full region. We don't have any,
we have degradation issues, but not something that we can, we have to change the batteries every
few months, it's, it's, it's okay. Think of presentation, how one question do you use any
interrupts in your Rust code? No. Because one of the pain points is just borrow checker getting into
middle of sharing anything. Yeah, yeah, yeah, I mean, it's the same as using threads,
but yeah, it's, it's one of the things that is difficult to understand if you're new to Rust,
and the compiler is really, really hard on getting it right, but you have to trust the compiler,
it will work. I mean, all you have to do, I don't know much about Rust, but all I have to
default the compiler instructions and I end up to something which compiles and it works, I don't know.
Oh, yes, I have a question about testing. Yeah, like you mentioned,
I've got a test, which is like, unit testing is pretty good and like Rust on, on desktop
devices, but how is it on embedded, like, do you have any idea of how you run tests?
Yeah, that's a good question. I was actually trying to find it out the day before, the day before
yesterday, because apparently there is no, if you find it, so if you go to, to get lab, you call
the project and you do a cargo test, it will try to compile everything and flush it to your board
and run it into your board, so you would need to specify a different target in your cargo
tunnel, but because that's not possible, but what people is doing is creating another work space,
which doesn't have dependencies on the hardware itself, so let's say you have a hull and the hardware
code and only the main logic has access to a target which is not the main MCU. So that's something
that is not easy to, to be done in the, in this kind of, of applications, at least at the moment.
Thanks for the talk. Quick question about the development time. Can you share a little bit
on about how much changing to Rust impacted the project? Can you say something with comparison
of previous projects? I don't think this is a fair comparison in this project, because I mean,
the project is, this one is really simple, it's, as I said, it's Wi-Fi and as
course we could do this with micro Python, with Arduino, with whatever, so this is not a fair comparison.
In Arduino, this would be, I don't know, a few weeks, if we want to do something safe and reliable,
I, in Rust, it took, in two weeks, we didn't have the, we didn't understand the language itself,
so we started from zero, we started from zero, so it took probably two months or something,
but yeah, the customer was, was okay in the Rust Foundation, so thanks to the Rust Foundation.
Yeah, hi, thank you for the talk. Our question is about hardware abstract abstraction, sorry,
yep, in the hypothesis of a new hardware version, what would,