Wymagana weryfikacja 64-bitowego polecenia Flags na wielu platformach

Zmodyfikowałem komendę Flags, aby obsługiwała 64bit. Wyświetlanie na WEBui również zostało naprawione. Sprawdzone na symulatorze i na BK7238. Czy ktoś może to zweryfikować na innych platformach?

test:

flags 18446744073709551615




Dodano po 38 [sekundach]: .

PR: https://github.com/openshwprojects/OpenBK7231T_App/pull/1548

Czy nie zepsuje to konfiguracji na platformach, gdzie long to 8 bajtów?

Btw, jaki był pierwotny powód, aby flagi składały się z 2 liczb całkowitych zamiast uint64_t?

insmod napisał:

Btw, jaki był pierwotny powód zrobienia z flag 2 liczb całkowitych, zamiast uint64_t?

Nie wiem.
Nie wiem. Być może pierwsza wersja miała tylko 32 flagi.

Dodano po 11 [minutach]: .

insmod napisał:

Czy to nie zepsuje konfiguracji na platformach, gdzie long to 8 bajtów?

Masz rację, zmieniono na uint32.

Dodano po 3 [minutach]: .

BTW, na której platformie dla OBK long ma faktycznie długość 8 bajtów? Czy wszystkie są 32 bitowymi mcu, czy nie?
To moja wina, jestem developerem głównie dla Win i na 64bit Win (LLP64) long jest 32bit

>>21456907 Obecnie wszystkie są 32-bitowe, ale kto wie w przyszłości. I choć long na 32bit to zazwyczaj 4 bajty, kto wie co zrobią niektóre kompilatory. Wiem, że widziałem 4 bajty długości na 64-bitowych oknach.

>>21456953
OK, dzięki uint32, flagi są gotowe na 64-bitową przyszłość .

Nie pamiętam dobrze, ale chyba zacząłem od pojedynczej 32-bitowej liczby całkowitej. Potem dodałem kolejne 32 bity i okazało się, że istnieje długotrwały błąd z ustawioną (lub odczytaną?) flagą. Był on poruszany kilka razy, ale nie doczekaliśmy się żadnej definitywnej poprawki, chyba że PR 1548 działa dobrze na wszystkich platformach?

Ok, przetestuję. Czy najnowsza kompilacja wygląda na ostateczną do testów?

Czy są platformy, którymi w ogóle nie powinienem się przejmować, bo na pewno nie zadziałają? I czy wszystkie ESP powinny być traktowane jako jeden test, czy po jednym z każdej wymaganej serii - np. jeden ESP32-C#, jeden ESP32-S# itd.

Pamiętam, że mój początkowy kod flag działał dobrze na Windowsie. Dlatego błąd nie został znaleziony przez tak długi czas...

>>21457353
To jest ostateczne. Nie ma potrzeby testowania wszystkich urządzeń, wszystkie są 32-bitowe.
Należy sprawdzić, czy funkcja strtoull() działa dobrze na głównych SDK (ESP, BL, LN). Beken jest w porządku.

Hej, mam pomysł!

Może moglibyśmy zrobić system autotestów podobny do tego z Windowsa, ale przeznaczony do uruchamiania na urządzeniach?

Na przykład umieścić go w cmd_selfTest.c i zrobić tam długą listę komend z asercjami wyników.

Następnie moglibyśmy uruchomić go na fizycznych urządzeniach, aby upewnić się, że wszystko jest w porządku.

Mogłoby to być bardzo przydatne, zwłaszcza biorąc pod uwagę różnice między platformami i takie....

Mieliśmy już problemy z tym związane, na przykład:
- time_t size (32 bit vs 64 bit)
- brakujący realloc na BL602
- dziwne zachowanie sprintf (pamiętasz statyczną stronę IP?)

>>21457368

p.kaczmarek2 napisał:

Może moglibyśmy zrobić system autotestu, taki jak ten w Windows, ale zaprojektowany do działania na urządzeniu?

.
Myślę, że nie jest to konieczne. Główne problemy są ujawniane na Win, a "specjalne" nieoczekiwane problemy i tak zostałyby wykryte przez test z bardzo małym prawdopodobieństwem.

