Book: Section 3B: Portability

[japaric]

From @jamesmunns on July 10, 2018 9:34

How can use of Rust improve portability between Projects, Targets, or even Operating Systems?

Copied from original issue: rust-embedded/wg#119

[japaric]

From @TotalKrill on July 30, 2018 9:26

I would really like to see some more graphical representation on how the different crates are thought to interact with the software, also some recommended guidelines for naming the crates so they are more easily found on crates.io. Example:
device crates should end with *-device, and board crates should end with *-board, driver crates should end with *-driver.

A graphical representation that basically says:

• Device crate = MCU registers, peripherals, settings, timers etc
• Board crate = Where SPI, UART etc are hooked up, what oscillators are running. ( are drivers a part of the board crate?)

Similar to this picture:

[jamesmunns]

I addressed this topic briefly in my RustConf talk. I will at least dump all of my written notes in this section today.

https://ferrous-systems.github.io/rustconf-james-2018/#/58

I also attempted to cover why this is desirable, e.g. when you have N chips and M drivers, N*M is a much larger number than N+M implementations

[TotalKrill]

Any attempt of trying to visualize this for me is a victory, it would help a lot for me to understand the scope of the embedded-hal traits. What i feel now is that embedded-hal traits are the arrows connecting everything.

Should board crates have the drivers? since the components are probably on the board. Just trying to show what should be replaced and what does not need to be replaced when porting hardware would be nice.

It would also feel easier for a new rust dev like me to understand the scope and roles of different crates and how to navigate the future huge embedded rust ecosystem.

[japaric]

Closing this in favor of #65