aboutsummaryrefslogtreecommitdiff
path: root/examples/nrf/src/bin/uart_split.rs
diff options
context:
space:
mode:
authorbors[bot] <26634292+bors[bot]@users.noreply.github.com>2022-03-27 17:18:30 +0000
committerGitHub <[email protected]>2022-03-27 17:18:30 +0000
commita211003021dee1cf1035557706e2e55d2c3608c9 (patch)
treed841b2c4d87e851fa2951e3b7039b72c305e1244 /examples/nrf/src/bin/uart_split.rs
parent5c68f0bae7c4091ad34fb2a671e08a614d9beb9a (diff)
parent55a9bf98c56e3a03cdd79e9607fc964e78badf62 (diff)
Merge #678
678: Add minimal F2 family support r=Dirbaio a=Gekkio Here's the bare minimum to support F2 family (207/217/205/215). A lot is missing in RCC (e.g. PLL support), but this is enough to have a working blinky example. The example is set up for a NUCLEO-F207ZG board which I don't have, but I've tested it on my custom board with a F215 and different pinout :sweat_smile: After looking at other RCC implementation, I noticed there's two main API styles: a "low-level" API (e.g. L0) where the `Config` struct has dividers and other low-level "knobs", and a "high-level" API (e.g. F0) where it has desired clock frequencies and the RCC implementation figures out how to achieve them. Which one is preferred? Personally I like the low-level API slightly more, because it gives you the most control and it would be easy to also provide some functions to calculate the required parameters based on desired clock frequencies. F2 has a nasty errata: a delay or DSB instruction must be added after every RCC peripheral clock enable. I've added this workaround to build.rs, but am not sure if this is the best approach. Any comments? I'm planning to add PLL support too once I know which kind of API is preferred. Would you prefer a separate pull request for that, or should I continue working on this one? Co-authored-by: Joonas Javanainen <[email protected]>
Diffstat (limited to 'examples/nrf/src/bin/uart_split.rs')
0 files changed, 0 insertions, 0 deletions