feature request: add support for StopMode

[smmoosavi]

To have low power mode, we should enter StopMode. Before entering stop mode, we should disable the SYST interrupt, and enable it when exiting stop mode.

We also need to fast-forward the SYSTICK_CNT value to keep it in sync with the real time.

Systick::disable_interrupt();

 // we will wake up every second with RTC interrupt. so we can estimate the number of ticks we miss when we are sleep
let duration = estimate_duration();
Systick::fast_forward(duration);

let mut stop_mode = PWR::stop_mode(&mut scb, &mut rcc, config);
stop_mode.enter(); // program stop here until the RTC interrupt 

Systick::enable_interrupt();

pub fn fast_forward(duration: u32) {
  SYSTICK_CNT.fetch_add(duration, Ordering::AcqRel);
}

pub fn disable_interrupt() {
  Self::systick().disable_interrupt();
}


pub fn enable_interrupt() {
  Self::systick().enable_interrupt();
}

I am not sure where is the best place for these functions to be implemented, SystickBackend or another struct/trait.

[datdenkikniet]

Would it be feasible to implement the Monotonic trait for your RTC instead?

What is the use case that would necessitate something like this? Especially if you're using the SysTick for scheduling, having it stop this way would be rather detrimental to any operations actually relying on it for timekeeping/scheduling purposes.

Adding support for en/disabling the interrupt in the monotonic, and fast-forwarding it seems like a somewhat heavy maintenance burden for a potentially niche use-case.

[smmoosavi]

Would it be feasible to implement the Monotonic trait for your RTC instead?

the RTC is not Monotonic. It only calls interrupt every second to wake us up from deep sleep.

What is the use case that would necessitate something like this?

To decrease power consumption, we have to enter StopMode. We can't accept any interrupt during StopMode including Systic interrupt.

Adding support for en/disabling the interrupt in the monotonic, and fast-forwarding it seems like a somewhat heavy maintenance burden for a potentially niche use-case.

I understand. but with the current implementation of Systick there is no way to implement fast-forward and we have to copy the whole Systick code to our code base. if SYSTICK_CNT becomes accessible from userland, we can implement what we need. Syst instance is accessible via unsafe code.

New feature request

make SYSTICK_CNT accessible from userland

unsafe fn systick_cnt() -> &AtomicU32 {
  &SYSTICK_CNT
}

[korken89]

Hi @smmoosavi,

Thank you for the feature request, we discussed it during today's meeting.
We came to the conclusion that this is not something that is in line with the simple Systick we have today, and we'd like to keep it simple.
However to get the functionality you want feel free to copy it out to your project (or create a crate) and add the desired functionality.

All the best!