embedded-hal VS rust-cpp

What is the difference between this and https://github.com/rust-embedded/embedded-hal/tree/master/embedded-hal-async?

Maybe worth mentioning if you (or someone else) hasn't seen it before, the embedded-wg is also working on an async version of the embedded-hal traits, embedded-hal-async.

In that case you want to keep most of the unsafe in the HAL crate, and expose an interface as safe as possible. To give you an idea, is it since 2018 that a "generic" DMA safe implementation is in discussion https://github.com/rust-embedded/embedded-hal/issues/37

Does something like embedded hal exist in the C/C++ world? ( https://github.com/rust-embedded/embedded-hal )

worth mentioning also is embedded-hal but my understanding is this has absolutely nothing to do with arduino, so despite being embedded probably not what I want.

The ecosystem is great and growing, It really benefits from a language-standard embedded HAL which makes writing cross-platform drivers a cinch - e.g., you can write a bit-banged MDIO driver and use it on anything that has a timer and a two IO pins, from a Zynq Ultrascale to an arduino. Sure, this is possible in C - but Rust really benefits from a less fragmented ecosystem here.

Have you thought about writing/contributing to embedded-hal compatible crates (a sensor module driver for example)? It's always good to contribute to an eco system.

📝 At the time of writing this post, it came to my attention that there is an additional HAL that targets STM32 device families (the stm32-hal). From what I figure, right now there seem to be two approaches for developing HALs. The first approach is trait driven so to speak where the embedded-hal is used as a foundation. The second approach is more application-driven and provides a high-level API that targets several families of a device. However, this exists only for the stm32 through the stm32-hal. Right now, the first approach is what I found to be more widespread as it covers different microcontrollers and what this post is based on.

I can write a library for an OLED device that is driven by an platform agnostic I2C device that will run on any microcontroller that implements the necessary abstractions.

The `embedded-hal` (https://github.com/rust-embedded/embedded-hal) are these abstractions that allow this to happen

Yes but there needs to be appropriate libraries available such as HAL. Well it doesn't have to but it makes my life as a beginner in both much easier. But its probably matter of time because i predict that this chip will be very popular in Rust embedded.

I am the current passive maintainer of the cpp crate: https://github.com/mystor/rust-cpp

I would like to utilize OMPL's functionality in Rust code, so I want to call into OMPL C++ code somehow in Rust. I've seen two (non-mutually-exclusive) options so far: - rust-cpp, which allows you to write C++ code in Rust within the cpp!() macro. - cxx, which allows you to define both sides of the FFI boundary manually (as opposed to bindgen's automatic generation).

There's also the cpp and cxx crates for doing C++/Rust interop, but they probably aren't appropriate to use in all cases. The C ABI is definitely the safest way to go unless you're really trying to marry Rust and C++ code bases, not just writing library bindings.

https://github.com/mystor/rust-cpp <- not a transpiler, but almost as good

Otherwise, C would never have achieved success in MS-DOS when all the stuff it was binding to at the time required blocks of inline assembly. (Crates like rust-cpp do exist, which allow "inline C++" in the same way that C++ allows inline assembly.)

Actually, you can make inline C++ macro in Rust. Similar unholy monstrosities exist for inline python, inline C, inline SQL, inline HTML,...

Here is a more serious project that allows to embed C++ code directly in your Rust code: https://github.com/mystor/rust-cpp

Don't underestimate the power of procedural macros: https://github.com/mystor/rust-cpp

Alright, thanks for all your ideas! I also found this mystor/rust-cpp, which apparently allows inline c++ as opposed to cxx. Having yet to try out any of these, I like the idea of inline code more. Thought now I feel I need to brush up my skills a bit more to try this stuff out.