-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Book: Section 3B: Portability #6
Comments
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: A graphical representation that basically says:
|
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, |
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. |
Closing this in favor of #65 |
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
The text was updated successfully, but these errors were encountered: