a bit of esp32-s3 c++ code

I recently purchased an inexpensive ESP32-S3-DevKitC-1-N32R8 development board. That’s an ESP32-S3 board with an ESP32-S3-WROOM-2, 32MB of FLASH and 8MB of SPIRAM. In one particular experiment I wanted to work with the ESP-IDF libraries for accessing the FLASH and SPIRAM. So far those attempts have failed in spite of trying to follow the demo code provided in the ESP-IDF. I’m currently using version 4.4.2 of ESP-IDF.

What I have done is create a project that allows me to get something running, then add features to a working project. This is the baseline project I’ve created, yet another RGB LED flasher. This one is written in C++ and uses C++ tuples to create a collection (vector) of colors to display on the RGB LED. I wanted something similar to what I do in MicroPython, where I create a Python collection and simply iterate over the collection of colors (see line 44). In the past when trying something similar in standard C I always had to know the size of my array/vector. With C++14, I can simply define my vector of colors, and then use the C++’s for-each construct to iterate over the vector of color tuples.

Finally, I should note that the RGB LED is on GPIO38. I used idf.py menuconfig to set the GPIO pen.

/* ESP32-S3 N32R8 Work Example

   This example code is released under the Apache License, Version 2

   Unless required by applicable law or agreed to in writing, this
   software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR
   CONDITIONS OF ANY KIND, either express or implied.
#include <vector>
#include <tuple>

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/gpio.h"
#include "esp_log.h"
#include "led_strip.h"
#include "sdkconfig.h"

static const char *TAG = "ESP32-S3-N32R8 Work Example";

/* Use project configuration menu (idf.py menuconfig) to choose the GPIO
   to blink, or you can edit the following line and set a number here.
static const uint8_t BLINK_GPIO = CONFIG_BLINK_GPIO;

static led_strip_t *pStrip_a;

/* Create a vector of color tuples to cycle through continuously.
   I wanted something simple and similar to what I do in Python.
   I don't believe this is it (the simple part).
typedef std::tuple<int, int, int, int> led_color;
static const std::vector <led_color> colors {
    {0,32,0,0},  // red
    {0,0,32,0},  // green
    {0,0,0,32},  // blue
    {0,0,32,32}, // cyan
    {0,32,0,32}, // magenta
    {0,32,16,0}, // yellow
    {0,0,0,0}    // black

static void cycle_rgb_led_colors(void) {
    for(auto c : colors) {
            std::get<0>(c), std::get<1>(c), std::get<2>(c), std::get<3>(c));
        pStrip_a->refresh(pStrip_a, 100);
        vTaskDelay(900 / portTICK_PERIOD_MS);
        // Turn RGB LED off by clearing all its individual LEDs.
        pStrip_a->clear(pStrip_a, 50);
        vTaskDelay(100 / portTICK_PERIOD_MS);

static void configure_rgb_led(void) {
    // LED strip initialization with the GPIO and pixels number.
    pStrip_a = led_strip_init(CONFIG_BLINK_LED_RMT_CHANNEL, BLINK_GPIO, 1);
    // Clear all LEDs in RGB LED to turn it off.
    pStrip_a->clear(pStrip_a, 50);

extern "C" void app_main(void) {

    ESP_LOGI(TAG, "Cycle RGB LED Colours.");

    while (true) {

sampling zorin os core 16.1

I’ve been looking other Linux distributions for a development environment going forward. Tonight I decided to look at Zorin OS ( https://zorin.com/ ). I’ve read a number of positive remarks, usually in the same post with positive remakes about Linux Mint.

I downloaded and installed Zorin OS Core 16.1 inside another Parallels virtual machine. As with Linux Mint I successfully installed Parallel Tools inside the Zorin VM (in order to do that I had to execute sudo apt install build-essential to pick up the necessary build tools). A quick tour and a check of a few key item of interest to me showed it was a solid distribution, like Mint, but unique in its own way. This won’t be a review of any kind, more like a “proof of life” post.

I did a little checking and discovered that Zorin, like Mint, is based on Ubuntu 20.04 LTS. Not a problem, as LTS means long term support. It makes no matter to me what version it’s based on, as I will install whatever current tools I need in parallel with the out-of-the-box tools. What I want is a distribution that is more developer friendly for the work I do. In particular brltty isn’t a part of the distribution. It is a part of Ubuntu 22.04 LTS, and is even more embedded in Pop!_OS. When brltty is installed and running it interferes with ESP32 devices that connect via USB and are mapped by the kernel to tty devices, causing the device to disconnect and making it impossible to program and debug ESP32 devices. The fact that Ubuntu 20.04 LTS does not have this installed is a strong plus in its favor, as well as any other current distributions still based on 20.04.

I was quite happy to see that the desktop defaults to Xorg, allowing Wayland to be an alternate. Not the surprise I discovered with Fedora 36 on a VM.

Overall I liked the look and feel of the installation. Zorin Core is complete enough for my work. I can install the bits I need and it will all work. Looks like I’ve two good distributions for my AMD development machine to mull over.