All right, we have our second talk ready for the day.
This is Marcell, this wheeler is going to talk about rust with risk five, which is very
exciting and new topics.
So, yeah, please give it up.
Good morning, folks.
No, I think it's fine.
I'm not wrong.
I'm Marcell, I joined Coat Think in 2024, and I'm a senior software engineer there.
I've right in, I first show you the hardware with the microcontroller I'm using here.
It's actually from a Chinese company, Nanjing, Queen Heng, microelectronics.
Those guys are basically behind the WCH, the Winchip Head brand.
They're founded in 2004, and so this control is a 32-bit channel purpose risk five, microcontroller.
And it has a Queen K, 32-bit risk five.
They call it V2A, processor, which supports a two-level D-pin drop nesting,
and it can run up to 48 megahertz, has 2K SRAM 16K flash.
And the cool thing is it can be run from 3.3 or 5 volts,
so it has a white multi-chranged there, and also supports multiple low power modes,
sleep standby, all that good stuff.
Then it has some peripherals included, like, you see there,
user, d-square-c-s-s-p-i-s of like that.
Some timers, it has up to 18 GP-i-os, they also call it IO ports,
and in the table down here you see what actual port numbers you can get.
Also, it is industrial grade minus 40 to 85 degrees.
And I also checked there are English data sheets available, actually pretty comprehensive.
So from that point of view, also quite good.
Let's have a look at the core that runs in this chip.
It actually implements the RV32 EMC.
Instruction set.
E is an alternative extension for all this, like real chip, low power chips.
And it's almost identical to the regular one, the RV32i,
but it's missing 16 of the general purpose registers.
So that is the big difference that they do that, I guess, for cost-reason.
This extension is still kind of influx.
That's also why official support for it is not fully there.
So you have to, like, on the wrong side, you have to use nightly stuff.
I'm not going to go through more of the details.
There is also an English manual available for the core itself.
This is the hardware, I have here.
They call it an EVT engineering validation test port.
So it has USB-C, just to power it.
And alternatively, in my case here, I actually power it by the debug probe.
Also the schematic's available.
The debug probe is a little USB tunnel that actually it has two modes,
even, it has a so-called RV mode for risk-5, debugging and downloading.
And it alternatively would also support the ARM SWDJ tag mode.
So that's the same probe.
You actually have to run another firmware on it, but it could run in both boats.
For the rust side, you can use a W link.
It's the command line tool in rust that you can run with it.
But of course, much more familiar for the embedded guys.
It's usually used probe RS, which also supports it.
It's the Factor embedded tool kit.
And yeah, it's cheap micros, not the full kit.
With the board on this probe, you can get for like seven and a half bucks on all the express.
This is when you plug in the probe.
So it also has a separate TTIACM-0, so it can do like a separate serial port.
That is kind of can be quite handy when you debugging stuff.
There are also other similar ports available, very cheap.
For example, the 10-star robot stuff.
It's more like a Raspberry Pi pick up things.
10-C-style, or a little bit more advance, for example, the one from Mini2.
That one has actually the UART directly integrated, so you have on the USB-C also the UART.
So how does the embedded tooling look like?
There is this W link, command line tool that allows you to flash firmware,
and basically steps through and look at your target.
Read right the registers, stuff like that.
This is how you install it.
You just call it installed W link.
Then you can list your probes that you have connected.
You can get the status from your chips, stuff like that.
And you can look at the status of basically dump all the registers.
And here you can see the terminal purpose registers X0 to X15, so we only have 16 of them.
Then progress, it's basically the fact to standard.
When you do embedded stuff with RAS node, it's very user friendly.
And yeah, it supports, basically it's direct integration with cargo node,
so you can call it cargo flash.
And if you have it configured, you can basically just run cargo run on your host target,
and it does all that behind the scenes node.
So you install it's called probars tools.
So embedded RAS, there is a RAS embedded device working group.
They basically build an economic and composable ecosystem for us developers
to work on embedded with RAS.
It has basically two important parts are the peripheral access grades,
so that's basically how would you access hardware peripheral registers,
so that is basically the way that is standard nowadays.
It uses machine readable hardware definition,
and that is called system view description, SVD format.
And then there is tooling, it's called SVD to RAS,
that basically automatically converts that then for API,
so you can access your peripherals.
And in the winchy pad case, this is distributed as part of the eclipse,
derived ID, their own ID, it's called Mount River Studio,
and in that ID, when you install that, you then get all this SVD files.
And basically, yeah, we took the SVD files and generated through SVD to RAS,
and you get all that tooling.
And then, of course, there is also the hardware abstraction layer,
so on top of that, you basically define traits
that for common peripheral functionality this way,
you can then really use a high-level drivers
that can depend on that stuff.
So you get interfaces for different peripheral types,
like GPS, time, and spaces, things like that,
that's your hardware has not.
And of course, trying to make sure that those abstractions
are like zero costs, so there isn't much overhead,
and also that it models the differences of certain chips
reasonably well.
Okay, then what does that mean in the WCHCH32v-003 case?
If you want to use that with Rust, there is an embedded hull,
so this hardware abstraction layer available as part of the CH32RS project
that you find that on GitHub.
Actually, I also have all the resources in the slide at the end of the tick.
So that is the same project where also that WCHCH tooling came from.
And like I mentioned earlier, it requires Rust nightly,
the embedded hull stuff, because it uses some features
that are not yet in regular kind of stable.
So that's how you configure that.
And then you also need the sources of standard library
to build some core pieces later on.
Then one thing you need is, do you need the target specification file
for your controller?
Okay, it's this risk-532EC on-down health stuff,
not this is basically not integrated yet.
That is like I mentioned earlier, this kind of simpler variant
of the risk-5 stuff that you can basically force that on your side
with an abstraction JSON file, not.
So here is specify what architecture it is,
and what the data layout is, and all these kind of details.
So one day maybe that in the future that will be basically integrated
and you would not have to manually do that like that, not.
Then you also use a cargo configuration file,
where you then specify that you actually want to use this special target.
So here you point to that JSON, different from before.
And then also here you can tell it when it would run stuff,
that it uses pro-barrass and which chip it's going to use there.
So that's how you link, make the link basically to the hardware again.
Then you have also some dependencies and profile settings in your cargo tomel.
So you basically have to use there, for example, the crate for that core,
not the crinkierty and crinkiest stuff.
Then we use embedded hull, remember that actually got the one O release.
I think some a little bit more than a year ago.
And that's basically that.
And now let's have a look how you can, for example, link an LED.
That's the finally do that.
It uses the delay, how that you can later do, for example, a delay.
So you can blink it in a certain timed way, not.
You also use the cheap IO abstraction.
And of course, as the hardware abstraction layer itself,
you use the CH32 flavor pair of.
And also specified the panning called stuff.
So basically on the microcontroller, you cannot do much more as just halt.
If you would hit some kind of a panic situation not.
Then for the crinkierty core, you basically specify the entry point.
So that your main basically, yeah, is the entry point for the microcontroller, not.
And here you just configure the hardware abstraction layer.
And you assign the peripherals.
And then you can basically specify an output pin.
So the LED is an output pin.
And you can give it the actual port there.
So it's the port D6.
So that will be a particular pin of your microcontroller, not what levels you want.
And then basically you go into your main loop.
That is very bare metal.
And you can do all your work in the main loop there.
In this case, we just toggle the LED.
And we wait another second.
OK.
That would look like when you run it.
Like I said, you can just cargo around and under the hood.
We'll do all that called ProBoris and through the debug probe.
It basically erases the flash, flashes it in and runs it in.
Then the last piece, of course, you don't really want to do that.
Maybe on the command line.
But you want it in a ID.
So let's have a look how one can do that.
For example, with VS code.
Of course, if you want to use VS code for rough development,
you install a few things.
Like for example, the Rostanalyzer and for the embedded stuff.
There is also an extension for the ProBoris debugger.
And then I hit a few more issues, of course.
I'm actually on a Fedora Silver blue.
So this is an atomic distribution node, where you usually run stuff in flat packs.
So it runs in a sandbox environment.
And of course, then you have the problem when you now want to run things like the debug probe.
There is no connection, basically.
The sandbox cannot get to that host tools, not.
How can that be done?
That's basically where the dev containers come in handy.
So VS code has a mode, where you basically can, in the background, spawn a container,
and anything that VS code would do on your host.
It does it basically in that container.
So this way you can have your whole environment.
Basically, for example, in the toolbox container in my case,
I usually use a toolbox container.
You can have that all configured the way to your liking, not,
including the tools that I mentioned earlier,
that you install it all in that toolbox container.
And then in VS code, you can configure that.
You have to configure Docker path and the Docker socket path.
Like I show here in the settings chasin for the Docker path,
I basically use a wrapper script that potman hosting.
And as the socket path, you use the potman socket.
And one thousand there, that's just the user ID.
So should you use another one, you would have to adjust it accordingly.
And then like I said, the wrapper script is just basically calling flatpack spawn.
That's basically the way you can, from the sandbox,
from spawn stuff, not.
And then another piece of the puzzle is, of course,
that the permission that you can actually access,
you reuse be stuff, not from the container.
One way to go about that, usually is, why are the so-called block dev in Linux,
not? So you have to find out in VS code,
when that content runs, what actually user,
it runs as not on the native host site.
And you can do that, for example, by when you're in VS code,
in the terminal there, that runs in that dev container.
You can spawn a sleep thousand, not like I show here.
And then outside, you can have a look with the, with PS,
what number that is using, not.
And then you can, in your Etsy group, just configure that
for the, to give it block dev access, not.
Alternatively, one thing you can do, you can run the whole container
privileged, not.
And the way you can do that is, for the dev container stuff,
also find in, in VS code, in the configuration,
a JSON file for that, not.
And in that, you can, on the bottom, you see that,
you can use privileged and disable all the security label stuff.
I mean, it's kind of a little bit harsh, but that way,
if you have any kind of hardware stuff that you would want to access,
do it that way, you know.
Okay, that's basically it, and I always, at the end,
also show a quick live demo.
In this case, you can maybe see it here.
I have one of these tunnels configured, and it is connected
to such a controller, and it has a little LED, not.
So let's have a look.
I had a VS code, unfortunately, it might be a little bit small,
but on the left side, you basically, in this case,
in, you have the dev container.
So it all, basically, runs now in the background
that dev container, that you also get the output down here.
And I have now, basically, the code here.
I suggest that it actually one can see that it also
something changes.
I changed the delay to 10 seconds.
So right now, the LED is not like perceived blinking,
because it's very slowly blinking, basically.
I change it back to one second, and I can just, in VS code,
hit the wrong button here.
One can see down here that it calls pro bar S,
and basically downloads the stuff.
And we can now see that the LED is blinking in,
like, one second cadence.
OK?
That's basically it.
And we have a few minutes for questions if there are any.
So go ahead.
Thank you.
Any questions?
Can you try for a minute?
Yeah, that's a good question, of course.
On some of the stuff I ran before, we use
something stuff, but I have to admit on this one, I have not tried it.
But yeah, I think it's mainly the space reason.
I have a very basic question, like you're using delay here.
Is the micro control sleeping when you're using delay?
Is it on?
When you use delay, is it sleeping or not?
At a delay, how?
That's a good question.
Yeah?
I think it will probably do, what is it?
The WMI thing here, that will basically sleep, not.
It's not that complicated, not.
That.
The entry point that you have.
Normally, I think I recall that the entry point is from the
Crayed Risk VRT, and you are using something else.
Why is that?
Like the decoration above the main.
Ah, we can go back, sorry.
Which one do you mean?
At the entry point, well, it is basically the reason it's done is that
Embedded hull can maybe do some set-up stuff, and then it will
call your main stuff, you know what I mean?
So the might be some kind of code that runs before, and that's how
we complicated that one.
Oh, that time, I'm not sure, I would have to check.
Why do you need the mic?
Yeah, I think it's because.
Yeah, so that.
Ah, yeah, of course.
Why we use this JSON file for the target?
Yeah.
That's like I explained.
It uses this kind of special.
It's not a RBE32I.
Yeah, I mean, to be honest, I'm not sure.
Maybe it's now in, basically.
It didn't use to be in there.
Like I even mentioned.
Months that is in there, you would not have to do that anymore.
But that is how you can override it, basically.
Okay.
I think that's all the time we have.
Thank you very much.