28e61ceaec
Fix the matrix.to link so that the room history can be viewed in "Matrix-Static" by users who aren't registered on Matrix (e.g. for previewing). Hopefully this will also get the room content into search engines. n.b. The new matrix.to URL uses the room name instead of the room ID, because the ID didn't work with Matrix-Static, and the matrix.to README at: https://github.com/matrix-org/matrix.to says... "Note that linking to rooms by ID should only be used for rooms to which the target user has been invited: these links cannot be assumed to work for all visitors." |
||
|---|---|---|
| .cargo | ||
| .github | ||
| book | ||
| ci | ||
| examples | ||
| heterogeneous | ||
| homogeneous | ||
| macros | ||
| src | ||
| tests | ||
| ui/single | ||
| .gitignore | ||
| .travis.yml | ||
| build.rs | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| CNAME | ||
| CONTRIBUTING.md | ||
| LICENSE-APACHE | ||
| LICENSE-CC-BY-SA | ||
| LICENSE-MIT | ||
| README.md | ||
| redirect.html | ||
Real Time For the Masses
A concurrency framework for building real time systems.
Features
-
Tasks as the unit of concurrency 1. Tasks can be event triggered (fired in response to asynchronous stimuli) or spawned by the application on demand.
-
Message passing between tasks. Specifically, messages can be passed to software tasks at spawn time.
-
A timer queue 2. Software tasks can be scheduled to run at some time in the future. This feature can be used to implement periodic tasks.
-
Support for prioritization of tasks and, thus, preemptive multitasking.
-
Efficient and data race free memory sharing through fine grained priority based critical sections 1.
-
Deadlock free execution guaranteed at compile time. This is an stronger guarantee than what's provided by the standard
Mutexabstraction.
-
Minimal scheduling overhead. The task scheduler has minimal software footprint; the hardware does the bulk of the scheduling.
-
Highly efficient memory usage: All the tasks share a single call stack and there's no hard dependency on a dynamic memory allocator.
-
All Cortex-M devices are fully supported.
-
This task model is amenable to known WCET (Worst Case Execution Time) analysis and scheduling analysis techniques. (Though we haven't yet developed Rust friendly tooling for that.)
Requirements
-
Rust 1.36.0+
-
Applications must be written using the 2018 edition.
User documentation
API reference
Chat
Join us and talk about RTFM in the Matrix room.
Contributing
New features and big changes should go through the RFC process in the dedicated RFC repository.
Acknowledgments
This crate is based on the RTFM language created by the Embedded Systems group at Luleå University of Technology, led by Prof. Per Lindgren.
References
License
All source code (including code snippets) is licensed under either of
- Apache License, Version 2.0 (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)
at your option.
The written prose contained within the book is licensed under the terms of the Creative Commons CC-BY-SA v4.0 license (LICENSE-CC-BY-SA or https://creativecommons.org/licenses/by-sa/4.0/legalcode).
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be licensed as above, without any additional terms or conditions.
-
Eriksson, J., Häggström, F., Aittamaa, S., Kruglyak, A., & Lindgren, P. (2013, June). Real-time for the masses, step 1: Programming API and static priority SRP kernel primitives. In Industrial Embedded Systems (SIES), 2013 8th IEEE International Symposium on (pp. 110-113). IEEE. ↩︎
-
Lindgren, P., Fresk, E., Lindner, M., Lindner, A., Pereira, D., & Pinho, L. M. (2016). Abstract timers and their implementation onto the arm cortex-m family of mcus. ACM SIGBED Review, 13(1), 48-53. ↩︎