Rust Programming Language Oxidize Global 2020, 16 Oct 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: probe-rs: Your Embedded Tome

Description

Ever wanted to know how the magic spell you always used to program that mystery ELF file onto your embedded target works? I did so in February 2019. This is the story of probe-rs, your magic spellbook to talk to embedded targets.

Close to a decade now, I have been working with embedded systems. While complaining about subpar tooling was always an option, stepping up and making better tooling somehow seemed impossible. One year ago, having no prior knowledge of this matter, I started to look into how debug probes and the debug interface of ARM cores works and how prior tooling, approaches this.

Today, we have a working library to interact with ARM and RISC-V targets. Of course we are not done yet. There is a plethora of embedded targets, bugs arise everyday and there is way more awesome functionality and tooling we want to provide.

This talk is the story probe-rs, giving you a little bit of the why, the how, the good and the bad and why you should use it and contribute to it.

A

Hello, everyone and welcome to the last talk of the day and it's a special highlight because I'm really glad to introduce noah husser who's, one of the authors of probe arrest really a cornerstone of the embedded ecosystem in ross. I'm so glad that he's going to talk about that as the final talk of the day. Thank you.

B

So good evening, everybody, I hope you enjoyed the great day of oxidize with a lot of interesting talks and have some energy left to spare. For my top pro bars, your embedded tome so very short introduction. My name is noah husser, better known as elteki on the internet.

B

I'm a twist software engineer and I work at my own tech, consultancy, technocrat, we're doing all sorts of electronics and software so from power, electronics to server backends, and we try to use rust as much as possible. More and more and in my spare time I like doing all sorts of sports such as jiu-jitsu, which I especially like.

B

So let me talk a little bit about embedded development. So when doing embedded development, I guess most of you have used some tools um I have listed here. So there's lots of probes and on-chip debugging tools that can talk to those probes and your target and you use them to flash an elf binary to your target or to get debug information from your target.

B

So this sounds great at first and it is great sometimes that you have such a huge selection of tools from which you can choose, but there's drawbacks and drawbacks, of course, so the ecosystem is very stiff, so oftentimes you don't really get to choose each tool but they're a chain of tools that you have to use and many vendors ship their own toolset, such as eclipse, which then is gdp based again and they all add their own flavor and you're kind of stuck with those tools and in the last seven years I've been doing embedded development.

B

I have always been using those tools and for every project it was a different tool and you always have to relearn stuff and even in the open source community, some tools require conflicts. You don't really understand it. It was always kind of magic to me and then in 2019, shortly before the first oxidized, where I met a lot of folks that actually contribute now to probe rs. um I started looking into those things, because I was kind of disappointed with how the setup went, because in rust we have those great tools, such as cargo.

B

For example, that really make development, nice and easy- and I think, embedded development should be fun too. So we have many cool tools with a lot of features, but they're not really nice to use, and we tried to change that so in the traditional debug setup, you have a target here at the bottom.

B

That is a cpu of a different architecture than your host at the top, where you write code on and those two can't really speak with each other. So you need a debug probe here in the middle that translates sort of on the protocol that the target cpu uses- and this is mostly swd or jtag- and this is a standardized interface which is different for each architectures sure some share a common interface, but this is basically defined by the architecture and it is well documented too, and then on the host side.

B

The debug probe mostly uses a proprietary interface. There is some standards defined by arm, but not everybody uses them and it's really tricky to get this right, because not all debug probes use the same level of abstraction. So some are higher level interfaces and some are lower level interfaces. So this is kind of a tricky point to get this run and of course we have been writing rost software on the target in the form of firmware for a long time and now, with probe rs.

B

We have also implemented those interfaces um in ros2, uh swd and jtag and, of course, the host site interface to talk with the probe and of course you have written a lot of software that is running on the host, so so this is rust2 and the only missing piece really is the probe, which is still proprietary so and on the host. Of course, there is a whole stack of applications. I have listed them a few slides earlier that you normally use.

B

So traditionally you have a target here at the bottom again and then in the middle. You have a debugger in the form of gdp, mostly at least for open source embedded development, but many manufacturers actually ship ship it inside their their eclipse, based distribution or the likes, and then you have a ui on top.

B

Traditionally, I know it's from eclipse, but uh many folks nowadays, for example, use vs code of course, um such as you would know it from normal x64 development, but in between those three components you have on one side the gdp stop, which is the gdp server, and it basically translates the gtp commands, such as read memory, write memory, etc to commands the target understands and yields the data back.

