Lib.rs

该软件包包含围绕由 riot-sys 暴露的 RIOT 操作系统 C API 的包装器，并尝试提供惯用的 Rust 包装器（例如，为外围设备实现 embedded-hal，为 stdio 实现 fmt::Write）。

软件包文档（rustdoc.etonomy.org）概述了哪些模块可用，以及它们实现了哪些其他软件包的特质。

对于新手的起点，请参阅 RIOT 使用 Rust 的文档。对于基本代码示例，请参阅 RIOT 的示例（名称中包含 "rust" 的示例），以及展示更多包装 API 的 附加示例。

库和运行时组件

riot-wrappers 软件包默认尽量不干预，以启用各种类型的应用程序（即不仅限于 "在 RIOT 上运行的 Rust 应用程序"，还包括 "用 Rust 实现的 RIOT 模块/驱动程序" 或其他）。

为了促进目前最佳探索的使用案例（即 "在 RIOT 上运行的 Rust 应用程序"），应用程序可以使用 main! 宏将常规 Rust 函数（如 fn main() -> ()）包装成一个具有正确名称和签名的函数，以作为 RIOT 中的 main 函数。

当使用它时，也合理地启用 set_panic_handler 特性。它实现了一个将 panic 消息输出到 RIOT 标准输出的 panic 处理器，并将受影响的线程永久休眠。（没有 unwinding 或类似操作；RIOT 中的线程实际上并不期望终止并重新启动）。

有了这样的主函数和panic处理器，Rust crate 可以构建成静态库，并作为 RIOT 构建过程的一部分进行链接，无需应用特定的C代码。RIOT 构建系统自动化链接，Cargo.toml 和 Makefile 中所需的设置示例作为 RIOT 示例目录的一部分提供。

支持的 RIOT 和 Rust 版本

目前，此 crate 面向 RIOT 的最新开发版本。对最新发布的支持以最大努力为基础。

此 crate 没有MSRV，它可能开始依赖于 RIOT 的构建基础设施提供的最新稳定版。

当使用与 riot-sys / riot-wrappers / nightly-compiler 组合不同的 RIOT 发布版时，很可能所有这些都必须一起升级。

就公共API而言，riot-wrappers 力求遵守SemVer保证（有关相关项的例外，已明确记录，例如保留替换已稳定特性的标准库类型 pub use 的权利）。与 riot-sys 不同，此API在 RIOT 的各个版本之间是稳定的。

关于项目存在和模块

此 crate 使某些模块的存在取决于相应的 RIOT 模块是否在构建配置中激活；该信息是通过检查 riotbuild.h 文件 获得的。例如，如果 USEMODULE += saul 在 Makefile 中设置（直接或间接），则 riot_wrappers::saul 才会存在。

这使得事情变得非常自动化，我还不确定这是否是最好的方式。Cargo 的方法是在使用 riot-wrappers 的 crate 中积极启用 riot-wrappers 的一些功能——但是 crate 不能对 RIOT 的模块选择采取行动，因为当它被调用时，RIOT 已经配置好了。RIOT 的方法是在 Makefile 中启用应用程序需要的模块（可能还会通过依赖关系拉入其他模块），但是 crate 不是模块，这使得很难做到这一点。

这种自动化的方式现在很方便；未来的迭代可能会更加明确，并从中受益。

代码约定

在较旧的代码（使用 C2Rust 之前）中，使用了静态内联 RIOT 函数或展开的宏。为了跟踪它们，设置了类似 EXPANDED ${FILE}:${LINE} 的注释（参考 RIOT 提交 6b96f69b 中的行号）。

随着它们被使用 C2Rust 习惯用法替换，结构体版本之间的冲突出现了，通常涉及指针。当它们被转换掉时，它们会通过 inline_cast & co 进行一些检查，或者用 INLINE TRANSMUTE 注释非常困难的情况。

许可证

此 crate 在 MIT 许可证的相同条款下双重许可或 Apache 2.0 许可证，这在嵌入式 Rust 生态系统中很常见。

请注意，此 crate 依赖于 riot-sys，它根据 RIOT 的 LGPL 2.1 许可证进行许可，以反映它使用从 RIOT 翻译的代码。

此 crate 由 Christian Amsüss [email protected] 维护，作为 etonomy 项目的部分，请参阅 https://etonomy.org/，以及 RIOT 团队。