Hello World для STM32 На RP2040 для Hello World достаточно printf() и пары настроек в CMake. Со STM32 ситуация другая — действий от программиста заметно больше. Уже на старте появляются CMSIS, LL и HAL, дерево тактирования, CubeMX, программатор, аппаратный отладчик и вопрос, куда вообще выводить строку. Самый привычный вариант — UART, но им дело не ограничивается: есть semihosting, SWO и SEGGER RTT. И тут начинается практика, которая не всегда совпадает с красивой таблицей поддержки. У автора semihosting упорно не работал через J-Link Server, а SWO в CLion заработал только после обновления ПО J-Link. Так простой Hello World превращается в хороший способ разобраться, что происходит между вызовом printf() и появлением символов в терминале. Заодно становится понятнее, зачем в этой цепочке нужны интерфейсы, отладчики, серверы отладки и среда разработки — и почему один и тот же проект с разными связками инструментов может вести себя по-разному.

[ХАБРААРХИВ] Как воссоздание Dendy на ПЛИС обернулось охотой за багом, где симптом и причина оказались из разных миров Инженер решает собрать легендарную приставку из детства заново, уже на ПЛИС, и погружается в её начинку до последнего регистра. Графический процессор, спрайты, эмуляция картриджей, звук. И вот на почти готовом проекте вылезает баг, от которого можно поседеть. В игре «Принц Персии» в левой части экрана перестаёт выводиться проём двери с решёткой. Всего один графический артефакт, больше ничего не сломано. Логика гонит искать причину в графическом процессоре, и там код перепроверяется сто раз в симуляторе, пока баг сидит совсем в другом блоке. Такое отлаживать больнее всего, когда симптом указывает в одну сторону, а виновник прячется в противоположной. #хабраархив

Конференции потрясающая штука. На воркшопе рассказывал про наш прогресс. Решил помимо черрипикнутых видео, где мы конечно молодцы, показать лайв демо. Там наша модель местами работает, а местами не работает. Например, одна из необъясненных проблем это вот такие странные траектории. Это игрушечная модель которая учится кликать в одну из двух кнопок. Все траектории в данных у неё прямые и попадают прямо в середину кнопки. А потом на инференсе она заходит на цель с какого-то уголка и наворачивает невероятные вензеля. В основном всем понравилось. Но один парень сказал, что я всё делаю неправильно, траектории курсора не нужны и все такое. Я задумался и к вечеру придумал три вероятных источника этой проблемы и какие эксперименты провести, чтобы её победить.

Самые неприятные баги — это те, из-за которых система работает, потом не работает, а через пять минут снова работает, будто ничего не произошло. 😬 Именно такой баг жил на YHub целый месяц. Сегодня я наконец нашёл его причину, но сначала дам немного контекста. Уже месяц на YHub можно создавать собственные базы данных.

То есть если вы написали какое-то фронтенд-приложение и вам нужна база, то вместо того чтобы прикручивать сложные сторонние сервисы или пытаться хранить всё в Local Storage, вы можете прямо в админке своего сайта включить базу данных, создать необходимые таблицы и получить полноценный API для работы с ними.

