Rust for embedded development: Where we are and what's missing


#125

Hi, I just started to look into Rust for embedded development to develop industrial IoT solutions with our own, STM32 Coretex-M3 based hardware.

So basically all I need is some binding from Rust to existing C code. I would then step by step replace some of the C code with Rust implementations.
We are using FreeRTOS and I’m interested in keeping it as an underlying RTOS and provide Rust bindings for it. FreeRTOS is pretty stable ans supports many platforms. I would develop such bindings open source.

I’m not very far yet, I just compiled some lines of Rust but did not tested it on my hardware. It’s still pretty complicated to set everything up.IMHO the community needs some more tutorials to get started with embedded Rust development.

I like to stay in contact with you and like your ambitions to improve the embedded Rust development.


#127

It seems to me most of us in embedded require an effective (fast and visual) edit-debug cycle. An editor with breakpoints and simple single stepping would fit the bill. I’d guess 80% would name this a requirement (not just in embedded).

Add live watches (and the ability to graph some variables) and that percentage goes up to 90%, 95% if one adds assembly level debugging. Anything more is niche territory.


#128

Would VSCode with this extension fit your bill?


#129

No, unfortunately from what I gather, this is for Raspberry Pi and up. Most embedded tasks involve ARM M0 MCU’s (to be replaced by RISC-V), without an OS, debugged through OpenOCD. This is all I found: https://stackoverflow.com/questions/36287351/how-to-setup-lldb-with-openocd-and-jtag-board

Would be fantastic to have this working. Some eyecandy too :slight_smile:


#130

If I install LLDB in VSCode, will it replace the default MS Rust debugging?

Note that Rust + Windows installations often go wrong on me, so I am weary of trying invasive things like debuggers.


#131

In my experience, connecting to gdb-server works better like this.

No, they will coexist side-by-side. For each launch configuration you may choose which debugger type to use.
Windows port of lldb is rough around the edges, but remote debugging might be one of the better working pieces actually.


#132

In my experience, connecting to gdb-server works better like this.

Are you suggesting to use GBD with OpenOCD remotely? I am just speculating here. Note that I have zero experience with setting up this stuff.


#133

I meant that you could use LLDB as a client to OpenOCD’s debug server stub.

Ugm, so I just tried that, and it didn’t work because of some protocol-level incompatibility. Looks like LLDB will need to be patched…

You could try one of VSCode extensions that are based on GDB. However, you won’t get visualizations, and I don’t think any of them support assembly-level debugging.


#134

Thanks for trying! I’d love to use LLDB.


#135

This problem is now fixed in LLDB master. I’ve published a new Windows build.


#136

Wow Vadim, I didn’t expect this.

I installed the download and installed Python 3.5 afterwards. Sadly it did not find the MSBuild tools. No desktop icon too. Later on I’ll try the configuration you gave, to see if anything works despite the error, because MSBuild definitely is present and Rust Windows programs compile and run normally. Stay tuned.


#137

Which step produced this error?
Note that the installation package actually contains LLVM+Clang+LLDB, just because that’s how LLVM project is set up, but you only care about the LLDB part. I am guessing that Clang might have been the one looking for MSBuild tools, so you can ignore that.


#138

The error occurs in a CMD.exe window showing:

Installing MSVC integration…
Failed to find MSBuild toolsets directory.
MSVC integration install failed.
Press any key to continue. . .

This occurs while executing step “C:\Program Files\LLVM/tools/msbuild/install.bat”, which seems to be the absolute last step.

How and to what do I connect (https://github.com/vadimcn/vscode-lldb/blob/master/MANUAL.md#remote-debugging)?

Absolute newbie here when it comes to GDB/LLDB/remote debugging (and I might include VSCode up to a degree).


#139

Set up your launch configuration as if connecting to gdbserver, but give it the port that OpenOCD is listening on.
If you have more questions please ask on gitter.


#140

I would like to use the Blue Gecko Dev Kit for profiling energy consumption while using Rust. However, I cannot seem to find out any information on how whether Blue Gecko Dev Kit supports Rust or vice versa and whether the IDE “Simplicity” supports the Rust toolchain. Some information on this would be nice. Some information on using Rust for other embedded arm platforms would be nice. I would like to develop a rust framework for a few arm cortex boards I’m designing. However, the process that I should follow in how to integrate rust into a project like this is not clear to me.


#141

I have gone briefly through the thread and I don’t think anyone has mentioned getting information about the stack usage at compile time. I think something in the line of gcc’s -fstack-usage would come handy for MCU developers.

For example (not mine): https://stackoverflow.com/questions/38929524/how-to-measure-a-functions-stack-usage-in-rust


#142

Even something like -fstack-usage is only a rough guide. It won’t include ISR stack usage.

Another technique I’ve used is to initialize from the current stack pointer to the end/beginning of the stack with some value like 0xEE and then later after a while scan from the end of the stack looking for the first non 0xEE

With the above scheme its still possible to overflow the stack and not detect anything ,expecially if a large unused buffer happens to straddle the end of the stack.

But if you don’t overflow the stack then you can get a sense for your worst case stack usage for a particular run.


#143

Yes indeed, but this technique only works at runtime, I had the feeling the rust compiler could provide more insight into this problem at compilation time. A stack usage on a by-function basis (vs with recursive usage based on call-graph) would probably already help.


[SOLVED] AVR support not working in avr-rust (xargo?)
#144

I am in desperate need of a good tutorial on writing a linker script and registry def files that may serve as a good example/template for developing in Rust on a few other embedded architectures. Most of these tutorials won’t go into detail on how to build a linker script which seems like the most important part when getting Rust working on other embedded architectures. Perhaps a few more tutorials on this might allow others to help out in getting other architectures up and running with Rust.


#145

Could Philipp Oppermann’s “Writing an OS in Rust” be of any use to you? It starts with a guided tour on how to build a bare bones OS kernel on x86, including how to set up a complete xargo + compiler + linker toolchain, and it feels like many parts of it could be adapted to other hardware architectures.

For example, the use of GNU ld means that the existing literature on linker scripts for embedded software in C can be largely reused.