В этом тексте я написал про то, как составить крохотный, но очень полезный загрузчик.
В программировании на STM32 бывает нужно сделать так, чтобы загрузчик оказался не в начале Flash памяти, а в конце.
Поэтому надо написать отдельную крохотную прошивку первичного загрузчика, которая при старте передает управление на другой адрес в физической памяти.
Всем привет, это моя первая статья, в рамках которой захотелось поделиться необычным для меня опытом. Возможно, кто-то найдёт здесь для себя что-то полезное. По работе пришлось столкнуться с крайне необычной микросхемой для коммутации высокочастотных (RF) сигналов. Одна проблема – проприетарный интерфейс управления MIPI RFFE. Появился вопрос “А как этим управлять, не имея специализированных средств?”. Ответ узнаем вместе.
Представьте себе классический кошмар системного администратора или SRE: три часа ночи, в управлении огромный кластер Greenplum на сотню сегмент-хостов, и вам нужно запустить тяжелый ETL-процесс или проверить доступность gpfdist строго одновременно на всех узлах.
Вы начинаете перебирать инструменты. Стандартный Cron? Он локальный, замучаешься синхронизировать конфиги. Ansible или SaltStack? Хороши, но требуют центрального «мастера» и стабильного SSH-соединения в момент старта. А если в дата-центре «моргнула» сеть и часть сегментов оказалась изолирована? Команда просто не дойдет.
Я решил, что миру нужен инструмент, который ведет себя как «умный почтовый ящик»: вы закидываете в него зашифрованную команду, а она сама расползается по всей сети и ждет своего часа, чтобы «выстрелить» точно в срок. Так появилась Gorgona.
В этой статье я расскажу о тернистом пути создания распределенной системы на чистом C, о том, как я боролся с «сетевым эхо» и почему это решение заставляет админов больших баз данных спать спокойнее.
Написать на Си проект прошивки для микроконтроллера STM32F407VE. В качестве кросс компилятора выбрать GCC. В качестве системы сборки использовать CMake. В качестве HAL использовать фирменный HAL от STM и CMSIS от ARM. Собирать в Windows 10.
В данном тексте я покажу как можно организовать CMake скрипты сборки, чтобы собрать прошивку для микроконтроллера STM32.
Когда логирование попадает в реальную систему, довольно быстро становится понятно, что это не про API и не про удобство вызова. Это про постоянный компромисс.
С одной стороны, хочется, чтобы система работала максимально быстро: любое логирование — это накладные расходы, и в нормальном режиме его стараются минимизировать. С другой стороны, как только возникает проблема, внезапно оказывается, что либо логов недостаточно, либо они есть, но в таком виде, что восстановить картину происходящего невозможно. В этот момент становится очевидно, что задача логгера — не просто «писать строки» максимально быстро, а помогать удерживать баланс между производительностью и диагностируемостью.
Первая проблема, которая всплывает практически сразу, связана не со скоростью, а со структурой. Лог начинает отражать структуру кода, а не структуру происходящего. Есть бизнес‑логика, есть библиотеки, есть множество параллельных операций, и каждая из них пишет что‑то своё. В итоге лог превращается в поток сообщений, где перемешаны разные задачи, и вместо «обработки конкретного запроса» мы видим просто последовательность вызовов. На небольшом проекте это ещё можно терпеть, но в серверной системе такая картина быстро становится непригодной для анализа.
Естественное желание — привязать лог не к месту вызова, а к самой задаче. Самый прямой путь — передавать контекст через параметры (например, инстанс логгера), но довольно быстро это начинает протекать через весь код и превращается в обязательный шум в сигнатурах. Гораздо более устойчивый подход — привязать контекст к потоку выполнения. В библиотеке logme это делается через thread channel:
Бесплатных IDE для разработки микроконтроллеров не так уж много, а их интерфейс, основанный на Eclipse, вызывает у меня только страдания. В итоге разработка превращается в постоянное переключение с VSCode для редактирования кода в CubeIDE для его сборки и отладки.
Но почему бы не собрать все инструменты в VSCode в едином расширении, заодно подогнав автогенерацию проектов под стиль компании/личные предпочтения? Об и будет моя первая статья. Привет, Хабр!
Тёплое зелёное свечение ИВ-11 и ИВ-6, современная электроника на STM32 и минималистичный корпус. Проект сочетает советскую эстетику 80-х с доступными современными компонентами.
Всё началось на второй паре по системному программированию. Нам дали задачу: написать CLI-утилиту для анализа логов - парсить файл, фильтровать записи по уровню ошибок, считать статистику, выводить красиво в консоль. "Ну понятно", - открыл я vim и началось мое долгое приключение...
Неделя. Две. Утилита называлась logz, она умела читать логи nginx и apache, фильтровать по уровню (DEBUG, INFO, WARN, ERROR), по дате, по IP, выводила топ адресов с наибольшим числом ошибок, рисовала простенький bar-chart прямо в терминале через unicode-символы. Только вот я сидел как-то вечером, запустил wc -l main.c - 3147 строк. И смотрел на это число минуты три с таким лицом - O_O.
Сама утилита работала. Но открывая её осознаешь что - это месиво. Одна функция process_file на 400 строк. Сегфолты раз в неделю. Valgrind как лучший друг. И каждый раз когда надо добавить фичу - сначала полчаса вспоминаешь что вообще происходит в коде.
Потом я случайно прочитал пост про Zig на lobste.rs. Заинтересовался и попробовал. Через месяц у меня была та же утилита, но теперь на 1089 строках, которая работала быстрее и не падала.
Тут я понял что вот золотая жила и расскажу о том - зачем Zig, как переписывал, где облажался и что вышло в итоге.
Прочитал статью Параллелизм с общим состоянием в Rust и обратил внимание, что её общий смысл можно выразить известной фразой: “делай как нужно, а как не нужно, делать не нужно”. Другими словами, это точно такой же совет, какой можно дать разработчику любого другого языка программирования, например С++.
И решил не продолжать дискуссию в комментариях, а написать отдельную статью с кратким описанием фундаментальной экономической модели разработки ПО, которая не способствует (и объективно не должно способствовать) массовому переходу с C/C++ на «безопасные» альтернативы. Так как из-за особенностей распределения затрат у разработчика ПО отсутствует экономическая мотивация к полному устранению ошибок, и как следствие - к переходу на использование «безопасных» языков программирования.
Давно интересовал вопрос использования 16-битного АЦП STM32H7 для обработки I/Q сигналов в реальном времени.
Почти год ушел на эксперименты реализации SDR приемника на базе Tayloe mixer и MCU STM32H723ZGT6, и вот что у меня получилось: принимаемый КВ диапазон 1...30МГц, вывод обработанного аудио через внутренний 12-битный ЦАП или вывод I/Q потока на ПК через UAC1.
В этом тексте я написал про то как наладить интерфейс командной строки (CLI) по двухпроводному синхронному отладочному интерфейсу SWD.
Посылать в прошивку команды и получать ответ.
Чтобы можно было работать примерно как с UART, только по SWD.
Это когда прошивка в коде асинхронно получает текстовую строку от PC и отправляет текст обратно в сторону PC.
В то время как одни пытаются обосновать, какой язык лучше в качестве средства обучения программированию школьников, посмотрим на вопрос с другого угла. Ведь не только языки бывают разными, также не всегда одинаковы цели обучения, методики (подходы), обучаемые. Поэтому вероятно в одних случаях может быть лучше один язык, в других — иной.
Программы часто отлаживают применяя printf-отладку.
Однако в этом есть недостаток. Со временем вывод printf сообщений становится настолько частыми и плотным, что становится просто невозможно что-либо прочитать.
Чтобы с этим бороться придумали уровни логирования Log Levels.
Суть в том, чтобы из shell консоли в run time можно было включать или отключить логи для конкретных программных компонентов. Отдельными командами вы можете увеличивать или уменьшать многословность логирования.
Это позволяет Вам сфокусировать внимание на конкретном программном компоненте и найти суть ошибки в программе или причину по которой не проходит модульный тест.
Я решил учить C не по учебникам, а через практику — сделать свою простую консольную игру. Не ради “проекта мечты”, а чтобы на собственных ошибках разобраться, как всё работает на самом деле.
Привет, Хабр!
Напомним вам об одной из самых интересных нишевых книг о Linux, изданных нами в последние годы — «Изучаем eBPF: программирование ядра Linux для улучшения безопасности, сетевых функций и наблюдаемости» от Лиз Райс. Под катом предлагаем перевод статьи Люки Кавальина (Luca Cavallin), в которой он даёт подробное введение в функции и возможности этого «фильтра пакетов». В сущности, eBPF — это де‑факто стандартный механизм для безопасного и оперативного введения пользовательского кода в ядро Linux. Статья рассказывает, как правильно обращаться с этим мощным инструментом, и какие возможности он открывает.
или как уместить Вселенную в iPhone, не привлекая внимания санитаров
Разработчики — люди в целом неплохие, но с одной странностью: когда задача кажется им большой, они добавляют слой. Потом ещё слой. Потом, в три часа ночи, смотрят на то, что получилось, и долго молчат.
Автор проекта «ЭХО» взял и убрал всё лишнее. Без предупреждения, без RFC, без голосования в команде. Остался минимальный Linux, один бинарник на Go и файловая система — всё остальное полетело в мусор вместе с базами данных, фреймворками и «чёрными ящиками» с гарантией на три года. Получилась система на 250 миллионов анкет, которая работает на обычном пользовательском компьютере и не требует звонить в поддержку AWS в два часа ночи.
Но 250 миллионов — это как-то мелко, правда? Давайте замахнёмся на Вселенную. Ну или хотя бы на Млечный Путь для начала.
Kite lang
Я написал язык программирования на C — и он работает в Termux
Почему вообще
Всё началось с мечты — написать свой собственный язык программирования. Я смотрел кучу роликов на YouTube, пытался что-то понять, но эти жалкие попытки ни к чему не приводили. В теории я знал как устроен интерпретатор — лексер, парсер, AST. Но как воплотить это в реальный код — не понимал совсем.
Потом я наткнулся на один ролик который дал мне надежду. Я вспомнил что DeepSeek неплохо пишет код и решил попробовать — первый Python проект заработал. Я был на седьмом небе от счастья.
Но тот проект был сырой и недоделанный. А когда пытаешься сделать на нём что-то серьёзное — DeepSeek выдавал код полный ошибок. Я фиксил один баг, появлялись три новых. Стало ясно что просто просить AI написать язык — не работает.
Однажды я снова сидел на YouTube и наткнулся на видео с канала WeaklyHow — он создавал свой язык программирования с помощью нейросетей. Видео было на английском, но я смотрел просто так — контекст был понятен и без перевода.
У меня уже были статьи, посвящённые эмуляции «Ну, погоди!». Цель этой статьи — рассказать, с чем я столкнулся при переносе моего эмулятора на Linux, и почему вообще я не воспользовался готовым решением. Статья может послужить туториалом для тех, кто хочет начать разбираться в библиотеке SDL2.
Всем привет, дорогие читатели! Расскажу вам о том как сделать интернет-радио на «скорую руку» без особых хлопот.
На первый взгляд задача определения выпуклости многоугольника кажется геометрически сложной.
Но на практике всё сводится к простой идее — достаточно последовательно пройти по вершинам и определить направление поворота.
В этой статье разберём, почему именно три точки позволяют определить поворот, откуда берётся формула через векторное произведение и как всё это аккуратно реализовать на C.
Также затронем важные нюансы, которые часто упускают: переполнение при вычислениях, порядок обхода вершин и обработку вырожденных случаев.
В итоге получится не просто решение, а понимание того, как работает один из базовых алгоритмов вычислительной геометрии.