Плюс можно создать таблицы, необходимые для аутентификации пользователей, и получить весь нужный функционал для регистрации, авторизации и так далее. 👌 В целом всё это работает хорошо. Я сам построил на этом несколько сайтов, моя игра тоже использует эту базу данных, а жена сделала несколько приложений, которые так или иначе с ней работают. 🤔 И вот как раз жена первой начала мне репортить, что иногда у неё просто пропадает таблица с рейтингом. Но после перезагрузки всё снова появляется и данные приходят. На тот момент я счёл этот баг не очень интересным. 🤷‍♂️ Подумал, что, может быть, произошла какая-то сетевая задержка или что-то было не так в её клиентском JavaScript. Я спросил: — Сейчас работает? Она сказала: — Сейчас работает. И мы такие: — Ну, работает — не трожь. Значит, всё хорошо. 👀 Но относительно недавно я прикрутил полноценный мониторинг ко всем функциям YHub. Раньше я мониторил только сам YHub и его основные модули: работает ли приложение, отвечает ли сервер. А теперь начал дополнительно проверять отдельные фичи, чтобы убедиться, что они тоже работают и ничего не отвалилось. И вот мониторинг начал ловить нестабильные ошибки. Условно, сначала он получает 200 OK: всё хорошо, база работает, данные записываются. ✅ Через пять минут приходит 404, будто база данных вообще не включена. ❌ А ещё через пять минут снова 200 OK, и всё опять прекрасно работает. ✅ Такое поведение — когда что-то работает, через пять минут не работает, а потом снова работает — это, наверное, самое неприятное, что может произойти при отладке. 😩 Баг не воспроизводится стабильно, поэтому непонятно, за что вообще цепляться. Но, вооружившись Codex, своими наблюдениями и несколькими теориями, я пошёл дебажить архитектуру и нашёл очень интересный момент. 🤔 На моём хостинге используется PHP Runtime. Чтобы всё это было безопасно, я изолирую сайты на уровне операционной системы. Для каждого окружения создаётся отдельный PHP-FPM-пул, который работает внутри собственного chroot. Благодаря этому процессы разных пользователей не должны видеть файлы друг друга. 😬 Но, когда я настраивал эту изоляцию, я пропустил одну важную настройку в OPcache. OPcache хранит в общей памяти уже скомпилированный байткод PHP-скриптов, чтобы не разбирать и не компилировать их заново при каждом запросе. Проблема была в том, что внутри каждого изолированного окружения сгенерированный API-скрипт находился по одному и тому же пути. А настройка opcache.validate_root, которая заставляет OPcache учитывать конкретный chroot, у меня была выключена. 🤦‍♂️ В результате для OPcache скрипты разных пользователей могли выглядеть как один и тот же файл. OPcache мог взять скомпилированный скрипт из одного окружения и использовать его при запросе к другому. 🤷‍♂️ В какой-то момент в кэше оказывалась скомпилированная версия скрипта сайта, на котором база была отключена. Поэтому мой сайт внезапно получал 404, хотя у него самого всё было включено и настроено. 💡 Это интересный пример того, как кэширование становится источником проблем в разработке. Кэширование — это, конечно, хорошо. Я не говорю, что его нужно избегать. Оно ускоряет работу системы и часто действительно необходимо. Но кэшировать тоже нужно с умом. В моём случае я просто забыл указать в настройках, что кэширование должно учитывать chroot пользователя, и получил вот такую интересную проблему. Причём именно мониторинг помог мне с ней разобраться. У меня были конкретные даты и время, когда всё работало, а когда отваливалось. Без мониторинга я вообще не представляю, как бы это отдебажил. 😅 Но теперь всё исправлено. После изменения настройки ошибка больше не повторялась, а мониторинг снова стабильно зелёный. 💪 Свята место | 10МДК | ВЕБМастер | YHub

Я конечно видел много способов harness для агентов, но это пожалуй самый прикольный: Парень придумал для агентов papercuts, чтобы они могли жаловаться на любую ерунду которую нашли во время выполнения задачи Потом по этим записям можно понять какие узкие места в репо замедляют работу, например: где есть расхождение доков, какие скрипты перестали работать и тд. Просто нужно добавить в AGENTS․md эту инструкцию:

# Log papercuts When you encounter small friction while working—a failed tool call, confusing setup, flaky command, stale cache, misleading error, missing helper, or non-obvious gotcha—record it in `PAPERCUTS.md`. Create the file if it does not exist. Append one entry in this format: ## YYYY-MM-DD HH:MM — <model> <What you were doing> → <what got in the way>. Include a possible cause or fix when useful. Log papercuts proactively when they occur, but do not interrupt the main task. Do not add duplicate entries. Papercuts are minor workflow friction, distinct from completed-work logs and real bugs or tracked issues.

Или еще проще, на гитхабе есть специальный CLI-тул под это. Ну и само по себе интересно читать как агент на естественном языке ругается на глупые проблемы☕️ @tips_ai