Skip to content
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

RP time driver alternatively using mtimer, timer0, timer1, or aot #3873

Open
wants to merge 11 commits into
base: main
Choose a base branch
from
5 changes: 5 additions & 0 deletions embassy-rp/Cargo.toml
Original file line number Diff line number Diff line change
Expand Up @@ -28,6 +28,11 @@ features = ["defmt", "unstable-pac", "time-driver", "rp2040"]
default = [ "rt" ]
## Enable the rt feature of [`rp-pac`](https://docs.rs/rp-pac). This brings in the [`cortex-m-rt`](https://docs.rs/cortex-m-rt) crate, which adds startup code and minimal runtime initialization.
rt = [ "rp-pac/rt" ]
## these settimngs are currently necessary to allow the pipeline build. They should be removed ghere when the features will be (somehow) selectable in the "embassy-executor" or the "embassy-time" section
time-driver-timer1 = []
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you add documentation for the features? Use ## just like the existing comments.

Copy link
Author

@mschnell1 mschnell1 Feb 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did the modification in the toml file not as a suggestion but just to allow the pipeline to do the build.
Supposedly, in the end these features should not be allowed in the project, but in the embassy-time dependency section. But I have no idea how this should be done.

time-driver-aot = []
time-driver-mtime = []
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Cargo features would make more sense if we did the following changes

  • Remove the time-driver feature. Instead, the time driver is automatically enabled if any of the time-driver-* features is enabled.
    • To do this you could rename the time-driver feature to _time-driver so that it's "private", and make the time-driver-* features enable it.
  • Add a time-driver-timer0 feature instead of making it the default if no other time driver is enabled.

To make examples compile you'll have to edit their Cargo.toml.
Also, please add to ci.sh lines that test compiling embassy-rp with the 4 different time drivers, so CI checks they all compile.

Copy link
Author

@mschnell1 mschnell1 Feb 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK. As I am not at all experienced in doing cargo instructions, I think it would be good if you could do the decisions and the (suggestions for) implementation.

My idea was as such:

  • if there is "integrated-timers" in the embassy-executor section, the time driver is used.
  • if there are no additional instructions in the embassy-time section :
    • if its a RP2040, the #[cfgs use the "TIMER" (already in place)
    • if its a RP235x, the #[cfgs use the RISC V System timer in pac::SIO (currently in place: TIMER0.)
  • if there is a feature "time-driver-timer0", "time-driver-timer1", or "time-driver-aot" in the embassy-time section, the #[cfgs use the appropriate timer: TIMER0, TIMER1, or the timer in pac::POWMAN.
  • if the feature "time-driver-aot" is given in the embassy-time section, the feature "tick-hz-1_000" is automatically set to prohibit any ambiguity (while otherwise the feature "tick-hz-1_000_000" is set (as it seemingly is right now, as trying a different setting when "integrated-timers" is enabled fails to compile.

Can such be implemented ?
Or is some other implementation (with no "default" setting) more appropriate ?

I suggest the RISK V system timer as a default, as

  • We don't want to break RP2040 projects that do use just "integrated-timers" and want it to default to "TIMER".
  • it's provided exactly for this "system" purpose by the hardware design.
  • the user might want to use the more versatile timers "0" and "1" for dedicated purposes
  • it counts 64 bits, the alarm checks all 64 bits. Hence no 32 Bit / 72 hours considerations necessary.
  • I feel the RISK V system timer is slightly more "secure" as the interrupt simply is managed by the alarm register content and stays active until same is lower than the count register. No additional conditions.
  • The RISK V system timer is in the "Secure SIO" . This might be advantageous - and works with the examples, but it also might be a problem in certain situations ?!?!?!

BTW: the tick generator is set up for driving TIMER0 with 1_000_000 Hz in embassy-rp-0.3.1/src/clocks.rs:529 ff. This seems not appropriate when TIMER0 is not used. Maybe it makes sense just to set just the constants appropriately so that clocks::clk_ref_freq() can be used in the timer driver to configure the appropriate clock to drive the timer to be enabled (as shown in the suggested driver code ).



## Enable [defmt support](https://docs.rs/defmt) and enables `defmt` debug-log messages and formatting in embassy drivers.
defmt = ["dep:defmt", "embassy-usb-driver/defmt", "embassy-hal-internal/defmt"]
Expand Down
Loading