diff options
| author | bors[bot] <26634292+bors[bot]@users.noreply.github.com> | 2023-05-09 21:56:43 +0000 |
|---|---|---|
| committer | GitHub <[email protected]> | 2023-05-09 21:56:43 +0000 |
| commit | e179e7cf85810f0aa7ef8027d8d48f6d21f64dac (patch) | |
| tree | 153a70e9123bbbd876f3a4b08659181d83ccec89 /tests | |
| parent | 856b944eaf20bbd5f1625226415af210a28af89a (diff) | |
| parent | 9d971e5b150e2ebe51570040ea59e3ccdbef7b17 (diff) | |
Merge #1436
1436: rp: Clock configuration r=CBJamo a=CBJamo
Draft of a more complete clock config for the 2040.
I also extended and made public the clk_<name>_freq functions. I know at least the ws2812 pio example would like to get the sys clock at runtime rather than just using a constant. I suspect most pio-based peripherals will want access to the clocks.
Open questions:
1. Best way to handle the 3 external clock frequencies. I think the XIN (aka crystal) freq should just be set by the init function then never changed, though if it's an external clock that could change? I'm not sure anyone would ever want to do that but maybe it should be handled just in case? The other two should probably be set by the application.
2. Better estimation of ROSC frequency. Right now it's really just a lookup table of the speed from the single sample I did this testing on, and only uses the frequency range and div, drive strength is ignored.
3. Probably some kind of warning should be generated if the random bit from the rosc won't be useful, not sure how to do that.
4. Should clocks only be allowed to be configured at init, or should they be modifiable at runtime? For example, switching the RTC to a clock in pin when a pps source is available.
Bonus feature to support clock output. I only implemented the bare minimum, and only for gpout0. I'm sure there's a clean way with macros to impl all 4 without just copy/paste, but I haven't learned macros yet.
Co-authored-by: Caleb Jamison <[email protected]>
Diffstat (limited to 'tests')
0 files changed, 0 insertions, 0 deletions
