>>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.
Hello! I wanted to try flashing my ESP32-C3 device on openesp. This is a 4-sensor leak controller. When there is a leak, 2 valves close. The "IF" operator doesn't work; the controller reboots and provides an access point. Everything works well on the Beken chips. Here's the script:
Does not work. addChangeHandler Channel8 == 1 if $CH6==1 then "setChannel 11 1" Does not work. addEventHandler OnChannelChange 8 if $CH6==1 then "setChannel 11 1" Does not work.
addChangeHandler Channel8 == 1 if $CH6==1 then "setChannel 11 1"
What's the solution to make it work reliably? Write a script in Berry?
Added after 1 [hours] 39 [minutes]:
p.kaczmarek2 wrote:
Does it work when ran from console?
If so, then maybe stack size..
Thank you so much! It's working. Could you tell me how to make a global float variable for the water meters? I would like to make a pulse counter. Where each pulse is 10 L of water
I tried to install the berry module on the ESP32-C3, but it also goes to the access point when I restart it. Is there any way to save data in flash? Help
>>21818678 I thought about it, but considering how much code is needed and how many esp variants there are, i decided against it.
If baud is different from 115200, it fails on C2. Works on 32, C3, C5, C6, C61, S3
Synced with ESP32!
Configuring SPI flash pins (SpiAttach)...
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
Chip returned error for CMD 8: Status 1, Error 5
SPI_ATTACH failed (no response or error status).
Failed to configure SPI pins.
Thanks for testing, it's just a little experiment. I'll probably move it to PR and hide in main tree until it works. That's not a high priority.
Maybe I should focus first on BK7238 RF issue - but I don't have yet full information. What's exactly going on there? Can't we, in OBK, just use Tuya's RF location?
>>21818985 As it is now, it can be said that it's precompiled into app.
Default addr = 0x1E0000, T1 - 0x1E3000. And 0x1E3000 is where flash vars are stored.
After flash vars are moved, hal_flash_init would need to be modified to scan flash and modify BK_PARTITION_RF_FIRMWARE address accordingly
https://github.com/NonPIayerCharacter/beken_f...eken378/func/user_driver/BkDriverFlash.c#L708
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.