Jesteś pewien? Podejrzewam, że nawet w tej chwili realloc jest nadal zepsuty na BL602 ... @miegapele może wiedzieć więcej na ten temat.

p.kaczmarek2 napisał:

moment realloc

Nie wiem jaki jest problem z realloc, ale jeśli ten sam problem będzie na windows, to czy selftest go znajdzie?

Nie, implementacja realloc jest zależna od platformy. Dlatego jest (jak podejrzewam) zepsuta na BL602, ale działa na innych platformach.

Powiązany problem:
https://github.com/openshwprojects/OpenBK7231T_App/pull/1529

Dlatego myślę, że możemy skorzystać z prostego autotestu, który działa na dowolnej platformie, z wpisem #define w obk_config.h, więc zajmuje 0 miejsca w wersjach Release.
Mógłby testować podstawowe rzeczy, takie jak parsowanie JSON, wykonywanie poleceń itp.

To znaczy, gdybyśmy o tym nie wiedzieli i problem nie został zaprogramowany do sprawdzenia

Dodano po 4 [minutach]: .

p.kaczmarek2 napisał:

Mógłby testować podstawowe rzeczy, takie jak parsowanie JSON, wykonywanie poleceń itp.

Ale ok, faktem jest, że zaoszczędziłoby to wiele pracy przy testowaniu nowych rzeczy na platformach innych niż te, na których były debugowane.

1548_merge_66c6fb20c815








Wszystkie ustawione flagi bez błędów, z wyjątkiem RTL-B, który miał poważny błąd. Wrócił jednak z wszystkimi flagami z wyjątkiem 1





Dodano po 3 [minutach]:

ustawienie flagi 13 i późniejsze zapisanie nie powoduje jednak twardego błędu

Dodano po 3 [minutach]: .

interesujące. z wyczyszczonymi wszystkimi flagami i ustawioną tylko flagą 13 będzie twardy błąd jeśli przejdziesz do strony głównej .

Dodano po 2 [minutach]: .

Domyślam się, że to jest to, czego nie lubi


Dodano po 16 [minutach]: .

ale niezwiązane z poprawką flag. To samo dzieje się z ogólną wersją 1.18.47 i tylko flagą 13

@divadiow Dzięki za świetny test. Tak dla pewności, błąd RTL nie jest związany z PR, czy powinienem coś zrobić?

Dodano po 1 [min]: .

divadiow napisał:

ale niezwiązane z poprawką flag. T

OK, rozumiem.

Dodaję system autotestu do budowanego urządzenia.
https://github.com/openshwprojects/OpenBK7231...mmit/a00d88b2a112c260985661cd079b7a5deba9a014

Użycie:
1. włącz ENABLE_TEST_COMMANDS w obk_config.h
2. dodaj komendę do cmd_test.c


3. dodać do drv_test.c:


4. wykonaj kompilację

5. w build run:

100 oznacza 100ms odstęp między krokami.
Działa w taki sposób, że najpierw drukuje polecenie, które uruchomi, czeka 100 ms, aż dziennik przejdzie, następnie uruchamia polecenie, następnie sprawdza wynik uruchomienia, następnie czeka 100 ms i ponownie uruchamia....

Przykładowe uruchomienie:



Najważniejszą rzeczą, na którą należy zwrócić uwagę, jest to, że jeśli jakieś polecenie ulegnie awarii, można je również uruchomić z konsoli bez sterownika testowego.

Proszę o wstępną opinię, ale także odczekaj 1 dzień przed uruchomieniem. Wkrótce to poprawię.

p.kaczmarek2 napisał:

Proszę o wstępną opinię

.
Tak, to wygląda dobrze. Zdecydowanie sprawdzę to później.

Zobacz to zatwierdzenie dla testu wyrażenia matematycznego z setChannel:
https://github.com/openshwprojects/OpenBK7231...mmit/0d18dd0a229b6de6dfd1abd2a396c8de076e40c7
I to zatwierdzenie dla niektórych podstawowych testów generowanych przez LLM:
https://github.com/openshwprojects/OpenBK7231...mmit/1b455ef82ec026f914eccb7bea1f2a0ecbc5dcb5

Dodano po 1 [minucie]:

Jednym z praktycznych zastosowań tego może być ten przeklęty błąd parsowania IP:
.

Więc to jest właściwe miejsce dla

