LED indication and power consumption

I am currently writing a program for LED indication of battery charge, voltage, and current consumption.
I am using beegee-tokyo/WisBlock-API as my main code
and beegee-tokyo/WisBlock-Sensor-For-LoRaWAN

Previously I used an OLED display, but now I decided that for the sake of miniaturization should use the LED indication on the motherboard (LED_GREEN & LED_BLUE).
So I wrote code FreeRTOS to “blink” two LEDs. The program works well. But I would like to hear the opinion of experienced developers: how much power consumption will increase due to one more task FreeRTOS. The official FreeRTOS documentation states that a task managed by a queue does not consume CPU resources.
Unfortunately, I do not currently have an ampere-voltmeter of sufficient accuracy to estimate energy consumption. Perhaps one of the DIY developers has already measured the power consumption of the processor when several more tasks are added to the main code.
I’m going to build two or three more tasks into the code to poll the sensors at a given time. Will this greatly increase energy consumption?
I would be grateful for your advice.

P.S. I would like to clarify further. As I understand it, the RAK1600 cannot be programmed for an interrupt; polling is only possible in a loop? I measure power to calculate battery capacity when powering a minicomputer.
Current consumption of RAK1600 during measurement: 0.7 - 1.0 mA, and with power off 6 - 15 µA.
Does it make sense to put the RAK1600 into ADC_OFF or even POWER_DOWN mode every second or will this mode of operation cause problems?
Thanks in advance for your answers.

#include "app.h"
#if RAK_LED > 0

#define LED_QUEUE_LEN 10

/* Queue structure */

TaskHandle_t HandleLED;
QueueHandle_t xQueueLED = NULL;

struct arrayLED {
     u_int16_t cycles;
    uint8_t LED;
     u_int16_t interval;
     u_int16_t pause;
} xLEDParameters;

/* The main task for LED */
void vTaskLED(void *pvParameters)
    struct arrayLED xParameters;	

    for (;;)
	  if (xQueueLED != NULL)
		if (xQueueReceive
		    (xQueueLED, &(xParameters),
		     (TickType_t) 10) == pdPASS)
		      for (int i = 0; i <= xParameters.cycles; i++)
	digitalWrite(xParameters.LED,  HIGH);
	digitalWrite(xParameters.LED,  LOW);

bool init_led()
    xQueueLED = xQueueCreate(LED_QUEUE_LEN, sizeof(xLEDParameters));

	digitalWrite(LED_GREEN,  LOW);
	digitalWrite(LED_BLUE,  LOW);

    if (xQueueLED == NULL)
	 return false;

    if (!xTaskCreate
	(vTaskLED, "LED", 1024, NULL, TASK_PRIO_LOW,
	 return false;

return true;

void LED_indication(const u_int16_t  cyclesT, const u_int8_t  LED, const u_int16_t   intervalT,
		const u_int16_t  pauseT)
    xLEDParameters.cycles = cyclesT;
    xLEDParameters.LED = LED;
    xLEDParameters.interval = intervalT;
    xLEDParameters.pause = pauseT;
    xQueueSend(xQueueLED, (void *) &xLEDParameters, (TickType_t) 0);


Thanks for sharing.

A FreeRTOS task waiting for a queue or a semaphore does not consume power in my experience as it will only run when there is something in the queue. However in your code you are only sleeping for 10 ticks, then if result is not pdPASS, you sleep again for 10 ticks.
You could change this to portMAX_DELAY. Then the task will sleep until something is in the queue and start processing it.

For the interrupt, correct, the RAK16000 doesn’t have an interrupt or threshold levels. But you do not have to poll it in a loop, you could setup a timer for e.g. measure every 10 seconds from a task. You can do this by setting up a timer that wakes up the app_event_handler() with a new event (you have do define that), read the RAK16000, do some calculations, then sleep again.

For ADC_OFF or POWER_DOWN you have to test. My guess is that POWER_DOWN should bring the lowest consumption.

Thank you, Bernd Giesecke! I have great fun writing programs using your code! I even got into FreeRTOS because I liked your code and Wisblock modules! It’s amazing when you can quickly assemble a device without wires and a soldering iron!
And thanks for the helpful answers!

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