2

I'm looking for advice how to put in place a lower power management inside an embedded application. My idea is to handle WFI enabled inside the IDLE task based on the RTOS info + application constraint.

  1. have an application function to know if application allows the WFI enable

  2. based on RTOS timing (Task, Timer, Semaphore timeout, .... ) calculate the maximum sleep time.

  3. use an HW feature to wake-up the system (maybe an EXTI)

So if some one has already managed this kind of application, I'm interested to know these solutions and maybe to get some code sample

Clifford
  • 88,407
  • 13
  • 85
  • 165
Domino
  • 31
  • 2
  • What are you talking about? WIFI? Or WFI? – Eugene Sh. Jan 12 '17 at 15:29
  • 2
    The `WFI` ARM instruction does **not** mean "wait for WiFi"! – too honest for this site Jan 12 '17 at 15:31
  • @Olaf I hope for the OP he didn't mean that... – Eugene Sh. Jan 12 '17 at 15:33
  • @EugeneSh.: Who knows? Even RISC CPUs add more and more instructions. And some CISC have (had?) indeed very _interesting_ instructions. See Transputer. – too honest for this site Jan 12 '17 at 15:37
  • Since it is an assembler instruction, you should specify the architecture. It is tagged FreeRTOS but is that actually what you are using? Not referenced in the question itself. – Clifford Jan 12 '17 at 16:39
  • In context WIFI was clearly a typo - I fixed it. If I am wrong let the OP fix it, but the question then would make make little sense. – Clifford Jan 12 '17 at 16:54
  • @Clifford: Sounds reasonable. But putting WiFi in idle state would also make sense. I'm just not sure OP really understands how WFI works, considering this: "My idea is to handle WFI enabled". I'm not sure if `WFE` would not be a better match here. – too honest for this site Jan 12 '17 at 21:49
  • @Olaf : largely on the basis that WFI was mentioned twice and WIFI (all caps) only once. Certainly the proposal seems over complicated - WFI should be transparent to the application. On ARM Cortex-M I think it very marginally increases interrupt latency; but if that is the difference between the application working and not working the application is marginal at best. – Clifford Jan 13 '17 at 09:59
  • @Clifford: I see WFI more to reduce power consumption than interrupt latency, indeed. If the latter really matters, I agree there is likely already a problem with the code. Using an OS in such systems is possibly not a good idea already. – too honest for this site Jan 13 '17 at 11:13

1 Answers1

2

Most RTOS implementations for architectures that support it already place WFI in the idle loop by default if no background work or user hooks are processed there - I don't think FreeRTOS is any different. The system will wake-up on any interrupt including the RTOS systick so there is nothing further to do to support low-power operation - if it is not in the idle loop, then it is doing work and not able to enter low-power.

For further power reduction, some RTOS support a tick-less mode where the RTOS systick interrupt period is variable and set to the longest active remaining timeout or delay and then the tick-counter is corrected on start-up based on the number of ticks actually spent asleep. It can still wake-up on other interrupts of course.

Tick-less operation is beneficial on systems with relatively large interrupt and timing intervals (compared to the RTOS tick rate). If you do work on every tick, it serves little purpose, because it will wake-up to do that in any case.

FreeRTOS supports tick-less operation on ARM Cortex-M using configUSE_TICKLESS_IDLE as described at Low Power RTOS For ARM Cortex-M MCUs.

Clifford
  • 88,407
  • 13
  • 85
  • 165