Comments (13)
Zephyr is another rtos that is getting popular rust support for it would be nice.
from book.
This repo uses freertos-rust to run FreeRTOS tasks written in Rust.
By slightly modifying hardware-specific configs in the repo, I was able to run FreeRTOS on my stm32f407g-disc
board.
from book.
from book.
The main components to getting Rust working with an existing RTOS are, imo:
- building an RTOS as a library: this might be slightly out of scope, but if we assume a reasonably sophisticated audience, we can explain how static libraries are linked in and draw the conceptual relationship between a kernel-as-collection-of-functions (from the view of the Rust code)
- using bindgen to actually generate the Rust bindings: fairly straightforward with one pitfall: inline functions that exist only in header files. getting ChibiOS working required some editing for that reason
- writing a shim to turn C types into types useful to Rust: reasonably straightforward once you understand FFI types
I can get my ChibiOS repo cleaned up (it's rotted quite a bit) if we want something to point to. I've never used FreeRTOS in this way, but there are a few repos out there. I feel like my approach (a more "pure" one that only uses build.rs to build ChibiOS as a static lib, and then bindgen for bindings) is easier to understand than some of the more complicated approaches I've seen elsewhere, but comparisons may be educational.
from book.
* using bindgen to actually generate the Rust bindings: fairly straightforward with one pitfall: inline functions that exist only in header files. getting ChibiOS working required some editing for that reason * writing a shim to turn C types into types useful to Rust: reasonably straightforward once you understand FFI types
A similar issue to the inline functions are the "polymorphic" C APIs which, for reasons of size optimizations, rely on one of macros, inline functions and non-inlined functions to implement any given public APIs, depending on the OS configuration.
If the inline functions are difficult, but solvable, for macros, I would consider them extremely difficult to bind to, without maybe doing some analysis of the RTOS interface sources, before the preprocessor.
OTOH, I am thinking that for such cases, since typically the #define
-s on which the particular choice of "backend implementation" are part of an application specific config files, it might make some sense to investigate generating some wrapper FFIs based on the static APIs and the configuration interface.
Still, I am unsure how we could make sure the Rust caller code of an RTOS API would be identified before the generation of the object files, so Rust bindings can be correctly generated for all the RTOS APIs implemented as macros.
from book.
There is a working RIOT-OS integration library that can become a candidate for inclusion here once it's matured a bit further and gathered some reviews.
Build system integration is interesting there because a typical RIOT application receives quite some configuration in its Makefile, and the RIOT API changes subtly in response to that (additional fields in structs, presence of functions etc).
Static inline functions are a pain point as with other OSes.
from book.
@chrysn I suppose RIOT has similar optimizations and macro abuse as the ones listed by me, right?
from book.
I'd call none of them abuse, but there are some complex areas. Preprocessor functions are not so much used for a polymorphic C API but more for triggering various other optimizations (many of which, in my impression, would be moot if LTO were universally implemented, but AFAIR some of the targeted compilers can't do that), eg. around the conversion of times to ticks.
On the other hand, most workarounds I do are for static inline
functions that are classic one-liners, either accessing a global variable or handing right off to a different function (eg. mutex_lock and mutex_trylock call to _mutex_lock with an additional boolean block parameter).
from book.
To clarify, by "polymorphic API" I mean something similar to what you said, the API signature will look the same, but it is possible the types are defined differently, some function calls might be turned into function-like macros or inline functions.
All of these are problematic for any bindgen-like tool and have to be taken into account.
from book.
rttrust is a [still incomplete] attempt to realize rust bindings for the rt-thread RTOS.
from book.
I have just started playing with doing this on top of Zephyr. Basics of building aren't too difficult, so I started with log. There is a bit of a semantic mismatch between rust's logging and Zephyr's logging system, mostly because the Zephyr one is built around C-style format strings.
from book.
In regards to Zephyr, this project looks really promising: https://github.com/tylerwhall/zephyr-rust
from book.
Could you also consider ThreadX for the book, please?
Thanks a lot for all your work.
from book.
Related Issues (20)
- Issue with Macbook Pro M1 HOT 1
- any plan on supporting microbit board? HOT 2
- Adding a small explanations on hardware exceptions vs software exceptions
- Segmentation fault HOT 1
- zsh: no such file or directory: gdb
- Apple Silicon can't install gdb, lldb instructions needed? HOT 2
- I think this repository can support more languages HOT 21
- How would one cite this book in an academic resource? HOT 5
- Where can I find the definition of the set_timer_1hz function?
- GDB blocks after running the continue command in 2.2-hardware HOT 1
- Doens't Work Verification OPENOCD
- Concurrency / Atomic access section contains factual errors HOT 6
- Discuss the usage of the `log` crate HOT 2
- Mention the critical-section crate?
- Memory-mapped Registers: does `W` give read access to the register?
- Interoperability: On the availability of `std::ffi` and `std::os::raw` in `core` HOT 1
- linking failed when using own svd2rust library
- Is there a procedure required to translate the repository into another language? HOT 11
- Links to other resources HOT 2
- Tooling page is significantly outdated HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from book.