oraz

test

Tak i będzie to wreszcie znaczące, a nie bezcelowe jak testowanie na Windows, ponieważ te funkcje są poza naszym SDK i testowanie ich na Windows nie powie nam, czy będą działać na Beken na BL602.

Dodano po 1 [godzinie] 18 [minutach]: .

Test parsowania IP:
https://github.com/openshwprojects/OpenBK7231...mmit/23e67076c3bf9b0b035ed2bb77066238277f76c9

to wszystko brzmi całkiem nieźle. Jak dokładnie działają i pomagają autotesty? Nie jestem zbyt dobry w kodowaniu, ale wydaje mi się to sensowną rzeczą. Jeśli, na przykład, współautor proponuje zmiany w kodzie w nowym PR i powodują one gdzieś problem, jak objawia się autotest? Co i gdzie zawodzi? Gdzieś w dzienniku przepływu kompilacji?

Zastanawiam się nad stworzeniem osobnego przewodnika na ten temat, ale mogę już zacząć tutaj.

Istnieją więc dwa rodzaje autotestów.
1. Autotesty tylko dla systemu Windows - są uruchamiane w symulatorze systemu Windows, znajdują się tutaj:
https://github.com/openshwprojects/OpenBK7231T_App/tree/main/src/selftest
Są uruchamiane na Githubie przy każdej kompilacji:


Te autotesty zasadniczo symulują scenariusz przypadku użycia, na przykład ustawienie diody LED, a następnie sprawdzają zewnętrznie, czy wynik przypadku użycia jest zgodny z oczekiwaniami.
Na przykład, jeśli ustawimy dwa piny PWM, oczekujemy, że pojawi się sterowanie CW i oczekujemy, że polecenie Dimmer zadziała. Oczekujemy, że pewne rzeczy zostaną opublikowane, gdy zmieni się stan światła, możemy to również przetestować. Symulujemy więc ustawienie dwóch pinów PWM, następnie uruchamiamy kilka poleceń i sprawdzamy, czy wynik jest zgodny z oczekiwaniami (na przykład, czy wyjściowe wartości PWM są zgodne z oczekiwaniami dla prawidłowego sterowania CW).

Przykład 1 - jeśli ustawimy kanał 1 na 123, czy stała $CH1 działa w skrypcie i rozszerza się do 123?

Jeśli "buffer" nie jest "123", SELFTEST_ASSERT_STRING pokaże błąd na kompilacji Github (czerwony krzyżyk zamiast zielonego znacznika wyboru).

Przykład 2 - jeśli ustawimy dwa piny PWM, czy są one poprawnie wykrywane jako światło CW? Czy światło poprawnie reaguje na komendy i ustawienia PWM?

Przyjrzyjmy się bliżej jednemu fragmentowi:
.
To w zasadzie mówi:
- jeśli masz ustawione światło CW, a OBK otrzyma komendę POWER OFF Tasmota, zmienna led_enableAll powinna mieć wartość 0 (false), a oba PWM powinny mieć wartość 0
- jeśli później otrzymamy komendę POWER ON Tasmota, led_enableAll ma mieć wartość 1 (true) i dla aktualnej konfiguracji (ustawionej wcześniej w kodzie) pierwszy PWM powinien wynosić 100%, drugi 0% (ponieważ wcześniej ustawiliśmy temperaturę 100% zimna).

Dzięki temu mechanizmowi, gdy tylko ktoś złamie oczekiwane zachowanie (na przykład doda zmianę, która sprawi, że światła CW nie będą działać), dowiemy się o tym w czasie kompilacji, ponieważ autotest to wychwyci.

2. Testy per-platform, wprowadzone wczoraj.
Narzędzie do uruchamiania testów jest tutaj:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_test.c
Polecenia testowe są tutaj:
https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/cmnds/cmd_test.c

Per-platform można uruchomić tylko na prawdziwych urządzeniach platformowych, takich jak BK7231, a nie w symulatorze .
Zostały one wprowadzone, ponieważ nie wszystko można przetestować w symulatorze Windows.
Niektóre rzeczy są per-platformowe, na przykład komenda sscanf lub realloc itp.
Mamy więc "inne" sscanf lub sprintf na każdej platformie - inne na BK7231, W800, W600....