B

So so this is sort of the probe driver right and every probe manufacturer ships, their own flavor of gdd stuff. So you always have. The interface is always similar, but, for example, I'm flashing a target. This is not always the same for each and every target, and the same is on the other side. You have the gdbmi the machine interface, which sort of provides a machine, readable interface to the gdp ui that, for example, an editor can use to actually interface the debugger.

B

But then again the the editor needs another plugin which speaks this machine interface. So you get all these different interfaces and this sort of layer cake which can be unstable at times.

B

So what we are aiming for is eliminating all those interfaces that can cause friction and provide one single block in the middle here named as server and also marked with a rust symbol, because we already have written that in rust, um which is sort of the missing link between the ui and the target, because um many editors nowadays provide at least some sort of ui to debug um and there's also standardized interfaces to implement this.

B

So this simplifies the entire chain and should remove a lot of problems.

B

So here are some of the probe rs benefits that we can get or that we try to to achieve. So, as I said, we want to have an editor of our choice. For me, this would be ideally vs code and we try to make um pro bars as a library such that you can use it um or that you can just put a thin layer of ui on top or a little server such that it can interact with your own tools.

B

So you don't have to write any weird script or something, but you have a clean, rust api and we try to document this properly. It's not always the case yet and what's very important to is that it is streamlined. So, for example, in open ocd you have for different architectures.

B

You have different commands to read memory, for example, and we try to not make this different, because the user is mostly interested in executing a command on the core, for example, read memory and this this is always the same from a user perspective right, so the user shouldn't be forced into using different commands and learning different interfaces, but they should just need to to do a memory read right, um yeah so and for our binary tools and also library usage.

B

We strive for a simple setup and usage, of course, uh such that you that the user can really go developing and not just setting up tools right for all eternity, um we're trying to use uh standard protocols or de facto standards um from microsoft and arm mostly and we're trying to be as rust, friendly as possible. So we're providing cargo plug-ins, but pro bars should really be language agnostic in its core.

B

So the library can be interfaced with ffi, of course, in other languages um and all the cargo plug-ins could be used as standalone applications too, and if we ever have some time to spare. We will of course make this even better by maybe not naming it cargo flash, but rather just flash or whatever the tools.

B

Name then is, and we try to actively encourage contribution um by having the library on github such that we really motivate people to contribute to the project, and I try to be as active as possible on matrix2, where we have our chat room so that we can exchange ideas that not one person just defines the entire interface such that really. All ideas can be combined in this one. Great library.

B

So I've talked a bit about what probe rs can do and what it should be if possible.

B

But now let me show you please how simple it really is. So let me make a small example, so let us have this imaginary program that just increases a counter at the memory location in ram. Then, let's flash that program then reset and hold the cpu to get it into a known state. Then we set the breakpoint after the counter or at the memory location in flash where the counter will be incremented, then we wait for the cpu to halt.

B

Read the counter, and we repeat the last two points such that we can see the counter incrementing uh or the counter is incrementing on the target and we can see it on the host.

B

So, first of all we are acquiring a session. um This is just a struct that holds a handle to our probe internally and a handle to our more specific target description. In this case, this is the nrf52 um yeah. So then we're flashing, the elf binary onto our target.

B

We just do this by handing the session to the function, the elf path and a form it. We could also use, uh bind pure binary format or intel hex here. So we support all three. So this is. This is really convenient uh normal magic to that, and then um we get a core handle in this case core zero, because there's just one core on the nrf52 and we reset and hold the core.

B

And then we can already set the breakpoint at this imaginary location in flash where the code resides um after the counter has been increased and then we run the core um because yeah it's halted at the moment. um We wait for the core to be halted again because it will hold once the breakpoint is hit right and then we will read one 32-bit words at the location in ram where the counter resides.

B

So this is really simple and easy and as you can see, we have control over the entire cpu. So this is really neat, because now we have a library which enables us to create any any sort of magic tool that can let us inspect and inspect our cpu talk to it. Flash and heal finally etc. So this is really cool a little bit about how the probe r structure works. I won't go into too much details, but just to give you an overview um how this all conceptually works.

B

So we tried to have the structure as close as possible to how this actually physically works uh in in, like a probe and core sense, so on the lowest level in the probe, rs space, so to say, and we have the probe drivers, so we provide a trait that is used by the probe struct internally, that implementers of a probe can implement so for the chaining, for the sd-link and for the cmc stuff.

