RTIC v2.0.0 support

[kyp44]

Hi, I'm new here. I'm working on a game targeting the PyGamer, which has a nice BSP here. Being a game, using async Rust is extremely valuable for me, and information on using async on SAMD processors seems to be very scare. It doesn't seem like Embassy supports SAMD processors at all, but RTIC v2 now uses async for software tasks, whereas v1 did not.

The HAL crate here does support RTIC (via the rtic feature), but it only seems to support RTIC v1 by implementing the old Monotonic trait. Things have changed with v2 and now there is a different Monotonic trait that has to be implemented, which involves some async functions.

The current paradigm for RTIC v2 is to select the time driver from the rtic_monotonics crate, in which the type that implements Monotonic is created using macros instead of passing it to the app RTIC macro as before. Looking at the code for the supported microcontrollers (noting that SAMD is not among them), it seems like Monotonic is most easily implemented indirectly by instead implementing the simpler TimerQueueBackend trait, which does not involve any async methods.

I think I have enough embedded experience to implement an RTC-based driver for RTIC v2. Given that the v1 driver was implemented in this HAL instead of within the RTIC project, I wanted to solicit opinions on whether a new v2 driver should also just live with the HAL here (including relevant macros), or by adding SAMD support to the RTIC project? Thoughts?

NOTE: I am aware that I can already use RTIC v2 on SAMD chips using the SysTick driver that ships with RTIC, but I want a more efficient driver that does not generate frequent, periodic interrupts.

[jbeaurivage]

Hi @kyp44 and welcome!

Ideally the implementation would live in this crate. By all means, feel free to open up a PR with a RTIC v2 monotonic implementation. I've actually been meaning to do it too, just haven't found the time yet - I'd be happy to assist you with that.

By the way, if you're looking for async support on more peripherals: I've been working on adding async APIs to the HAL. The PR is pretty much complete at this point, it just hasn't gotten merged yet. Having some extra hands testing it out would absolutely help with getting it over the finish line.

[kyp44]

@jbeaurivage I appreciate the response!

While I have never used RTIC v1, my impression is that the Monotonic driver was a critical component in that you couldn't even use RTIC without one (if I'm wrong about that please let me know!). In v2, however, the new Monotonic is created by the user (via a macro) and seems to only provide global (note that the methods are all associated functions) access to async delay functions. In that sense it seems to be completely optional and you wouldn't really need one if you did not need any async delays. I imagine that you probably also need a driver if you want to have periodic hardware tasks as well, though these aren't really discussed in the RTIC book.

I do need async delays for my application, but looking at the async methods you've implemented for TimerFuture, I could probably get away with just using these. However this would be less ergonmic than having a global delay provider as I would have to pass peripheral or TimerFuture objects around for safety reasons.

So I think I still would like to try to implement the global TimerQueueBackend driver, and I agree that it should just live in this HAL. It can be implemented along side the old Monotonic driver so that Rtc can be used with RTIC v1 and v2.

I'll fork and start working on this right away, and I'm happy to have you help or at least have another set of eyes on my implementation. I'm also happy to help you test your async HAL extensions, though I only have a PyGamer in terms of ATSAMD hardware so I may be limited in what I can test.

[jbeaurivage]

No problem! Yeah having a global monotonic is entirely optional on v2.
Regarding testing the async APIs, just the pygamer is fine, I've done extensive testing on a D21 target. Testing on a SAMx5x chip would likely give us the confidence that it's virtually bug-free and useable.

[jbeaurivage]

@kyp44 By the way, do reach out on Matrix if you haven't already: https://matrix.to/#/#atsamd-rs:matrix.org

[Sympatron]

Most rtic-monotonic implementations for other platforms live in rtic-monotonics. So that is where I would look for reference.