Re: [riot-devel] How to properly use cortexm_sleep

[Kees Bakker]

Thanks

On 29-05-19 13:02, Robert Hartung wrote:

Hey everyone,

let me say a few words as Kaspar and I have been driving the
implementation of this. In general there is no need to manually go to
sleep, as the deepest sleep mode will always be selected from the idle
thread depending on the deepest mode possible.
Which mode is possible depends on the used periphs. For STM32 sleep was
long not possible, as PM_BLOCKER_INITIAL was initialized with 1 for each
mode, which resulted in never going to a sleep mode.
 From what I can see is that it is still initialized with ones?
Nevertheless, to make us of it PM_BLOCKER_INITIAL should be initialized
with 0. All periph modules should then individually block the sleep
modes they can not operate in. For now the biggest problem was the
shell/uart, as it would always block any sleep modes.
An exception are some platforms, as they have a Uart which can wake them
up from sleep modes.

I have modified the atmega1284p implementation to make use of it [0] and
[1].

Best Regards
Robert

[0]
https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega1284p/periph/pm.c
[1]
https://github.com/ibr-cm/RIOT/blob/idealvolting-rc1/cpu/atmega_common/periph/

On 28.05.19 20:01, Kees Bakker wrote:

Nice,

Thanks for sharing

On 28-05-19 08:48, Oleg Artamonov wrote:

Hi.

Yes, but for emergency reboots only.

Implementations:

https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/stm32_common/periph/iwdg.c
and
https://github.com/unwireddevices/RIOT/blob/loralan-public/cpu/nrf5x_common/periph/iwdg.c

For task scheduling on sleepy devices we use RTC-based timers with 1

ms resolution and 1 week max period
(https://github.com/unwireddevices/RIOT/tree/loralan-public/sys/rtctimers-millis;
on STM32L, we use regular HW RTC with SSR register, on nRF52 —
"software" RTC implemented on top of HW RTT unit).

--

/Sincerely yours,/
/Oleg Artamonov/
/+7 (916) 631-34-90/
/www.unwds.com/ <http://www.unwireddevices.com>

27.05.2019, 21:57, "Kees Bakker" <k...@sodaq.com>:

     Hey Oleg,

     Are you using the watchdog?

On 27-05-19 07:30, Oleg Artamonov wrote:

         Hi

We do. On STM32L0, STM32L1, nRF52, etc. Checking for interrupt flags is absolutely useless here - 1)

         WFI checks for any relevant interrupt flags, 2) interrupt
         still can happen between check and WFI.

--

         /Sincerely yours,/
         /Oleg Artamonov/
         /+7 (916) 631-34-90/
         /www.unwds.com/ <http://www.unwireddevices.com/>

26.05.2019, 18:40, "Kees Bakker" <k...@sodaq.com>

         <mailto:k...@sodaq.com>:

             Hey

             Is there anyone using cortexm_sleep for a real
             application? And if
             yes, would you want to share how exactly that's done?

             Let me say that I've never written a real application with
             RIOT, but
             I would like to. One of the important requirements is that
             the app
             must be in sleep (deep sleep) and only wake up to do some
             work.
             And another requirement is to use the watchdog.

             That said, I'm familiar with the following Arduino pseudo
             code.

                  while (forever) {
                      do stuff

                      disable interrupts
                      if !certain condition
                          __WFI();
                      enable interrupts
                  }

             That "certain condition" is mostly checking that no WDT or
             RTC interrupt
             occurred before disabling the interrupts. These interrupts
             are handled
             by ISR's and they set a flag. This is a fairly common
             thing to do, I think.

             I don't see (or understand) how this can be achieved with
             RIOT-OS and
             cortexm_sleep. It is essential to check the condition
             AFTER disabling the
             interrupts.

             --
             Kees Bakker
             _______________________________________________
             devel mailing list
             devel@riot-os.org <mailto:devel@riot-os.org>
             https://lists.riot-os.org/mailman/listinfo/devel

         _______________________________________________
         devel mailing list
         devel@riot-os.org <mailto:devel@riot-os.org>
         https://lists.riot-os.org/mailman/listinfo/devel

     ,

     _______________________________________________
     devel mailing list
     devel@riot-os.org <mailto:devel@riot-os.org>
     https://lists.riot-os.org/mailman/listinfo/devel


_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel