Category: Embedded

more esp32-s3-devkitc-1 programming notes

whbeebe

This is a follow on to this post: /2022/03/23/simple-programming-of-the-esp32-s3-devkitc-1-using-esp-idf/

These are a collection of notes more than anything else.

  • I cleaned up the code a bit, then added a few more comments to make things a bit clearer to me for future development. When you write for an audience of one, you tend to forget to leave important bread crumbs for the future when the code isn’t as fresh as when you first wrote it. Overall it grew a few lines, but all in the name of clarity and possible future growth.
  • I tried to use the Espressif Visual Studio Code plugin to develop with the ESP32-S3 board, but it wouldn’t see my initial Espressif supplied ESP-IDF installation.
  • I tried to use PlatformIO in Visual Studio Code, but it failed to connect with my existing ESP-IDF installation. I will admit PlatformIO looks quite powerful, and I’ve seen a few YouTube videos showing how to use it when writing code for older ESP32 chips and boards. But it won’t work with ESP-IDF 4.4 installed on my computer.

What I now have is a simpler development environment. I use Visual Studio to open and manage my ESP32-S3 projects. There’s no auto-complete, no C++ language checking, just syntax code highlighting. I have a shell opened in a vertical window on the right where I run the idf.py tool with necessary command line arguments, and watch the results. You can see the screen cap of a run at the top of the post. Primitive? Perhaps. But effective enough for my modest needs. I will probably give PlatformIO another run in the very near future.

As for the code, it’s a bit cleaner and I changed a few camel-case names to snake-case. The only camel-case names left are all from FreeRTOS, which makes spotting them a lot easier. Snake-case is the coding standard used in ESP-IDF, so I’ll be using that in my own code examples as well.

#include <stdio.h>#include "freertos/FreeRTOS.h"#include "freertos/task.h"#include "driver/gpio.h"#include "esp_log.h"#include "led_strip.h"#include "sdkconfig.h"// 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);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};static uint NUM_COLORS = sizeof(led_colors)/sizeof(led_colors[0]);// Stay in an endless loop. Don't return from this task.//while(true) {for( int color_select = 0; color_select < NUM_COLORS; ++color_select ) {// Set NeoPixel LED to a color using RGB from 0 (0%) to 255 (100%)// for each color.//pStrip_a->set_pixel(pStrip_a, led_colors[color_select][0],  led_colors[color_select][1],  led_colors[color_select][2],  led_colors[color_select][3]);// Refresh the strip to send data//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 2.//static void task_blink_led(void * pvParameters) {#define BLINK_GPIO46_LED 46gpio_reset_pin(BLINK_GPIO46_LED);// Set the GPIO as a push/pull outputgpio_set_direction(BLINK_GPIO46_LED, GPIO_MODE_OUTPUT);// 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);}}void app_main(void) {static const char *TAG = "DUAL_BLINK";int core = xPortGetCoreID();ESP_LOGI(TAG, "app_main running on core %i", core);ESP_LOGI(TAG, "CONFIG_BLINK_GPIO %i", CONFIG_BLINK_GPIO);// Create task 1.//TaskHandle_t xHandle1 = NULL;static uint8_t ucParameterToPass1 = 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.//TaskHandle_t xHandle2 = NULL;static uint8_t ucParameterToPass2 = 1;xTaskCreate(task_blink_led,"BlinkLED", // human-readable task name.2048,   // stack size in bytes.&ucParameterToPass2,tskIDLE_PRIORITY,&xHandle2);configASSERT(xHandle2);// Stay in an endless loop. Don't return from this task.//while (true) {vTaskDelay(1000 / portTICK_PERIOD_MS);}}

a problem with the arduino ide 2.0 rc5

whbeebe

I have been using the Arduino IDE 1.x since I first came across it back in 2013, so nearly 9 years now. In all that time it’s done yeoman work as a tool for writing software for embedded devices in C and C++ for both Arduino and Adafruit devices. I might be a big fan of Python, and by extension, Micro Python and Circuit Python, but there’s no denying that when critical timing counts and/or you’re limited in memory and storage resources that the Arduino IDE and C/C++ give you much finer control towards implementing an embedded solution. I was therefore greatly anticipating the final release of Arduino IDE 2.

Arduino IDE 2 ( https://www.arduino.cc/en/software ) is a re-write of Arduino IDE 1 using the Theia Platform ( https://theia-ide.org/ ). The usage of Theia brings the Arduino IDE 2 interface up to date with its contemporaries, such as Visual Studio Code. While the main interface is great to work with, it’s some of the subfunctions that are questionable, such as Preferences | Additional Boards Manager URLS.

The current release of Arduino IDE 2 is at release candidate 5. It’s this release with which I have a problem. When I try to add new URLs to point at board support repos, the text box into which those URLs can be edited is a very narrow line that will not expand. I need this feature to work in order to try and use the Arduino IDE 2 to help write software for the latest ESP32 boards, such as the ESP32-S3 and ESP32-C3. This is a problem since RC2 was released, and has been a problem with each release candidate since.

It wasn’t a problem with the beta releases. This is how the dialog should look, using the last beta in the series, beta 12. As you can see the text box is open, and I have at least three separate URLs in the text box.

Another issue that has been in all the releases I’ve used, both beta and release candidate, is the placement of the ‘OK’ and ‘Cancel’ buttons. On the Preferences dialog it’s one way, while on the Additional Boards Manager URLs dialog it’s the opposite. I don’t care what order you choose, but the order should be consistent. It’s not a bug like the dialog text box, but it is just downright sloppy.

I have tried to report this to the developers, but it appears my reporting isn’t getting through. I hope I’m wrong and that this issue is fixed before the final release.