B

We already provide this, but if you were to manufacture your own probe, you could implement a driver for your probe just by implementing this trade. So this should be really easy and all the internals use uh this trademark and then on the next level. We we have a core. It works. Basically, the same. We have a trade that you would implement for each and every different architecture.

B

So at the moment we have our v6 rmv7.

B

um I guess rmb8 is to come soon and then we have risk v and maybe someone is to implement avr in the future, for example, and this is really just implementing a trade more or less, and then we have the target descriptions which are sort of uh a better or a more uh in detailed description of all the targets.

B

There are, for example, the nrf52 840, which describes the target memory, locations and sizes and their flash algorithms a little bit more about that in a second and then uh at the top level we have the session struct. We have seen in the code example two. It just holds a reference, the probe and the target description, and it holds core state sort of internally and you can get a handle to a core by pulling the session for the core handle, and then you can control the core from that.

B

So the session is just really a top level uh entry um entry struct, um which manages all state, and then this is basically probe rs, and on top of that we can build third party libraries, for example, probe rsrt, um a gtp stop or our flashing tools. Of course, the flashing tools are inside probe rs because they're commonly used uh very often, but it's really just building on the layers below, and on top of that we can build applications, for example, cargo, flash cargo embeds or our vs code plugin.

B

So oftentimes people ask me: is this already in cargo flash um or cargo embed, or they if they issue an issue over there in the repost? But all the functionality is really in probe rs. So if we add a new target or new functionality in general, this will always be in probe rs. So if you install the newest tool and it uses the newest version of pro virus, you get all this functionality. So so this is really cool, so it really doesn't depend on the application.

B

So the application is a very thin ui layer that basically just parses arguments and passes them to pro bars, and so I've spoken a little bit about those flash algorithms.

B

So those are um elf blobs that we flash onto the target that are into ram that manage the flashing process um and this would be huge work and also describing all the memory properties of the different targets.

B

We couldn't do all that work, I think- or at least it would take years or many many many work hours.

B

This is where cm6 packs come in handy. So this is an arm standard um for target descriptions, so these cm cmss packs contain all the flash algorithms, the target descriptions and they're implemented by the vendors of the targets. So that means we don't get to do any work and we still get thousands of available targets and many of those targets are to be included soon. uh Yeah. We can just export them, so this is really really great that this was done by arm.

B

So I've talked a little bit about how everything looks like and what it should be optimally. So at the moment we have a few binary tools and we have this library, that's working great actually, but of course we can always extend the tool set so what's planned. Next, of course, is the vs code. Plugin, so we have a working plugin, but it's very early alpha state and it uses the microsoft app.

B

This is a modern json api for debugger interfaces, and this is implemented in in vim and emacs 2, for example, and I'm sure it will get into other editors soon too. Just like the language server protocol has been implemented by many too, and this means we get rid of the entire gtb stack in between. Of course, this means a little bit more work because we have to implement all the debugging things ourselves, but there's cool rust projects coming up that do this already.

B

So maybe we can tap into that and as of now, I think we can. We can print the stack trace. We can look at the stack frame very rudimentary just point to values.

B

We can run step and halts and maybe even set breakpoints. I'm not entirely sure how far that is, and you can check it out on github- have a look. Try. It out contribute codes, it's going to be cool and then the next thing uh I have been discussing on the probe rs channel just a minute before the talk um with brian cantrell and uh adam greek, uh two um we're trying to get itm uh into master uh after this weekend, so we're trying to implement this during the input days.

B

So for those of you who don't know what itm is, this is really really powerful data streaming on arm, v7 and rmd8, and it enables you to track uh interrupt events and memory access events uh which then are streamed out in a uart kinda interface, and you can also send custom binary data. So this is really cool for uh tracing your target in real time, because this doesn't use any cpu cycles or additional ct cycles. So this is around the corner and there's an open pull request and there's lots of features coming.

B

I won't go through them for time reasons, but you can find it in the presentation. If you scroll down, I will publish that later on so now uh for a short demo, because I guess most of you um I mean sure the library is cool to use, but most of you are interested in flashing, a target or actually debugging a target right. So we provide two cool binary tools for that and the first one is cargo flash.

B

