Flashing LED's with different rates

Kernel
1

I am trying to understand how this code works

/* Include FreeRTOS APIs and defines */
#include <mutex>
#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "freertos/timers.h"


SemaphoreHandle_t mutex = xSemaphoreCreateMutex();

const int RED = 4;

void setup()
{
   assert(mutex);
   Serial.begin(115200);
 
   pinMode(RED, OUTPUT);
   
  xTaskCreatePinnedToCore(Task1, "Task1", 1000, NULL, 1, NULL, 0);    
  xTaskCreatePinnedToCore(Task2, "Task2", 1000, NULL, 1, NULL, 0);  
 
}   

void Task1( void * parameter )
{
 
  for(;;)
  {
     xSemaphoreTake(mutex, portMAX_DELAY);
     digitalWrite( RED, HIGH);
     vTaskDelay( 400 );
     digitalWrite( RED, LOW);
     vTaskDelay( 400 );
     xSemaphoreGive(mutex);
  }
}

void Task2( void * parameter )
{
  for(;;)
  {
    xSemaphoreTake(mutex, portMAX_DELAY);
    digitalWrite(RED, HIGH);
    vTaskDelay( 500 );
    digitalWrite(RED, LOW);
    vTaskDelay( 500 );
    xSemaphoreGive(mutex);
  }
}

void loop() {}

I understand there are two tasks created with same priority. Task 1 flash LED with 400ms and Task 2 flash LED with 500ms.

I don’t understand how mutex working in code ?

2

Well, I guess the idea is to serialze flashing cycles to prevent the two tasks from uncontrollably turning on and off the LED. Without the mutex, you can expect pretty wild flashing. With the mutex, you will see only “short” vs. “long” flashes.

It serves the purpose, but I would not exactly call this a good example for a mutex use.

1 Like
3

In your opnion, What would be better example of using a MUTEX

4

there’s nothing technically wrong with that sample, but just like you,I initially asked myself “why?” and after thinking about “why ask why” I figured that I do not expect a vTaskDelay() inside a mutex. That sort of defeats the purpose because the idea of vTaskDelay() is to allow other tasks to get the CPU, but in the sample, exactly that is excluded (at least for the competing task) with the mutex.

A more “prototypical” example would be an implementation of a homegrown linked list where one tasks inserts and the other task removes. The insert and remove operations would be guarded by the mutex because those are normally not atomic, meaning that a task switch interrupting, sav, an insert operation at the wrong time may leave the linked list in limbo.

1 Like
5

Sorry, I don’t understand why you don’t expect vTaskDelay() ?

How led would change state if you don’t use vTaskDelay() ?

6

I wrote “I didn’t expect vTaskDelay() INSIDE A MUTEX.” For the flashing functionality, I don’t expect anything else. :wink:

7

I know it’s a little off topic, but I still believe that flashing an LED is something which should be done by hardware where possible, so that the microcontroller can be left to do its controlling and processing instead of using up threads for flashing routines.

A digital potentiometer, an electrolytic and a ceramic capacitor, and a 555 timer IC is pretty much the circuit, the microcontroller controlls things by setting the potentiometer (changing this value will change the clock speed of the 555 timer) and triggering the timer, but then the microcontroller can forget about things and leave the flashing to be managed by the hardware circuit, and if the design doesn’t call for varying flashing intervals then one can omit the digital potentiometer and put in a fixed resistor or (for the case of fine tuning/calibration) a trimpot (trimmer).

Though a caveat to this is that 555 IC chips usually operate at between 4.5-16v, and they sink/source curent up to around 200mA, so depending upon one’s MPU, extra circuitry may be required … and this then becomes a consideration about your package design, because extra circuitry will obviously increase the physical footprint of the solution; but if that’s not an issue I think I would always favour a hardware controlled LED solution

8

I would disagree. The software required is very small and low overhead. It doesn’t Ned a task, just a timer callback. Also, the hardware options make the flash pattern very fixed, so not as useful. (Yes, maybe if you requirement is a continuous 1 Hz flashing, hardware works).

If you are doing HIGH frequency flashing(PWM) for brightness, then yes THAT could be hardware.