Quad Timer PWM?

[speelbarrow]

According to the various documentation I've read for the Teensy 4.1, the board appears to have certain pins that are capable of PWM using the 'Quad Timer'. I can't seem to find a way to access this functionality through this crate or any of the re-exported crates (imxrt-hal, imxrt-ral, imxrt-rt, embedded-hal, etc.). Is this just unimplemented in Rust at this point?

[mciantyre]

There's no quad timer driver available in imxrt-hal, and imxrt-iomuxc doesn't know which pins can be used with quad timers. Nevertheless, imxrt-ral exposes the registers and peripheral instances; they're available in the tmr module. This could be the foundation for a quad timer driver.

[speelbarrow]

Thanks for the info! I'm poking around with directly accessing those instances, but I'm having trouble moving the quad timer instances out of the board::instances() result. Or rather, I can move the instance out just fine, but I'd ideally like to move it out in such a way that I can still use the result of board::instances() to run board::t41. See below for a code snippet that explains what I mean better.

let mut instances = board::instances();
let tmr2 = instances.TMR2;

let resources = board::t41(instances); /* ERROR: use of partially moved value */

Any ideas for a workaround? Thanks!
- N

[mciantyre]

The easiest workaround is to unsafely re-fabricate the timer instance(s) after giving all the resources to the BSP:

use bsp::ral;

let mut instances = board::instances();
let resources = board::t41(instances);

// Safety: the BSP doesn't use any quad timer instance.
// Since the BSP discards these instances, it's OK for us
// to re-create and use them.
let tmr2 = unsafe { ral::tmr::TMR2::instance() };

This doesn't require us to coordinate. But, if a future contributor adds quad timer support to the BSP, the safety caveat may no longer hold.

---

Another approach, one needing our coordination, is to add the quad timer instances as board resources. #140 shows how we've done this for FlexIO instances. This would allow us to write something like

let mut instances = board::instances();
let resources = board::t41(instances); // <-- Extend resources to hold quad timers.

let tmr2 = resources.tmr2;

This gets rid of the unsafety, and it establishes that the BSP can do something with the quad timers. The BSP tends to wrap timers in their HAL drivers, but I'm OK with not doing that here; we can treat it as a category 2 resource.

---

A final, extreme approach: adopt the BSP's clock and power policy, but ignore the board functions that configure resources. You'll use the HAL to allocate all your own drivers. #146 talks about this.