Dlatego dodałem komendy testowe, takie jak ta:
.
To sprawdza parsowanie IP i jest to wymagane, ponieważ okazało się problematyczne, patrz implementacja:

To nie jest tylko teoretyczna próbka - naprawdę mieliśmy ten problem:

Jak widać powyżej, mieliśmy problem z sscanf, który wymaga specjalnej obsługi na W600/LN882H/Realtek, a my nie wychwyciliśmy go wcześnie.
Gdybyśmy mieli wtedy testy urządzeń dla poszczególnych platform, które obejmowałyby str do ip, wychwycilibyśmy to wcześniej.

Wyłapanie tego problemu jest niemożliwe w autotestach systemu Windows, ponieważ jest on obecny tylko na niektórych platformach z ich specyficzną implementacją.

Dzięki testom per-platform możliwe jest teraz wyłapanie tego błędu.
Jeśli skompilujesz OBK z włączonymi komendami testowymi i jeśli twoja platforma ma uszkodzony str_to_ip, to ten kod:

spróbuje przeanalizować "192.168.0.123", ale to się nie powiedzie, a następnie "if" to wykryje, więc zwróci CMD_RES_ERROR.
Później drv_test.c to wychwyci i pokaże błąd tutaj:


Autotesty są bardzo przydatne, ponieważ pozwalają szybko sprawdzić, czy wszystkie testowane funkcje działają zgodnie z oczekiwaniami. Nie trzeba konfigurować światła CW, aby sprawdzić, czy PWM są ustawione poprawnie - robi się to za pomocą autotestów Windows w SImulatorze na każdej kompilacji Github. Nie trzeba też teraz ręcznie sprawdzać każdej strony, takiej jak lokalna konfiguracja ip na każdej platformie, ponieważ testy per-platformowe również to obejmą....

Jak uruchomić autotesty?
- aby uruchomić autotesty symulatora Windows, wystarczy uruchomić kompilację online github, są one uruchamiane automatycznie
- aby uruchomić testy na platformę, skompiluj OBK z ENABLE_TEST_COMMANDS, flashuj go na swoje urządzenie i uruchom "backlog startDriver Test; StartTest 100;"

Nie miałem czasu, aby uruchomić testy per-platform, ale podejrzewam, że przynajmniej test realloc spowoduje awarię urządzenia BL602 - realloc jest znany jako problem na BL602.

dziękuję. to bardzo interesujące i wyjaśnia sprawę. fascynujące!

Teraz zróbmy demonstrację. Rozważymy hipotetyczny scenariusz, w którym ktoś przypadkowo łamie jakąś funkcję, na przykład zestaw kanałów.
Zmodyfikowałem CHANNEL_Set_Ex, aby zawsze ustawiał wartość na 0:
.
Następnie zatwierdziłem zmiany na Githubie.
Zobaczmy co się dzieje.
Właśnie się buduje, więc poczekajmy chwilę...
.
A potem otrzymujemy:
.
Jak widać, wiele autotestów nie powiodło się. Oczekują, że kanały będą działać, więc rozpoznają, że coś jest nie tak:

>>21458386
świetna robota, jak zwykle!

Dodano po 1 [minucie]: .

więc ten test symulatora kompilacji będzie automatycznie uruchamiany przy każdym PR/aktualizacji?

Dodano po 55 [sekundach]:

Czy też musi być uruchamiany ręcznie?

Symulator kompilacji i testy uruchamiane w systemie Windows nie są niczym nowym, są już w naszym Githubie od miesiąca lub dłużej. Są uruchamiane z każdym commitem.

Jedyną nową rzeczą, którą wprowadziłem wczoraj, są testy per-platform, które można uruchomić tylko ręcznie na fizycznym urządzeniu.

p.kaczmarek2 napisał:

Jedyną nową rzeczą, którą wprowadziłem wczoraj, jest testowanie na platformie, które można uruchomić tylko ręcznie na fizycznym urządzeniu.

Rozumiem. Wydawało mi się dziwne, jak test dla konkretnego HW MCU może działać na githubie

1548_merge_82ad074ae93b

brak twardego błędu, ale flaga 13 jest odznaczona po ponownym uruchomieniu, poza tym wydaje się OK na RTL8720D