Different function same functionality

RUI
1

Difference between
api.system.scheduler.task.destroy();
and
api.system.sleep.all();

and this seemly the same

When using this code

    Serial.print("The timestamp before sleeping: ");
    Serial.print(millis());
    Serial.println(" ms");
    Serial.println("(Wait 10 seconds or Press any key to wakeup)");
    api.system.scheduler.task.destroy();
    api.system.sleep.all(); // change function
    Serial.print("The timestamp after sleeping: ");
    Serial.print(millis());
    Serial.println(" ms");

there is no difference. In the examples sometimes the one and sometimes the other is used

2

api.system.scheduler.task.destroy(); stops loop() from being called ever.
api.system.sleep.all(); puts the loop into sleep until an event happens.

Difficult to explain. Maybe this simple example helps.
Loop calls 16 times api.system.sleep.all();
The device wakes up from sleep on events, that can be LoRa or LoRaWAN events or a timer event or an external interrupt.
After 16 times loop calls api.system.scheduler.task.destroy(); and after that loop() is never called again.

For demonstration purposes I use a timer that “ticks” every one second.
In the beginning, every timer event triggers a wakeup from sleep ==> loop is executed (if you look into the log, you can see there is as well another event happening that wakes the loop between tick #1 and tick #2
After 16 times you can still see the “Tick”, but loop is not executed anymore, because the loop task is destroyed.
After 20 ticks, the timer is stopping itself and you see no more output.

Log output:

20:07:51:081 -> +EVT:JOINED
20:07:51:386 -> Current Work Mode: LoRaWAN.
20:07:51:386 -> Calling Sleep 1 times
20:07:52:386 -> Tick 1
20:07:52:386 -> Calling Sleep 2 times
20:07:52:386 -> Calling Sleep 3 times
20:07:53:395 -> Tick 2
20:07:53:395 -> Calling Sleep 4 times
20:07:54:387 -> Tick 3
20:07:54:387 -> Calling Sleep 5 times
20:07:55:387 -> Tick 4
20:07:55:387 -> Calling Sleep 6 times
20:07:56:387 -> Tick 5
20:07:56:387 -> Calling Sleep 7 times
20:07:57:387 -> Tick 6
20:07:57:387 -> Calling Sleep 8 times
20:07:58:387 -> Tick 7
20:07:58:387 -> Calling Sleep 9 times
20:07:59:386 -> Tick 8
20:07:59:386 -> Calling Sleep 10 times
20:08:00:386 -> Tick 9
20:08:00:386 -> Calling Sleep 11 times
20:08:01:386 -> Tick 10
20:08:01:386 -> Calling Sleep 12 times
20:08:02:386 -> Tick 11
20:08:02:386 -> Calling Sleep 13 times
20:08:03:385 -> Tick 12
20:08:03:385 -> Calling Sleep 14 times
20:08:04:385 -> Tick 13
20:08:04:385 -> Calling Sleep 15 times
20:08:05:385 -> Tick 14
20:08:05:385 -> Calling Sleep 16 times
20:08:06:385 -> Tick 15
20:08:06:385 -> Destroying loop() task
20:08:07:386 -> Tick 16
20:08:08:384 -> Tick 17
20:08:09:384 -> Tick 18
20:08:10:384 -> Tick 19
20:08:11:384 -> Tick 20

And here is my simple test code:

/**
 * @file Scheduler-Destroy-Test.ino
 * @author Bernd Giesecke ([email protected])
 * @brief Demonstration of sleep.all and task.destroy
 * @version 0.1
 * @date 2024-07-17
 * 
 * @copyright Copyright (c) 2024
 * 
 */
#include <Arduino.h>

uint8_t loop_to_destroy = 0;
uint8_t timer_to_destroy = 0;

void nothing(void *)
{
	Serial.printf("Tick %d\r\n", timer_to_destroy + 1);
	timer_to_destroy++;
	if (timer_to_destroy == 20)
	{
		api.system.timer.stop(RAK_TIMER_0);
	}
}

void setup(void)
{
	Serial.begin(115200);
	delay(500);
	api.system.timer.create(RAK_TIMER_0, nothing, RAK_TIMER_PERIODIC);

	while (api.lorawan.njs.get() != 1)
	{
		Serial.println("Wait for join");
		delay(5000);
	}
	api.system.timer.start(RAK_TIMER_0, 1000, NULL);
}

void loop(void)
{
	loop_to_destroy++;
	Serial.printf("Calling Sleep %d times\r\n", loop_to_destroy);
	api.system.sleep.all();
	if (loop_to_destroy == 16)
	{
		Serial.println("Destroying loop() task");
		api.system.scheduler.task.destroy();
	}
}
3

Makes sense.
For most destroy makes more sense, right?

4

If you make your application event driven (timers, external interrupts, LoRa events), it makes sense to destroy the loop task.

5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.