qmsk / esp Goto Github PK

ESP8266/ESP32 FreeRTOS projects

License: Apache License 2.0

Makefile 0.11% C 91.83% Dockerfile 0.29% Vue 2.83% HTML 0.04% JavaScript 1.21% CSS 0.41% Python 2.00% SWIG 0.96% CMake 0.30% Shell 0.01%

artnet dmx esp32 sk6812rgbw sk9822 ws2811 ws2812b

esp's People

Contributors

Stargazers

Watchers

Forkers

kurtlab djpeterlewis scelibre

esp's Issues

Replace artnet output direct-to-task notifications with separate event group

Using direct-to-task notifications for such an async API is dangerous, because other APIs may also use task notifications internally, and these will interfere.

See e.g. 8d52235 which caused I2S output tearing, with fast artnet output updates causing i2s_out_flush() to return prematurely and the leds interface gpio to be cleared before I2S output EOF.

i2s_out slc buffer size calculation is buggy

https://github.com/SpComb/esp-projects/blob/47c8cfb32fb72ca43c8478969559d52d320bb74e/components/i2s_out/slc.c#L104-L113 uses size incorrectly, the last desc in a size > SLC_DESC_SIZE_MAX buffer should be between SLC_DESC_SIZE_MIN and SLC_DESC_SIZE_MAX bytes, currently all buffers will be SLC_DESC_SIZE_MAX.

This just allocates extra memory that will be left unused by init_slc_desc(), rather than crashing.

Web error UX

The Web UI needs some error UX for Files/FileNode and ConfigView operations.

Originally posted by @SpComb in #50 (comment)

Optimize VFS file upload/download performance

vfs_http_copy() needs some benchmarking to see if the fgetc / fputc loop could be optimized to improve file upload/download performance.

Originally posted by @SpComb in #50 (comment)

ESP-IDF 4.4 EOL

The esp-idf V4.4 release branch is EOL 2024-07-02: https://www.espressif.com/sites/default/files/advisory_downloads/AR2024-008%20End-of-Life%20Advisory%20for%20ESP-IDF%20v4.4%20Release%20Branch%20EN.pdf

Need to upgrade to V5.x, including our sdk patches + testing.

https://docs.espressif.com/projects/esp-idf/en/v5.3/esp32/migration-guides/release-5.x/5.0/index.html

Support for eth01-evo board / chip ESP32-C3

Is there any possiblity to flash the eth01-evo board, chip ESP32-C3 with the solution?

I'm running into the issue that the flash process aborts with the error message

A fatal error occurred: This chip is ESP32-C3 not ESP32. Wrong --chip argument?
CMake Error at run_serial_tool.cmake:56 (message):
  /opt/esp-idf-tools/python_env/idf4.4_py3.9_env/bin/python
  /opt/esp-idf/components/esptool_py/esptool/esptool.py --chip esp32 failed

I also tried to create a new build running the command upfront idf.py set-target esp32c3, but this does not change the target chip when trying to flash.

Any help would be useful. Thanks in advance.

config load/restore corrupts multi-value items

CLI config load -> config_load() / HTTP POST /config.ini -> config_read() does not clear multi-count items, meaning that loading/restoring the same config twice will duplicate the values:

> config get leds3 gpio_pin
25
26
32
33
> config load
I (31905) config_load: /config/boot.ini
> config get leds3 gpio_pin
25
26
32
33
25
26
32
33
>

