Question regarding including in a new project

[xgonc]

@jefftenney, first of all, great work!

I was able to include lptimTick on my project with configUSE_TICKLESS_IDLE 2 and it runs as expected.

I'm not sure when the sleep mode is activated. Is it on every call of osDelay()?

Thanks.

[jefftenney]

@xgonc You can use tickless idle with or without lptimTick.c.

Setting configUSE_TICKLESS_IDLE to 1 means you're using tickless idle without lptimTick.c. The tickless implementation is entirely from FreeRTOS. The tick is provided by the hardware timer called SysTick.

Setting configUSE_TICKLESS_IDLE to 2 means you're using tickless idle with lptimTick.c. The tickless implementation is found in lptimTick.c. The tick is provided by the LPTIM you select.

Either way (1 or 2), sleep mode is activated at all the same times. Using lptimTick.c does not change when the sleep mode is activated. That's because FreeRTOS itself decides when to activate the sleep mode. The tickless implementation merely does what it is told by FreeRTOS. FreeRTOS decides to go to sleep when there is nothing to do -- when no tasks are ready to execute. When FreeRTOS notices no tasks will be ready until 10 more ticks elapse, it tells the tickless implementation to go to sleep for 10 ticks.

A task that calls osDelay() doesn't necessarily result in sleep mode. If another task is still executing during the first task's delay, FreeRTOS won't activate sleep mode. Only if no tasks are ready to execute will FreeRTOS activate the sleep mode. Lots of other FreeRTOS API calls can result in a task not being ready to execute. For example, xSemaphoreTake() can do that. While the task waits for the semaphore to be available, it is not ready. FreeRTOS would activate sleep mode in that case, as long as no other task is ready to execute. The beauty of this design is that application tasks don't need to manage the use of sleep mode. The OS knows when to go to sleep.

[xgonc]

Thanks for your answer!

I'm measuring the current levels, and for now I'm looking at the overall board current. Tomorrow I will try to measure the current of the MCU only, and I can see if I get next to the figures you have on the README. Mine is a STM32G474, so it won't be that low...

Anyways, with only a task running, I tested the following:

  for(;;)
  {
    for (size_t i = 0; i < 10000; i++)
    {
      HAL_UART_Transmit(&huart3, "test\r\n", 7, 10);
    }
    HAL_UART_Transmit(&huart3, "-------\r\n", 7, 10);
    HAL_Delay(5000);
  }

The uart transmit loop is drawing 19mA, and the blocking HAL delay, 21mA.

  for(;;)
  {
    for (size_t i = 0; i < 10000; i++)
    {
      HAL_UART_Transmit(&huart3, "test\r\n", 7, 10);
    }
    HAL_UART_Transmit(&huart3, "-------\r\n", 7, 10);
    osDelay(5000);
  }

The uart transmit loop is drawing, as expected, the same 19mA, but the OS delay, 14mA.

What's your opinion on the difference between the 2 situations?

[jefftenney]

Seems OK. HAL_Delay() is busy-wait function and prevents tickless idle. So current during the delay is the same as current when running normal code.

But osDelay() is not a busy-wait function, so it allows tickless idle. Thus you see power savings when in osDelay().

At this point in your experimenting, the current you measure should be the same whether you set configUSE_TICKLESS_IDLE to 1 or 2.

What is your clock speed? And what is your target board -- specifically what else is drawing energy on the board?