Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
insmod wrote:Btw, what was the original reason to make flags into 2 integers, instead of an uint64_t?
insmod wrote:Wouldn't it break config on platforms where long is 8 bytes?
u.newValue = (uint64_t)strtoull(args, NULL, 10); p.kaczmarek2 wrote:Maybe we could do a selftest system like the one on Windows, but designed to run on Device?
p.kaczmarek2 wrote:It could test for basic stuff, like JSON parsing, commands execution, etc.
backlog startDriver Test; StartTest 100;
(uint64_t)strtoull(args, NULL, 10)sscanf(args, "%lld", &u.newValue))
p.kaczmarek2 wrote:The only new thing that I introduced yesterday is the per-platform testing that can be started only manually on physical device.
TL;DR: OpenBK’s 64-bit Flags update was checked on 2 targets first, and testers then expanded it across Realtek, XR809, and TR6260. One maintainer called per-device testing "finally meaningful" because Windows checks cannot validate SDK functions like
strtoull()on real MCUs. This FAQ helps OpenBK contributors verify PR 1548 safely and separate true 64-bit parsing results from older flag-13 bugs. [#21457658]
Why it matters: A flags parser that works on Windows but fails on one SDK can silently break settings, web UI behavior, or reboot persistence on real hardware.
| Option | What it checks well | Main limitation |
|---|---|---|
strtoull(args, NULL, 10) on device |
Real 64-bit decimal parsing on ESP, BL, LN, Beken SDKs | Must be validated per platform |
sscanf("%lld", ...) on device |
Alternate 64-bit read path for comparison | C library behavior can vary by SDK |
| Windows simulator tests | Fast regression checks on every commit | Cannot prove SDK-specific libc behavior |
Key insight: The thread’s main conclusion is that the 64-bit Flags PR itself looked good on tested 32-bit OpenBK platforms; the notable failures pointed back to pre-existing platform-specific issues, especially the older flag 13 behavior and SDK quirks.
strtoull() outside Windows. [#21457366]StartTest 100, where 100 ms is the interval between printed test steps and result checks. [#21457592]time_t, missing realloc on BL602, and unusual sprintf behavior, showing why device-level checks matter. [#21457368]flags 18446744073709551615. 3. Confirm the value displays correctly, saves, reboots cleanly, and does not trigger SDK-specific faults. The thread says all current OpenBK targets are 32-bit, so broad device duplication is unnecessary; the key question is whether strtoull() works on each main SDK outside Beken. [#21457366]uint64_t. The thread does not give a stricter architectural reason than that evolution path. [#21457325]uint32-based parts instead of relying on long. This matters because OpenBK is 32-bit today, but future ports or unusual compilers could size long differently. In short, fixed-width integers keep 64-bit flags stable across builds, while long can shift structure size and storage rules. [#21456907]strtoull() is a C library function that converts a text string into an unsigned long long integer, using a chosen base and returning a 64-bit-capable value on supported SDKs." OpenBK uses it because the command input arrives as text, and PR 1548 needs to read values up to 18446744073709551615 in base 10. The tested code path shown in the thread is u.newValue = (uint64_t)strtoull(args, NULL, 10);, which directly matches the 64-bit Flags goal. [#21457366]strtoull(args, NULL, 10) was treated as the main path to test, while sscanf("%lld", ...) was considered a useful comparison target. The thread’s maintainers wanted both covered by the new per-platform tests because those functions come from each SDK’s own C library, not from OpenBK. That means a Windows pass does not prove they behave the same on ESP, BL, LN, or Beken. The practical conclusion was to add on-device tests for both parsing routes. [#21457621]ENABLE_TEST_COMMANDS in obk_config.h, then add test commands in cmd_test.c and register them. 2. Add them to drv_test.c and compile the firmware. 3. Flash the device and run backlog startDriver Test; StartTest 100;, where 100 means a 100 ms interval between steps. The runner prints each command, waits, executes it, checks the result, and continues. [#21457592]sscanf, sprintf, realloc, and parsing code. That split matters because a simulator pass cannot prove behavior on BK7231, W600, LN882H, or Realtek libraries. [#21458365]strtoull() behaves correctly on ESP, BL, and LN, since Beken was already confirmed. A few cross-family samples therefore give higher value than many same-SDK boards. That keeps validation focused and fast for PR 1548. [#21457366]CMD_RES_ERROR if the result is wrong. The thread gives a concrete IP example: parse 192.168.0.123, then verify all 4 bytes. That mattered because %hhu handling had already failed on W600, LN882H, and Realtek, and realloc was still suspected broken on BL602. Windows tests cannot expose those MCU-specific libc differences, but per-device tests can fail immediately on hardware. [#21458365]long at 32 bits while pointers and long long use 64 bits, which makes 64-bit Windows behave differently from many Unix-like 64-bit environments." That mattered in the thread because a contributor worked mainly on 64-bit Windows and assumed long behavior from that world. They then corrected the code to use fixed-width integers after realizing Windows LLP64 does not guarantee portable flag storage elsewhere. [#21456907]0, separate from the 64-bit parser itself. After more testing, the PR author said they fixed the zero-value display and credited another tester for identifying it. They also stated the updated behavior was fine from their side after that correction. The thread does not publish the exact code change, but it clearly separates the UI bug from the core 64-bit flag parsing work. [#21459741]0 and a single-bit case like flag 13. The maintainer explicitly said they would add a FLAGS test for 64-bit flags, and that is the right place to verify strtoull() and sscanf() behavior outside Windows. This keeps future regressions visible before merge. [#21459788]