I (72698) tcp_server_accept: 192.168.5.1:80 accept 192.168.5.2:54936
I (72698) http_request_read: POST /config.ini HTTP/1.1
I (72708) http_request_header: 	                Host : 192.168.5.1
I (72708) http_request_header: 	          User-Agent : Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0
I (72708) http_request_header: 	              Accept : application/json, text/plain, */*
I (72718) http_request_header: 	     Accept-Language : en-US,en;q=0.5
I (72718) http_request_header: 	     Accept-Encoding : gzip, deflate
I (72718) http_request_header: 	        Content-Type : text/plain
I (72718) http_request_header: 	      Content-Length : 3377
I (72728) http_request_header: 	              Origin : http://192.168.5.1
I (72728) http_request_header: 	          Connection : keep-alive
I (72728) http_request_header: 	             Referer : http://192.168.5.1/
I (72728) config_post_handler_ini: config read...
W (72738) config_set: leds.i2s_data_pin: too many values
W (72738) config_read: Invalid value for section leds name i2s_data_pin: 12
W (72738) config_set: leds.i2s_data_pin: too many values
W (72748) config_read: Invalid value for section leds name i2s_data_pin: 13
W (72748) config_set: leds.gpio_pin: too many values
W (72748) config_read: Invalid value for section leds name gpio_pin: 2
W (72748) config_set: leds.gpio_pin: too many values
W (72758) config_read: Invalid value for section leds name gpio_pin: 3
I (72758) config_post_handler_ini: config save...
I (72858) config_save: /config/boot.ini.new
I (73018) http_response_start: HTTP/1.1 204 No Content
I (73018) http_response_header: 	              Server : %s/%s (%s %s) ESP-IDF/%s
I (73018) http_server_main: force-close HTTP connection

config reset

Needs support for some kind of hardware config reset button, or a config error -> bootloop is unrecoverable.

This should inhibit loading of /config/boot.ini, and boot with defaults.

Should probably not enter a bootloop with #3 type configuration errors.

Requires some kind of wifi bootstrap... like defaulting to AP mode.

Workaroud

Erase config partition using esptool.py

ESPPORT=/dev/ttyUSB0 docker-compose run --rm flash /opt/ESP8266_RTOS_SDK/components/esptool_py/esptool/esptool.py --chip esp8266 --port /dev/ttyUSB0 --baud 115200 --before default_reset --after hard_reset erase_region 0x200000 0x100000

Could not build sdk

config artnet universe UX

the lower-four-bits logic is undocumented/difficult to config correctly in the CLI/web UI
artnet_add_output crashes into a bootloop if universe & 0xFFF0 does not strictly match the artnet.universe
artnet.universe can be configured with a value that has 0x000F bits set, and will thus never pass the artnet_add_output check, and always enter a bootloop

boot -> config -> init error handling should not always enter a boot-loop

The app_main() logic currently aborts and enters a boot loop on any error condition in the following stages:

board init (status_leds, uart, cli)
config load
component init + start

This is not ideal for situations like #3 invalid configurations, or waiting for the #4 config reset delay.

Could not build on ESP8266 (ncurse not found!)

Hello, I tried to build the project for an esp8266 but an error appears on the inclusion of ncurse. I tried to modify apt-install with other ncurse packages but it doesn't change anything.

Someone can help me ?

OS : Linux 6.5.0-15-generic 15~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux
Docker version : 25.0.1, build 29cf629
Docker compose version : 1.29.2, build unknown

gpio_out level should be per-pin

The implementation is broken if different LEDs are configured to use a different gpio_mode:

esp/main/leds_gpio.c

Lines 29 to 45 in f929ca9

 case LEDS_GPIO_MODE_LOW: 

 enabled = true; 

 LOG_INFO("leds%d: gpio mode=LOW pin=%d", i + 1, config->gpio_pin); 

 leds_gpio_out.pins |= gpio_out_pin(config->gpio_pin); 

 leds_gpio_out.level = GPIO_OUT_LOW; // XXX: per-pin 

 break; 

 case LEDS_GPIO_MODE_HIGH: 

 enabled = true; 

 LOG_INFO("leds%d: gpio mode=HIG pin=%d", i + 1, config->gpio_pin); 

 leds_gpio_out.pins |= gpio_out_pin(config->gpio_pin); 

 leds_gpio_out.level = GPIO_OUT_HIGH; // XXX: per-pin 

 break;

WiFi STA should reconnect automatically

If the WiFi STA connect fails or gets disconnected, it does not reconnect automatically.

Crash in user_leds_set() -> xEventGroupSetBits()

Under heavy leds artnet -> update_leds() -> user_activity() load, user_leds_set() -> xEventGroupSetBits() will occasionally crash:

Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

Core  1 register dump:
PC      : 0x4008e16b  PS      : 0x00060a33  A0      : 0x8008bba2  A1      : 0x3ffdd590  
0x4008e16b: uxListRemove at /opt/esp-idf/components/freertos/list.c:199

A2      : 0x3ffc1dc0  A3      : 0x3ffb3c5c  A4      : 0x00000001  A5      : 0x00060a23  
A6      : 0x00000005  A7      : 0x00000000  A8      : 0x00000000  A9      : 0x3ffafb28  
A10     : 0x3ffafb28  A11     : 0x00000000  A12     : 0x00000001  A13     : 0x00060a23  
A14     : 0x00000003  A15     : 0x00060f23  SAR     : 0x0000001f  EXCCAUSE: 0x0000001c  
EXCVADDR: 0x00000004  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  


Backtrace:0x4008e168:0x3ffdd5900x4008bb9f:0x3ffdd5b0 0x4008d482:0x3ffdd5d0 0x400fc596:0x3ffdd5f0 0x400d8099:0x3ffdd630 0x400d80e9:0x3ffdd650 0x400d7bb9:0x3ffdd670 0x400dcfe8:0x3ffdd690 0x400dd758:0x3ffdd6b0 0x4008e1d1:0x3ffdd7b0 
0x4008e168: uxListRemove at /opt/esp-idf/components/freertos/list.c:193

0x4008bb9f: vTaskRemoveFromUnorderedEventList at /opt/esp-idf/components/freertos/tasks.c:3751

0x4008d482: xEventGroupSetBits at /opt/esp-idf/components/freertos/event_groups.c:664

0x400fc596: user_leds_set at /build/components/user_leds/user_leds.c:216

0x400d8099: set_user_led at /build/main/user_leds.c:257

0x400d80e9: set_user_leds_activity at /build/main/user_leds.c:278

0x400d7bb9: user_activity at /build/main/user.c:74

0x400dcfe8: update_leds at /build/main/leds.c:169

0x400dd758: leds_artnet_main at /build/main/leds_artnet.c:232

0x4008e1d1: vPortTaskWrapper at /opt/esp-idf/components/freertos/port/xtensa/port.c:131





ELF file SHA256: a1b9c594030c662c

Rebooting...

Similar conditions also lead to an occasional lockup, where the ESP32 just freezes without a panic, and the watchdog fails to reboot.

	case LEDS_GPIO_MODE_LOW:
	enabled = true;

	LOG_INFO("leds%d: gpio mode=LOW pin=%d", i + 1, config->gpio_pin);

	leds_gpio_out.pins \|= gpio_out_pin(config->gpio_pin);
	leds_gpio_out.level = GPIO_OUT_LOW; // XXX: per-pin
	break;

	case LEDS_GPIO_MODE_HIGH:
	enabled = true;

	LOG_INFO("leds%d: gpio mode=HIG pin=%d", i + 1, config->gpio_pin);

	leds_gpio_out.pins \|= gpio_out_pin(config->gpio_pin);
	leds_gpio_out.level = GPIO_OUT_HIGH; // XXX: per-pin
	break;