>>21651947 I think all of mine can be merged, even 3.0.78.
LN882H IR while enabled by default, there is still a lot of free space remains. Even if everything in OBK was to be enabled, there would still likely be about 50-100kb free of ota space.
ESP-IDF is just update from v5.5 to v5.5.1. It only brings ESP32-C61 v1.0 support (currently only beta chips works, and with this update support for them was dropped).
TXW is in acceptable enough state.
were there any concerns still @p.kaczmarek2@max4elektroda? is it because it's quite a big change?
I would think it's safe to merge - we "only" change "HAL_Delay_us()", used in DHT and DS1820 driver.
The platforms affected from this change either still work with this PR, or (the ones not working before) do work with it.
There is only one discussable point I think, which is the new possibility to test HAL_Delay_us() on pins, wich can be enabled with "ENABLE_DS1820_TEST_US".
It's disabled now for all platforms, so it's no more than an option now..
I remember that the initial version of this PR (or similar one) broke timings on DHT or something, but if that's not the case anymore, I am happy to merge it.
it boots fully and creates connectable AP.
Wifi scan sees 5ghz networks.
My C5 also arrived. Had some problems how to connect for some tests but came up with the idea to fit it into my universal adapter.
Needed some paper to fit (though it should be 18mm as WROVER module), so right row is isolated, but the left row connects o.k.
To get infos or flash I used esptool with "--no-stub" (else got "A fatal error occurred: Unable to verify flash chip connection (No serial data received.)."
esptool.py -p /dev/ttyACM0 --no-stub -b 921600 write_flash 0 OpenESP32C5_1.18.171_4M.factory.bin
esptool.py v4.8.0
Serial port /dev/ttyACM0
Connecting...
Detecting chip type... ESP32-C5
Chip is ESP32-C5 (revision v1.0)
Features: WiFi 6, BT 5, IEEE802.15.4
Crystal is 48MHz
MAC: XX:XX:XX:XX:XX
BASE MAC: XX:XX:XX:XX:XX
MAC_EXT: ff:fe
ROM expects crystal freq: 48 MHz, detected 48 MHz
Changing baud rate to 921600
Changed.
Enabling default SPI flash mode...
Configuring flash size...
WARNING: In case of failure, please set a specific --flash_size.
Flash will be erased from 0x00000000 to 0x0012ffff...
Erasing flash...
Took 1.64s to erase flash block
Wrote 1244160 bytes at 0x00000000 in 7.9 seconds (1267.3 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
AP is only in 2.4GHz Wifi, but in scan I see 5GHz APs (Channel 116)
There's an AT CMD based firmware, it won't react to my input on ACM tty (from USB - and sadly RX/TX are on the opposite side, I isolated to fixate the module)...
Spoiler:
W (1048) wifi:WDEV_RXCCK_DELAY:960
W (1048) wifi:WDEV_RXOFDM_DELAY:256
W (1048) wifi:WDEV_RX_11G_OFDM_DELAY:257
W (1048) wifi:WDEV_TXCCK_DELAY:630
W (1048) wifi:WDEV_TXOFDM_DELAY:94
W (1058) wifi:ACK_TAB0 :0x 90a0b, QAM16:0x9 (24Mbps), QPSK:0xa (12Mbps), BPSK:0xb (6Mbps)
W (1068) wifi:CTS_TAB0 :0x 90a0b, QAM16:0x9 (24Mbps), QPSK:0xa (12Mbps), BPSK:0xb (6Mbps)
W (1068) wifi:WDEVBEAMFORMCONF:0x61d7120, HE_BF_RPT_RA_SET_OPT:1
W (1078) wifi:WDEVVHTBEAMFORMCONF: 0x61d7120, WDEV_VHT_BEAMFORMEE_ENA: 1, WDEV_VHT_NG_SEL: 0
W (1088) wifi:(agc)0x600a7128:0xd21f0c20, min.avgNF:0xce->0xd2(dB), RCalCount:0x1f0, min.RRssi:0xc20(-62.00)
W (1098) wifi:MODEM_SYSCON_WIFI_BB_CFG_REG(0x600a9c18):0x10003802
W (1098) wifi:(phy)rate:0x0( LP-1Mbps), pwr:20, txing:20
W (1108) wifi:(phy)rate:0x1( LP-2Mbps), pwr:20, txing:20
W (1108) wifi:(phy)rate:0x2(LP-5.5Mbps), pwr:20, txing:20
W (1118) wifi:(phy)rate:0x3( LP-11Mbps), pwr:20, txing:20
W (1118) wifi:(phy)rate:0x5( SP-2Mbps), pwr:20, txing:20
W (1128) wifi:(phy)rate:0x6(SP-5.5Mbps), pwr:20, txing:20
W (1128) wifi:(phy)rate:0x7( SP-11Mbps), pwr:20, txing:20
W (1138) wifi:(phy)rate:0x8( 48Mbps), pwr:17, txing:17
W (1138) wifi:(phy)rate:0x9( 24Mbps), pwr:19, txing:19
W (1148) wifi:(phy)rate:0xa( 12Mbps), pwr:19, txing:19
W (1148) wifi:(phy)rate:0xb( 6Mbps), pwr:19, txing:19
W (1158) wifi:(phy)rate:0xc( 54Mbps), pwr:17, txing:17
W (1158) wifi:(phy)rate:0xd( 36Mbps), pwr:19, txing:19
W (1168) wifi:(phy)rate:0xe( 18Mbps), pwr:19, txing:19
W (1168) wifi:(phy)rate:0xf( 9Mbps), pwr:19, txing:19
W (1178) wifi:(phy)rate:0x10, mcs:0x0, pwr(bw20:19, bw40:18), txing:19, HE pwr(bw20:19), txing:19
W (1188) wifi:(phy)rate:0x11, mcs:0x1, pwr(bw20:19, bw40:18), txing:19, HE pwr(bw20:19), txing:19
W (1198) wifi:(phy)rate:0x12, mcs:0x2, pwr(bw20:18, bw40:17), txing:18, HE pwr(bw20:18), txing:18
W (1208) wifi:(phy)rate:0x13, mcs:0x3, pwr(bw20:18, bw40:17), txing:18, HE pwr(bw20:18), txing:18
W (1208) wifi:(phy)rate:0x14, mcs:0x4, pwr(bw20:17, bw40:16), txing:17, HE pwr(bw20:17), txing:17
W (1218) wifi:(phy)rate:0x15, mcs:0x5, pwr(bw20:17, bw40:16), txing:17, HE pwr(bw20:17), txing:17
W (1228) wifi:(phy)rate:0x16, mcs:0x6, pwr(bw20:17, bw40:16), txing:17, HE pwr(bw20:17), txing:17
W (1238) wifi:(phy)rate:0x17, mcs:0x7, pwr(bw20:17, bw40:16), txing:17, HE pwr(bw20:17), txing:17
W (1248) wifi:(phy)rate:0x18, mcs:0x8, pwr(bw20:19, bw40:16), txing:19, HE pwr(bw20:16), txing:16
W (1258) wifi:(phy)rate:0x19, mcs:0x9, pwr(bw20:18, bw40:16), txing:18, HE pwr(bw20:15), txing:15
W (1268) wifi:(hal)co_hosted_bss:0, max_indicator:0, bitmask:0xff, mBSSIDsEnable:0
I (1268) wifi:11ax coex: WDEVAX_PTI0(0x55777555), WDEVAX_PTI1(0x00003377).
I (1278) wifi:mode : sta (XX:XX:XX:XX:XX:XX)
I (1278) wifi:enable tsf
W (1288) wifi:(BB)enable busy check(0x18), disable idle check(0xaa)
I (1288) esp32c5_wifi: ==========Wi-Fi STA started==========
Scanning Wi-Fi networks...I (8058) esp32c5_wifi: ==========Wi-Fi scan completed==========
5G AP: XXSSID1XX, RSSI: -94 dBm, BSSID: XX:XX:XX:XX:XX:XX
5G AP: XXSSID2XX, RSSI: -94 dBm, BSSID: XX:XX:XX:XX:XX:XX
5G AP: XXSSID3XX, RSSI: -94 dBm, BSSID: XX:XX:XX:XX:XX:XX
WiFi tool ready. Send AT+HELP for command list
I (8078) main_task: Returned from app_main()
Added after 5 [minutes]:
max4elektroda wrote:
To get infos or flash I used esptool with "--no-stub" (else got "A fatal error occurred: Unable to verify flash chip connection (No serial data received.)."
>>21689071 Crashes because uart is already initialized in DMX_Init?
Don't know why flush freezes, and is it really needed? It is only for RX, not TX. For TX use uart_wait_tx_done. (https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/uart.html#_CPPv410uart_flush11uart_port_t)
Probably I could investigate exactly what's done there under the hood, but still wanted to get faster approach.
insmod wrote:
>>21689071 For TX use uart_wait_tx_done. (https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/uart.html#_CPPv410uart_flush11uart_port_t)
I will try
Added after 1 [hours] 45 [minutes]:
UPDATE: DMX works, more or less. I am still not sure why it seems that data seems to be applied with second call, but i will resolve it soon, hopefully. I will also finish LED backend split.
The code in WINDOWS block crashes ESP32 due to repeated UART init. The code in else works incorrectly (second call pushes data). Probably that's as far as I can go today.
Added after 44 [seconds]:
It would help a lot to scope the UART but I am not sure if I have time to set this up tonight.
I didn't know about uart_write_bytes_with_break, I may check it soon.
I've accepted cache PR, good idea.
For now, I'm still focusing on LEDs.
What kind of UI do we need for RGBW strip? Should we allow RGB and W control at the same time? Or show RGBCW and try to emulate cool with RGB like on bulbs...
And what do you think about caching toolchains in workflow to speed-up build process? In some cases it builds faster by more than 1 minute. Full build of everything is only 6m 36s (https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/17720392809)
https://github.com/openshwprojects/OpenBK7231T_App/pull/1793
Can it be this somehow broke Windows simulator build in "my" repo @insmod ?!? It works o.k. (e.g. in PR#7169), but for the same "local" I get:
Project "D:\a\OpenBK7231T_App\OpenBK7231T_App\openBeken_win32_mvsc2017.vcxproj" on node 1 (default targets).
C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.WindowsSDK.targets(46,5): error MSB8036: The Windows SDK version 10.0.17763.0 was not found. Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution". [D:\a\OpenBK7231T_App\OpenBK7231T_App\openBeken_win32_mvsc2017.vcxproj]
Done Building Project "D:\a\OpenBK7231T_App\OpenBK7231T_App\openBeken_win32_mvsc2017.vcxproj" (default targets) -- FAILED.
The discussion centers on configuring OpenBeken firmware for ESP32 devices with a default 4MB flash size using sdkconfig.defaults.esp32. Initial issues included missing sdkconfig.defaults.esp32 and bootloader offset misconfiguration, which were resolved to enable successful compilation and flashing. Various ESP32 variants were tested, including ESP32-C3, ESP32-C6, ESP32-CAM, ESP32-C2, ESP32-D0WDQ5-V3 (ESP-WROOM-32), and ESP32-S3, with reports on flash size detection, bootloader behavior, and peripheral support. Challenges encountered involved stack overflows on reboot, watchdog timer resets, and GPIO functionality inconsistencies, particularly on non-C/S ESP32 boards. Solutions included adjusting makefiles for 4MB flash, fixing bootloader offsets, increasing task stack sizes, and replacing software timers with hardware timers for improved timing accuracy. Peripheral drivers such as BMP280, AHT2x, DS1820, DHT11/22, PWM, UART, and NTP were tested with varying success; some required specific pin assignments or additional delays to prevent crashes. Deep sleep support was added without GPIO wakeup. The firmware uses the Espressif ESP-IDF SDK for ESP32 and plans for ESP8266 porting were discussed, noting SDK differences and RAM constraints. Continuous integration (CI) and online build availability were confirmed. Users shared flashing tools, partition table considerations, and debugging tips including esptool flash_id and efuse burning. The community actively tested and reported logs, crashes, and feature functionality, contributing to iterative fixes and enhancements. Summary generated by the language model.
