Well, it can't be helped for now.
I will later try to update sdk to v1.00.10
But for now, do i open a pull request with those changes?
Currently all of the drivers and lfs can be compiled, where previously lfs build was disabled.
Would it be possible to get those changes (drivers, etc, lfs, you mentioned) without broken UART? We have some tutorials mentioning that it's worth to check UART after flashing and now we could confuse people... and how actually that change affected UART?
>>21525698 I will try.
Current SDK is tailored to minilibc, and printf implementation is done in minilibc_port.c.
And to get it to compile i had to cut out most of the code there.
Still, i'll try to port changes from newer sdk, will se if it works.
Added after 2 [minutes]:
Got it to work, just straight copy-pasted from newer sdk.
Are you referring to the Easyflash usage for OBK config? As I said some time ago, I'm not sure about that. On one hand, Easyflash is optimizing flash erase cycles usage, so that could be a good thing... but on the other hand, we don't save config that often so it doesn't matter and I would strongly prefer to have config at fixed address, so flash tools can access it in the future. So for now, don't port OBK config to easy flash. Better focus on new features or platforms. BK7252 or whatever may be possible.
Still, flash vars (channel values save restore) could be actually stored in easyflash, if possible. They are saved often and they could benefit from flash wear optimization.
It depends on how complicated is it. Of course it could, but I would still avoid giving us/you extra work. We still have to fix that Tuya Config partition parse, which currently just reassembles text from binary data which causes Tuya config read failure in some edge cases, and this has higher priority:
https://github.com/openshwprojects/BK7231GUIFlashTool/blob/main/BK7231Flasher/TuyaConfig.cs
Code: C / C++
Log in, to see the code
This is hacky as hell and could be improved with some Tuya code analysis:
I also thought about making a V6 config - where its size is 'dynamic' - like storing multiple ssids (more than 2), dynamically sized initCommandLine, etc.
With easyflash that could be done easily.
That sounds good, as long as it's really reliable and includes flasher update. Of course, flasher would need to support both formats, for the time being... I could help with C# code, if you already have a generic idea how to handle it. Testing in C# is a bit easier for me because I am still very limited when it comes to space, especially after having basements and stuff flooded. I've recently posted a post-flood Smart Switch teardown: https://www.elektroda.pl/rtvforum/topic4116996.html
Would you also take that chance and normalize configs between platforms? So you'd basically do a key-value system? Wouldn't it be prone to memory fragmentation over time, especially if the size of values has high variety?
Added after 3 [minutes]:
I didn't check the EasyFlash code yet, but maybe also GPT could help with C# translation. Not that I need it... but it's sometimes faster than doing by hand and not that bad if used with caution.
>>21525743 It's all concept only for now.
But i did thought about moving all configs to either easyflash, or flashdb.
I chose easyflash only because bl602 and tr6260 already used it by the time i came with that idea.
And there is probably no need to translate everything to c#, dllimports would probably be enough.
Fragmentation might be a problem, if env size is small enough. As it is now, i blindly believe in algorithms already implemented in ef code.
You have mostly convinced me, so I could agree to such change, but we may indeed need to check for fragmentation first.
How hard would it be to run EasyFlash on PC, I guess it has simple ef_port.c or whatever fill that we need to fill in?
We could create some kind of our own early test for EasyFlash and check how it behaves over time. Just a simple C program, no OBK yet, just C + EF.
Then, if we decide to port, we could do more OBK-related test of EasyFlash with OBK simulator. Simulate tens or hundreds of changes and see what happens.
This is exactly why I've added Windows (and later Linux) support to OBK, ability to do such tests really helps with development.
New sdk build: https://github.com/NonPIayerCharacter/OpenBK7231T_App/actions/runs/14580099010 Increased stack size to 100k, free heap is about 88k. This leaves about 40-50k for libc heap. Freertos version is now V10.4.1 instead of V7.0.2 (came with new sdk), and using heap_5.
LFS is now available, 0x1B000 length, replaces tuya config section. Easyflash is used for flashvars with possibility of using it for config.
Powersave implemented (currently if it is done in autoexec/init, it won't work, will upload fix later).
Berry enabled by default.
Now for the sad parts.
Worse signal reception, at least for me. I can connect to wifi with release version, but can't with this one. Rssi reports as -70. But it connects to a second, closer ap just fine.
Ota is much slower, and if not done after reboot, there is a high possibility that it will fail (will quickly eat all available heap, which will force a reboot).
>>21526809 Checked that sdk, and it is too different.
Main thing is the structure, everything is organized neatly in esp style.
Uses cmake instead of makefiles.
Decided to test ota some more, and if using new_tcp_server, ota can succeed, even if somehow logs about it's progress aren't printed. But it takes even longer.
@divadiow I see -79dbm on new sdk, did you check current release? Is there anything different in signal strength?
Tuya partition dump attached, but it can't be decoded. Taken from full dump made in web app.
@p.kaczmarek2 Do i open a pull request for SDK? Even with the aforementioned problems?
Hmm, i have HLK-W800 and it's worse for me.
Where old sdk can connect to wifi just fine and no packet loss, new sdk can take several minutes to connect and then many http requests fail.
Connection and OTA is important.... well, @insmod , would it be possible, to port for now LFS to OBK without the low quality WiFi SDK? At least until it's resolved...
Checked tuya W800, sdk is rather outdated, v1.00.01
Updated OBK: https://github.com/NonPIayerCharacter/OpenBK7231T_App/actions/runs/14693345412 Extra w800 features are the same as with newer sdk, easyflash for fv, berry, newlib gcc, heap_5, 100k stack size.
But i also disabled a lot of unneeded features, like hostif/rmms (AT? disabling that one freed a lot of memory), web server (sdk one), iperf server.
Binary sizes: +103kb fls, +70kb ota. Still a lot of free flash remains.
@divadiow check how gcc is done it tr6260/ecr6600, and do it the same way in xr sdks. No need to download them from external servers, keep them on github for reliability/faster actions builds. Or perhaps check how i did it in w800 branch, just pulled T sdk and used gcc in that one. Or even use system gcc, like with realteks, ln882 etc.
regarding toolchains, I was curious about why, for example, a 2015 gcc would be kept in place and not updated (by anyone, OpenBeken world, or generally) to the point where breaking changes were introduced and then it became too much work to fix in SDK. Like, if it means the potential for smaller builds, is it a reasonable practice to try to see how far one can update? Is that a good thing to do? If the build succeeds, why would one not do it?
>>21534169 That was my motivation for realteks and beken_freertos_sdk. And it is easy to update gcc when platform arch is arm.
But what to do with andes (tr/ecr) and c-sky (w800)? I did try to find a newer gcc for andes, but failed. For c-sky, there is a build package on github, but i didn't try it. https://github.com/c-sky/toolchain-build
For T/N, updating gcc will make obk crash when reading flash vars, because time_t changed from 32bit to 64bit.
Then there is always a question what libc is used, like with w800 currently minilibc is used, while in my branch gcc is using newlib. And i had to completely replace libc port to make it work.
I once tried to update gh actions from ubuntu-22.04 to ubuntu-latest. Many builds, where gcc is the system one failed, because its changes were incompatible (i think it was gcc 14?).
oh sure. interesting, OK. I should have guessed that a successful build doesn't necessarily mean a 100% working app. I haven't tested those XR809 and XR872 toolchain change builds...
The discussion revolves around the differences between the OpenBeken W800 and W806 models, particularly in terms of their specifications and OTA (Over-The-Air) update methods. The W800 features an HTTP server-based OTA, while the W806's capabilities are under scrutiny, with some users questioning its lack of Wi-Fi and Bluetooth. A user attempted to flash the W800 firmware onto a W806 board but encountered errors, leading to further investigation into the internal structures of both models. The conversation includes attempts to compile and test firmware for the W806, with discussions on flash sizes and the potential for reducing build sizes. The community is actively exploring the capabilities of the W806, including its possible Wi-Fi and Bluetooth functionalities, while sharing resources and troubleshooting strategies. Summary generated by the language model.
![[ZIGBEE] 20A Zigbee socket with energy metering (Tuya TS011F_plug_3)](https://obrazki.elektroda.pl/1000454900_1749493372_thumb.jpg)
