C++ / Development / Embedded / Programming

adding queues, c++ — more esp32-s3-devkitc-1 programming notes

whbeebe

In this post I’m going to show how I added freeRTOS queues to last post’s code. In addition, I moved the source from C to C++, hopefully using the C++17 standard. I discovered that if I renamed the source file extension from .c to .cpp then the ESP IDF framework would automatically switch from compiling the source as C to the C++. After the switch I was able to do a bit of contemporary C++ coding to clean up my original code, which I’ll show later in the post. To better help explain things, I’ve broken the single source file into four sections to describe what’s happening.

The primary motivation for adding queues came from discovering that you can’t use ESP_LOGx calls in critical sections such as threads. If you do then the application will abort and start over, continuously. So that led me to find a way to transfer information from the threads back to app_main, which can then be logged without causing the application to crash.

#include <stdio.h>#include "freertos/FreeRTOS.h"#include "freertos/queue.h"#include "freertos/task.h"#include "driver/gpio.h"#include "esp_log.h"#include "led_strip.h"#include "sdkconfig.h"QueueHandle_t   qtask = NULL;enum MsgType {corenum = 1,tick};struct TaskMessage {uint16_ttaskid;MsgType msgtype;uint32_tmsgdata;};

This first code section lists the necessary include files, the global definition of the queue handle (QueueHandle_t qtask), a simple enumeration, and a simple message structure to be used by the tasks with the queues.

// Task 1.//static void task_blink_neo_pixel(void * pvParameters) {static led_strip_t *pStrip_a;pStrip_a = led_strip_init(CONFIG_BLINK_LED_RMT_CHANNEL, CONFIG_BLINK_GPIO, 1);pStrip_a->clear(pStrip_a, 50);TaskMessage task_message, *ptask_message;ptask_message = &task_message;task_message.taskid = *reinterpret_cast<uint16_t*>(pvParameters);task_message.msgtype = MsgType::corenum;task_message.msgdata = xPortGetCoreID();xQueueSend(qtask, (void *)&ptask_message, 0);uint32_t count = 0;static int led_colors[][4] = {{0, 32, 0, 0},  // red{0, 0, 32, 0},  // green{0, 0, 0, 32},  // blue{0, 32, 0, 16}, // violet{0, 0, 32, 32}  // cyan};// Stay in an endless loop. Don't return from this task.//while(true) {for (auto color : led_colors) {pStrip_a->set_pixel(pStrip_a, color[0], color[1], color[2], color[3]);pStrip_a->refresh(pStrip_a, 100);vTaskDelay(500 / portTICK_PERIOD_MS);// Set NeoPixel LED dark by clearing all its pixels.pStrip_a->clear(pStrip_a, 50);vTaskDelay(500 / portTICK_PERIOD_MS);task_message.msgtype = MsgType::tick;task_message.msgdata = count++;xQueueSend(qtask, (void *)&ptask_message, 0);}}}

This is the first task which blinks the built-in NeoPixel with five different colors (led_colors) repeatedly. Switching to C++ allowed me to use a C++ style for-each construct (line 58) and eliminate the verbose code I was using before, such as defining the size of the array of colors in one variable and then using a classic C for loop to iterate through led_colors. Cleaner code, fewer lines and two less variables.

However, the interesting bits are lines 39,44, and 68. It’s on those lines the message structure is set up, and it’s lines 44 and 68 that send out a message on the queue. The really annoying part is how to set up the pointer to message that is unique to each task. It took me a while while reading various code examples that the argument in xQueueSend was a void pointer to pointer, not a simple void pointer. Once I got that part straight then I was able to refine the messaging a bit to what it is right now.

Two messages are sent by tasks 1 and 2; the CPU core they’re running on, followed by a continuous data message that’s sending out a simple counter incremented every time an LED flashes.

// Task 2.//static void task_blink_led(void * pvParameters) {const gpio_num_t BLINK_GPIO46_LED = (gpio_num_t)46;gpio_reset_pin(BLINK_GPIO46_LED);// Set the GPIO as a push/pull outputgpio_set_direction(BLINK_GPIO46_LED, GPIO_MODE_OUTPUT);TaskMessage task_message, *ptask_message;ptask_message = &task_message;task_message.taskid = *reinterpret_cast<uint16_t*>(pvParameters);task_message.msgtype = MsgType::corenum;task_message.msgdata = xPortGetCoreID();xQueueSend(qtask, (void *)&ptask_message, 0);uint32_t count = 0;// Stay in an endless loop. Don't return from this task.//while (true) {gpio_set_level(BLINK_GPIO46_LED, true);   // LED onvTaskDelay(100 / portTICK_PERIOD_MS);gpio_set_level(BLINK_GPIO46_LED, false);  // LED offvTaskDelay(100 / portTICK_PERIOD_MS);gpio_set_level(BLINK_GPIO46_LED, true);   // LED onvTaskDelay(100 / portTICK_PERIOD_MS);gpio_set_level(BLINK_GPIO46_LED, false);  // LED offvTaskDelay(2700 / portTICK_PERIOD_MS);task_message.msgtype = MsgType::tick;task_message.msgdata = count++;xQueueSend(qtask, (void *)&ptask_message, 0);}}

