Closed japaric closed 5 years ago
Overall this LGTM, good update!
But I have one small nitpick. In my opinion the QEMU parts are more fit for the book, learning how to simulate an MCU is not the purpose of a quickstart guide. I'd however agree that a link to an emulation section in the book would be useful for those interested.
@japaric Sounds good to me, I like it.
@sekineh hey. I just want to inform you that I'll be adding a section about running bare metal programs with QEMU to the embedded book based on what I've written in this PR. I know you have been working with QEMU recently so I'm letting you know in case you want to, at any time, share with us any cool tricks you have learned or give feedback on the text. I'll be including the exit
syscall stuff you showed me in the revised version of this PR's text.
The latest commit upgrades all the examples to Rust 2018 and moves out the text to the book. See https://github.com/rust-embedded/book/pull/20
Question: Should we remove all the non-essential files from this repository? That is LICENSE-*, the ci directory, etc. Right now these would appear in projects made using cargo-generate
. (To be fair, they also appeared in copies made using cargo-clone
.)
Given that the bulk of the documentation will be in the book; this seems fine to me.
Thoughts?
@japaric +1
I have minified the repo and bumped the dependencies.
Since there's no clear ETA for the beta I would suggest landing this now. The text has been updated to note that the beta is not out yet.
As there's no .travis.yml anymore I have modified the branch protection to not require bors. One of you will still have to approve this PR before it can be merged (just press the green merge button afterwards).
I was going to propose moving to cargo-generate now by having the default values work for the LM3S6965 microcontroller which QEMU supports and also to update the documentation to start out with QEMU but while implementing this it occurred to me that this documentation (see README.md) may be a better fit for the embedded book and should be there instead of here. Which begs the question what should the documentation of this template consist of?
thoughts? ^ @rust-embedded/resources @rust-embedded/cortex-m
Oh, and the rationale for starting with QEMU is that (a) way more people will be able to try it out as it doesn't require hardware; (b) there's less chance of things going wrong because there are no device specific steps, there are no permissions to fiddle with (see OpenOCD on Linux), etc.; and (c) we don't expose new users to so many new concepts at once (cross compiling and debugging vs that plus "what is OpenOCD even doing?", "what is this interface/*.cfg file?", etc). Basically, newcomers will have an easier time all around. The downside is that there would be a new dependency to install: QEMU.