Feat/split bindings

[leftger]

• Split the bindings into 3 crates:

1. linklayer-bindings: low-level bindings needed for the MAC and BLE crates to properly initialize
2. ble-bindings
3. mac-bindings

• Edited the workflow file to reflect new crate generation
• Added ll_sys_if.rs, linklayer_plat.rs, and mac_sys_if.rs

[leftger]

I had to leave the split crates as scaffolding since packaging the crates requires the version dependency which thereby requires publishing to crates.io (chicken vs egg problem). I'll defer to @xoviat regarding future direction of packaging.

[xoviat]

So I appreciate your work here, and I don't want to waste the effort, however, this is not the direction that I want to go with this crate. I will submit a PR to add changes to the README outlining the principles of this crate:

1. First, there should be a single crate with multiple features for each binding, to reduce release work.
2. Second, the contents of the crate should be exclusively generated bindings. No manual rust code or c2rust code should be present, only rust headers.
3. Third, the crate must be highly configurable, namely, users of the crate should be able to select which libraries to link and which bindings to use independently of each other.
4. Fourth, the crate must be unsafe.

Why these principles? Because the exclusive purpose of this crate is to eliminate the need for users to have a C compiler installed or to download the ST git repository when building downstream crates. In fact, once the bindings are generated correctly (and I believe they mostly are at this point), there should be little need for more releases. In fact most of the work should happen in downstream crates (namely wpan) without the need for a c compiler or sources.

One exception to this principle might be if you wanted to use c2rust to generate rust files, but even then, these rust files would not be included in the crate, but downstream repositories. But you could add a command to generate them to stm32-bindings-gen if you wanted to write logic to accomplish that.

[xoviat]

Now, let discuss linklayer_plat.rs and the other files I discussed. In the C project, they are linked in as part of the user project to allow the libraries to call certain platform functionality (as opposed to passing them in as callbacks). This means that trying to build the mac_ffd.rs example that I added results in undefined symbols from these files. To resolve this, these files should be included in wpan and provide implementations of the functionality for each symbol.

[xoviat]

This is an example of a file that I have already implemented correctly. It provides the same symbols as the C file and has the same structure. This is intentional so that it's easy to compare to the C file and see any mistakes that may have been made. And this is one of the files that I discussed that has not been implemented correctly. The PR to fix this would be submitted to the embassy repository, because this is rust code. And the development would be faster because you would not need to use a C compiler or download the sources.

A note on the scheduler: mac_sys_if is not yet done (it has some placeholder code but that is not correct). However, the UTIL_SEQ_RegTask and other similar statements refer to the ST executor (yes, it is an executor implemented in C). These will need to be translated to provide similar affect to the embassy executor and runners (similar to embassy-net stack runner) will need to be provided. In others words, the ST code will call the function (which will be no_mangle extern "C"), which will execute rust instructions to either suspend or resume the embassy task, which runs mac_baremetal_run. The details need to be worked out here.

Again, sorry about wasting your time on this, and let me know if you have more questions so that you don't misuse your time again.