Task 2 is a shorter version of Task 1 because it’s only toggling a single color LED on one of its GPIO pins. The set up code for the queue message is the same between both tasks, so there’s a bit of a code smell there. I suppose I should come up with a simple class that encapsulates queue message block initialization. Perhaps the struct TaskMessage can be evolved in that direction. I have yet to decide. Once again the task sends one message with the CPU core it’s running on, followed by a continuous stream of data messages sending the counter results.

extern "C" void app_main(void) {static const char *TAG = "DUAL_BLINK_QUEUE";int core = xPortGetCoreID();ESP_LOGI(TAG, "app_main running on core %i", core);ESP_LOGI(TAG, "CONFIG_BLINK_GPIO %i", CONFIG_BLINK_GPIO);TaskHandle_t xHandle1 = NULL;static uint16_t ucParameterToPass1 = 1;TaskHandle_t xHandle2 = NULL;static uint16_t ucParameterToPass2 = 2;qtask = xQueueCreate(10, sizeof(TaskMessage *));if (qtask != NULL) {ESP_LOGI(TAG, "queue created");// Create task 1.//xTaskCreate(task_blink_neo_pixel,"BlinkNeoPixel",// human readable task name.2048,   // stack size in bytes.&ucParameterToPass1,tskIDLE_PRIORITY,&xHandle1);configASSERT(xHandle1);// Create task 2.//xTaskCreate(task_blink_led,"BlinkLED", // human-readable task name.2048,   // stack size in bytes.&ucParameterToPass2,tskIDLE_PRIORITY,&xHandle2);configASSERT(xHandle2);TaskMessage *ptask_message;// Stay in an endless loop. Don't return from this task.//vTaskDelay(1000 / portTICK_PERIOD_MS);while (true) {// vTaskDelay(1000 / portTICK_PERIOD_MS);xQueueReceive(qtask, &(ptask_message), (1000/portTICK_PERIOD_MS));uint16_t tid = ptask_message->taskid;MsgType msgtype = ptask_message->msgtype;uint32_t msgdata = ptask_message->msgdata;ESP_LOGI(TAG, "Task ID %i, MsgType %i, msg data %i", tid, msgtype, msgdata);}}}

Finally we get to app_main, the entry point for ESP32. Note that I had to declare app_main as extern "C". This occurred when I switch the source to C++. The library that the ESP IDF wants to link with my code expects a standard C app_main signature. Compiling as C++ “mangles” the name, thus the need to declare external C symbol naming.

The majority of app_main is setting up the queue and starting the two tasks. The work begins in line 149 where the code waits for messages to come in from each task. Note that the message block is owned by the tasks, and only a pointer to those message blocks is sent on the message queue. This keeps the amount of data being sent to a minimum.

With all that running, here’s what the initial output looks like:

...I (277) cpu_start: Starting scheduler on PRO CPU.I (0) cpu_start: Starting scheduler on APP CPU.I (297) DUAL_BLINK_QUEUE: app_main running on core 0I (307) DUAL_BLINK_QUEUE: queue createdI (327) gpio: GPIO[46]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0 I (1307) DUAL_BLINK_QUEUE: Task ID 2, MsgType 1, msg data 0I (1307) DUAL_BLINK_QUEUE: Task ID 1, MsgType 1, msg data 0I (1377) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 0I (2377) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 0I (2427) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 1I (3367) DUAL_BLINK_QUEUE: Task ID 2, MsgType 2, msg data 0I (3477) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 2I (4477) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 2I (4527) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 3I (5527) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 3I (5577) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 4I (6417) DUAL_BLINK_QUEUE: Task ID 2, MsgType 2, msg data 1I (6627) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 5I (7627) DUAL_BLINK_QUEUE: Task ID 1, MsgType 2, msg data 5...

The first two messages received from the two tasks are the CPU core (MsgType 1), followed by a continuous stream of counter values. Because of the task 1’s faster blink cycle, there are far more messages from task 1 than task 2.

I’m working on setting up an interrupt handler, and breaking up the code into smaller source modules. So until the next post, happy coding!