Add new section 'Supporting a new SoC' #99
Conversation
There was a problem hiding this comment.
this is a random passing-by review, i don't have a stake in this but saw it and was positively surprised by it!
one thing i'm wondering: it seems that a lot of HAL activity is now centered around embassy (with the exception of e.g. esp-hal). i'm wondering if this should be explicitly pointed out so that vendors could opt to implement their PACs & HALs directly in embassy rather than having them separate? OTOH embassy is not a WG project, thus this might be the wrong place for this?
This is not required by embassy, and vendors typically prefer to keep their codebases in their own org/repo so they can control access to them, there's no doubts about ownership, etc. Also: maybe ask dirbaio before you start suggesting that everyone shove their code in his project's repo? |
sorry, this wasn't meant as a "hey, everyone should be doing this!" and more as a "is it the idea that this could/should be done?". sorry if that didn't come across like that CC @Dirbaio |
|
This looks great to me, thanks for updating. |
|
Sorry to have lost track — where are we with this? The commits are marked "outdated" but I don't know what that means: Github is hard. I'd be happy to review and merge it if this is the time. |
@BartMassey: the comments are marked outdated because @mbrossard pushed a new commit on top, i.e. the comments are no longer attached to the newest commit. the PR itself is still marked as draft - @mbrossard: if you believe that the PR is ready for review could you please mark it as such? |
|
@rursprung Ah, thanks. I'm used to folks force-pushing amended updates to PRs, which I don't believe does this? |
it does the same (source: i very regularly force-push amended commits to open PRs) |
|
Thanks! |
Suggested flow based on @jamesmunns's guide in Embassy FAQ
|
Based on input from @diondokter, @jamesmunns, @adamgreig, @therealprof, @BartMassey and others at RustWeek Unconference. |
|
|
||
| - A preliminary requirement of this flow is that the Rust toolchain includes | ||
| a [target](https://doc.rust-lang.org/rustc/platform-support.html) that | ||
| matches System-on-Chip (SoC). If this not the case the solution can be as simple as adding a |
There was a problem hiding this comment.
nit:
| matches System-on-Chip (SoC). If this not the case the solution can be as simple as adding a | |
| matches the System-on-Chip (SoC). If this not the case the solution can be as simple as adding a |
| - Ensure that your target is supported by [probe-rs](https://probe.rs). The | ||
| ability to debug using SWD or JTAG is highly beneficial. Support for flashing | ||
| programming can be added with a Flash Algorithm (e.g. from a CMSIS-Pack). | ||
| - Generate Peripheral Access Crates (PACs) from register description files with |
There was a problem hiding this comment.
nit:
| - Generate Peripheral Access Crates (PACs) from register description files with | |
| - Generate Peripheral Access Crates (PACs) from register description files, with |
| - Generate Peripheral Access Crates (PACs) from register description files with | ||
| SVD (System View Description) being the most common and preferred format. | ||
| Alternatives include extracting the register descriptions from PDF datasheets | ||
| or C header files, but this much more labor-intensive. |
There was a problem hiding this comment.
IIRC @thejpster recently mentioned on matrix that this was the more efficient method for him for a project where the SVD files were really horrible. but since this is a suggestion for the chip vendors they can also just fix their SVD files, so it's probably correct to write it like this 🙂
| - Add core functionality in HAL: clocks, timers, interrupts. Verify the | ||
| accuracy of timers and interrupts with external tools like a logic analyzer | ||
| or an oscilloscope. | ||
| - Progressively add drivers for other peripherals (GPIO, I2C, SPI, UART, etc.) |
There was a problem hiding this comment.
would it make sense to mention that at this point they should already make their repo publicly visible and maybe push v0.0.1 to crates.io (to reserve the name) if they haven't done so until then?
No description provided.