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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
