<story><title>Asynchronous Rust on Cortex-M microcontrollers</title><url>https://interrupt.memfault.com/blog/embedded-async-rust</url></story><parent_chain><item><author>tadfisher</author><text>There&amp;#x27;s also the simplicity of bare embedded in Rust, because you can mostly[1] use Cargo, depend on the right embedded_hal crates for your target, and be up and running with a hardware-backed async runtime and everything. Zephyr, Tock, Mynewt, etc. all have bespoke build&amp;#x2F;deployment systems and driver ecosystems. That said, RTOS makes actually deploying working products much more realizable, so pick your poison.&lt;p&gt;1: I think you still need xargo&amp;#x2F;cargo-xbuild for no-std embedded sysroots, but there may have been some upstream development on that front since I last played in this sandbox.</text></item><item><author>jvanderbot</author><text>I could be wrong, but isn&amp;#x27;t every multi-task &amp;#x2F; RTOS essentially supporting this? Wake up, check flags, do work if required.&lt;p&gt;Of course if you&amp;#x27;re bare-metal programming, it might be nice to have a lightweight mechanism for this.</text></item></parent_chain><comment><author>the__alchemist</author><text>Embedded-HAL is interesting to me - in principle it&amp;#x27;s a great concept; writing hardware-agnostic, portable code.&lt;p&gt;I don&amp;#x27;t use it in my firmwares because:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  - All of the embedded-HAL libs I&amp;#x27;ve found (eg drivers) have had notable limitations or ergonomics problems.
  - It appears unsuitable for use with DMA, which I use for all runtime IO
  - The APIs tend to be a mess due to heavy use of typestates&lt;/code&gt;&lt;/pre&gt;</text></comment>
<story><title>Asynchronous Rust on Cortex-M microcontrollers</title><url>https://interrupt.memfault.com/blog/embedded-async-rust</url></story><parent_chain><item><author>tadfisher</author><text>There&amp;#x27;s also the simplicity of bare embedded in Rust, because you can mostly[1] use Cargo, depend on the right embedded_hal crates for your target, and be up and running with a hardware-backed async runtime and everything. Zephyr, Tock, Mynewt, etc. all have bespoke build&amp;#x2F;deployment systems and driver ecosystems. That said, RTOS makes actually deploying working products much more realizable, so pick your poison.&lt;p&gt;1: I think you still need xargo&amp;#x2F;cargo-xbuild for no-std embedded sysroots, but there may have been some upstream development on that front since I last played in this sandbox.</text></item><item><author>jvanderbot</author><text>I could be wrong, but isn&amp;#x27;t every multi-task &amp;#x2F; RTOS essentially supporting this? Wake up, check flags, do work if required.&lt;p&gt;Of course if you&amp;#x27;re bare-metal programming, it might be nice to have a lightweight mechanism for this.</text></item></parent_chain><comment><author>junon</author><text>Building core&amp;#x2F;std&amp;#x2F;whatever using unstable flags and --target works for me these days. I can do everything with cargo and make it even more ergonomic with a toolchain file.&lt;p&gt;Now if Cargo had a way of producing multiple variants of the same project (e.g. different --targets with pre-set features) just with `cargo build` then things would be a lot better.&lt;p&gt;As of now, a Makefile is still needed to bring it all together.</text></comment>