So I'm here inside the nordic, dev kits repository and just to show you the structure, it's just a normal uh rust project and um yeah we can uh normally we can. We could do cargo cargo run um and then dash dash release and an example blinky- and this of course I'm sorry.

B

This of course, won't work because we're not having the right target architecture, we also don't have sdg, etc, but what we can do is use our in-place replacement, so we just replace run with flash and we add our chip um at the end, this is the nrf 52 840, and then we can flash the blinky onto the dev kit. I have here with me. I I think we can't really see it well, but it shouldn't blink. Yet, oh the camera. Even does a nice job, so it should flash, and now it should blink.

B

So this is really simple. We have a clean interface and there's a lot of comfort flags which we can configure the entire process and, of course, always putting all those flags onto the command line is not really nice, especially when you want to configure the probe or the speed or you want to have rtt working or a gdp server.

B

So we provide a second tool called cargo embed, and this is sort of the big brother of cargo flash that can also do rtt things etc, and it really um doesn't need any more arguments, because there is this embed tumble here at the top, which has all those configurations stored and yeah. So um when we run this command, um let's, for example, I have to put an example, of course, rtp.

B

It should flash the example onto the board and open this rtt console, so we can't really see any output yet, but if we switch to tab two, we can see uh what it tells us um that we can type on channel one and it will return it to us. So we can type, for example, um hello, oops, oxygen.

B

And it will return just in caps, so this is really communication from the host to the target and it should be really convenient and we will only expand, only expand those tools even more in the coming weeks and months, so they should really provide a nice development experience so uh to hop back into the slides.

B

So I've been talking about this debug chain uh at the beginning of my talk and the only missing piece here is really the piece in between so the probe, um which has not been done in ross, but a few folks from the pro bars team, uh namely corkin. This awesome and adam greek have been really hard at work and we have this uh little debug probe here which operates um fully with rust, firmware and it implements the cms's dab, debug, spec and yeah. So we have the last missing piece in ros2.

B

uh The probe is extremely fast and very little and it implements this standard api. So you can also use it with commercial tools such as arm keil, for example, and it can stream all the things you would need, such as dab itm and your data, and you can find it on corkin's github.

B

The firmware repository has been kept a secret. It will be open sourced on the pro bars workspace soon and if you want a probe, um just join the probe rs metrics channel, we will see that we can get sort of dev kits out in the next few days. uh We will have to set up some kind of supply chain. So if you want one uh join there, I will make an announcement, so you can all uh join them yeah. So this was it for my talk. I hope uh you enjoyed it.

B

um You can find us uh on several places on the internet, our web page, the github organization, the matrix channel, where we talk a lot or mostly me, spamming and then, of course, hit us with your questions and talk. Reports uh you're very welcome to report any box and, of course, prs are even more welcome um yeah. So I guess this was it for my talk uh yeah. If there are any questions, I think I can answer them now. I think we have a few minutes left, not sure.

A

Yes, there are a couple of questions and a couple of discussions already got going on in the channel, and the first question is: when would you want to use rtt verses atm.

B

Okay, so rtt is platform independent. The only requirement is really that um the core has the capability to. Let you read memory over the debug interface while it is running so this is really just two ring buffers in in the ram of the core which the host and the core access with some safety locks, of course, and they put data and read data from uh to and from it. So this is platform independent, so you could use it on avr technically on on arm or on riskview, and also on arm v6, which misses itm.

B

The itm is very proprietary, so to say it's only on v7 and v8, but what's cool about ikea is that it has those additional um tools for streaming out uh core events such as interrupts or um memory reads and writes, which would use up cpu cycles. If you were to do this manually over rtt, um so to say so. This is really cool. If you don't want to intrude your firmware, but this is a one-way connection. um You can only stream data from the target to your host in rtt.

B

You get both ways so yeah those are kind of the differences. Thank you. I hope this answers. The question.

A

I guess so um and then there's one other question uh with oklahoma city and a small cargo config cargo run works as a spec as expected. Is there a way to do something similar with cargo flash cargo embed? So basically, cargo run. Does everything.

B

Yeah, um I know of a few folks that do this. um You can make this happen. It shouldn't be a problem. um You can configure cargo flash as your runner. I think, if not come to the probe rs channel, we can figure out the solution, I'm sure, because it is possible to use those tools standalone at least cargo flash cargo embed misses the flag, I think, but in cargo flash you can point it to a specific elf binary, so that works.

B

B