My apologies if this is not the correct place to put this issue. I couldn't find a better one.
I am looking into creating a new board crate, but am also a relative newbie to the ARM architecture. As a result, I am having to learn a lot about how the ARM ecosystem itself works.
For example, the chip I'm looking at comes with an SDK, which is good enough if you are looking at their chip and writing one project in C. But in Rust, we want to look further than just one project on one chip, in addition to being a different language.
As a result, I had to figure out that the SDK was really a version of CMSIS-RTOS with patches on top -- and that CMSIS was something ARM built for OEMs to make their SDKs, CMSIS-RTOS being a now-unsupported variant thereof. That gave me an approach to figuring out what was new, and what was already taken care of by the cortex-rt crate.
There is an explanation of ARM's hardware designations and features, and how they map to Rust targets. I feel it would help others to have a similar section for software artifacts: a high-level overview of C code that ARM gave to OEMs to write their SDKs, what is handled already by equivalent libraries in the Rust ecosystem, and what kinds of things board crate writers should look for as they do a port to Rust from that source code.
My apologies if this is not the correct place to put this issue. I couldn't find a better one.
I am looking into creating a new board crate, but am also a relative newbie to the ARM architecture. As a result, I am having to learn a lot about how the ARM ecosystem itself works.
For example, the chip I'm looking at comes with an SDK, which is good enough if you are looking at their chip and writing one project in C. But in Rust, we want to look further than just one project on one chip, in addition to being a different language.
As a result, I had to figure out that the SDK was really a version of CMSIS-RTOS with patches on top -- and that CMSIS was something ARM built for OEMs to make their SDKs, CMSIS-RTOS being a now-unsupported variant thereof. That gave me an approach to figuring out what was new, and what was already taken care of by the
cortex-rtcrate.There is an explanation of ARM's hardware designations and features, and how they map to Rust targets. I feel it would help others to have a similar section for software artifacts: a high-level overview of C code that ARM gave to OEMs to write their SDKs, what is handled already by equivalent libraries in the Rust ecosystem, and what kinds of things board crate writers should look for as they do a port to Rust from that source code.