Hey badyjoke, there's definitely some resources, lemme give you some notes/opinions:

* If you do it, you'll probably use [bindgen](https://github.com/rust-lang/rust-bindgen), which will generate rust bindings from your C headers. you'll need to build your C code as a static libary, then link that in, usually as a crate. So you might make a `some_c_hal_sys` crate with the raw bindings (static library and bindgen output), and then usually a `some_c_hal` that puts safe Rust wrappers over the raw unsafe C code bindings.
* The steps to make this work are generally:
    * Figure out how to build your C hal as a static library
    * Figure out how to get all the right headers into a single header, feed that into bindgen, get a generated rust file out
    * Make a crate (a "sys" crate) that builds your hal, links it, and includes the header from bindgen
    * start building safe wrappers on top of that "sys" crate.
* However, there are usually some difficulties doing this, particularly:
    * If your C library has "features", or compile time configuration like "enable feature X", or "how many bytes to use as a buffer for X", you'll probably need to recompile it, and it's difficult to expose this in Rust. Most people use environment variables, and have a build-rs script used to control the compilation of the static library
    * Many C concepts don't always map well to safe rust. It might be a challenge to do this in a robust way.
    * Debugging across the C/Rust barrier can be a challenge, if you're not an expert in both C and Rust (and build systems).

In general, in my opinion, I would not recommend this as a first Rust project. It's challenging to get right, and might save less effort than you think. This sort of approach works well in two main categories, in my opinion:

1. Some well isolated library, like a sensor driver or math library, that you can basically call in one place and isn't "spread out" all over your project
2. If you can write it as an isolated "layer", like you write one clean line that handles the C/Rust interaction, then most of your code stays "far away" from that line.

There are definitely times it makes sense to reuse existing C code, but I think the bar is a lot higher than people often think. Having to deal with two languages inside one project adds a continuous level of difficulty, especially if you ever have to debug across the language barrier. The more places your Rust code interacts with your C code, the more likely you are to have "integration bugs".