C *

Как только я узнал, что книга Making Embedded Systems 2nd Edition (русская версия: «Создание встраиваемых систем. Паттерны проектирования отличных программ. 2-е издание») доступна для предзаказа, я не раздумывая отправился на Amazon и раскошелился за неё.

Некоторое время я занимался самообучением в различных областях, связанных с электроникой и разработкой встраиваемых систем, но в совершенно произвольном и никак не организованном ритме.

Рассчитывал, что эта книга даст мне хороший каркас, на базе которого можно будет формализовать мой рост и обучение.

Я сразу примерно представлял, о чём будет книга, и полагал, что сначала научусь с её помощью настраивать среду разработки для различных микроконтроллеров класса STM32, а потом, отталкиваясь от материала книги, смогу перейти в любую область разработки, которая к тому времени будет меня больше всего интересовать.

Просмотрев на сайте O'Reilly предметный указатель и выложенные для просмотра главы, я обнаружил, что такой «конфигурационной» главы в книге нет. Также в предисловии прямо рекомендовалось не прыгать по книге от главы к главе, а проработать её всю по порядку.

Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень) и алгоритмах на языке C!

Идея написать эту статью зародилась из моего поста, после него я начал серию статей, которая раскрывала много интересных моментов — от математических алгоритмов и оптимизации до ГПСЧ.

Если вы видите эту статью, значит еще не все тайны C раскрыты. В этой статье будет еще больше свежих хаков, фанов, трюков, еще больше магии и скорости! А также нетипичных алгоритмов и структур данных, что позволит вам почерпнуть и полезную информацию тоже!

Добро пожаловать в новую часть. Прошу под кат — там будет жарко, быстро и очень, очень интересно.

Мы привыкли обсуждать микросервисную архитектуру с точки зрения границ сервисов, ответственности команд, масштабируемости и отказоустойчивости. Мы спорим о том, как правильно нарезать домен, где провести границы и какие сервисы должны взаимодействовать напрямую.

Но есть более фундаментальный вопрос - кто в системе определяет правила игры?

В реальных финтех-системах бизнес-логика часто начинает зависеть от того, как именно разложены микросервисы. Допустимость действий формируется не в одном месте, а распределяется по цепочке:

- часть проверок живeт во фронтенде

- часть - в API,

- часть - в промежуточных сервисах

- часть — во временных проверках, добавленных после инцидентов

Добавили новый сервис в цепочку - и изменилось поведение.

Вынесли проверку в отдельный процессинг - и появились состояние гонки.

Перестроили оркестрацию - и неожиданно стала недоступной операция, которая раньше работала.

В этот момент происходит архитектурный перекос - не бизнес-процесс определяет систему, а структура сервисов начинает определять поведение процесса.

Для финтеха это особенно критично. Допустимость действия - это не просто проверка прав. Это функция состояния процесса, версии правил, контекста операции и регуляторных ограничений. Если эта допустимость зависит от связности сервисов или порядка их вызова, система становится хрупкой и уязвимой, и тогда, начинается разговор о подходе, в котором бизнес-логика централизуется, версионируется и становится инвариантной к физической архитектуре.

Мы отвлекаем существенные ресурсы в поисках решения для проблем.

Десятилетия терминальных мультиплексеров, одна хроническая боль и маленькая тулза на C, которая наконец всё починила.

Обзор инструментов отладки встроенного ПО: программаторы (JLink, STLink, CMSIS-DAP, BlackMagic), GDB-клиенты и серверы, формат ELF/DWARF. Разбирается цепочка взаимодействия между IDE, GDB, OpenOCD и физическим программатором — от общих принципов до конкретных решений.

На почти каждой Linux-машине в мире живёт один маленький бинарник. Весит несколько мегабайт, несколько десятков тысяч строк кода, поставляется со своим собственным конфигурационным языком, и CVE-шек за ним накопилось столько, что хватит на хорошую таблицу с фильтрами. Большинство из нас запускает его по десятку раз в день, не задумываясь.

Этот бинарник — sudo.

В мире Docker-контейнеров, эфемерных CI-раннеров и Kubernetes-подов, которые живут тридцать секунд и умирают без предупреждения, большая часть того, что умеет sudo, попросту не нужна для той работы, ради которой мы его вообще вызываем.

Вот о чём эта статья: что это за работа, как она обросла такой сложностью, и как маленькая программа на C справляется с ней лучше.

В этом тексте я написал про своеобразный фильтр нижних частот.

Это гистерезисный фильтр на триггерах Шмитта.

Функцию rand из стандартной библиотеки языка Си для генерации псевдослучайных чисел, наверное, не ругал только ленивый. В довольно известном докладе Rand considered harmful рассказывалось о проблемах с переносимостью, ограниченным диапазоном, многопоточностью, качеством и т.п. Иногда в учебниках упоминают о том, что алгоритм в rand может быть не очень качественным, иметь проблемы с младшими битами, периодом, прохождением статистических тестов. Но крайне редко можно увидеть разбор конкретных критериев, выявляющих дефекты генераторов. В этой статье я постараюсь наглядно показать не просто отдельные недостатки rand, lrand48 и random из glibc, но их полную непригодность для каких-либо вычислений в принципе. Также вы увидите превосходство поточных шифров над minstd, линейным конгруэнтным генератором из 1980-х, не только в качестве, но и в производительности.

В начале 2021 года я взялся написать игру для компьютера, которому тогда было уже 40 лет — речь о его благородии Commodore 64. Релиз игры Cab Hustle наконец состоялся осенью 2022 года, после того, как я в течение нескольких месяцев эпизодически добивался по ней некоторого прогресса. В начале 2023 года я также выпустил версию этой игры для ПК.

Есть утилита для автоматического выравнивания отступов в исходных кодах. Называется astyle.exe.

В этом тексте я покажу, как работать с утилитой Astyle.

Приветствую! В этой статье я расскажу, как мне удалось запустить DOOM на осциллографе Siglent SDS5034X. Для этого пришлось найти шелл (вендор получил мой репорт), адаптировать систему ввода игры под энкодеры на лицевой панели и вывести звук на встроенную «пищалку».

Недавно пришлось собирать ffmpeg под Windows компилятором MSVC. И знаете — я чуть не помер. Официальная документация по сборке проекта под Windows безнадежно устарела. В Интернете есть даже статьи, которые так и заявляют: "Официальная документация по сборке ffmpeg под Windows безнадежно устарела — вот как теперь это делается". И смех в том, что эти статьи уже тоже устарели и не дают работающего решения "press X to compile".

Поэтому я просто оставлю здесь инструкцию, которая работает на февраль 2026. И, возможно, устареет, как и все предыдущие. Но вы тогда мне просто об этом напишете, и я попробую актуализировать эту инструкцию.

Tarantool – это in-memory СУБД с открытым исходным кодом, разрабатываемая VK Tech. Существует два способа разработки приложений для Tarantool. Как и к большинству СУБД, к Tarantool можно подключаться из внешнего приложения по TCP/IP. С этой целью для многих популярных языков программирования (включая Go, Python, C#, С++, Java и др.) разработаны соответствующие коннекторы. Это – первый способ.

Кроме этого, Tarantool обладает замечательной особенностью: он позволяет запускать бизнес-логику на встроенном сервере приложений. В этом случае пользовательский код исполняется в одном адресном пространстве с данными, что обеспечивает высокое быстродействие. Это – второй способ.

Если мы ведем разработку для встроенного сервера приложений Tarantool, то выбор языков программирования более ограничен. Основным языком программирования, в этом случае, является Lua. Также, часть логики может быть реализована на C/C++. Но набор доступных языков расширяется. Например, с некоторого времени, поддерживается Rust. Помимо этого, Tarantool может выполнять Wasm-приложения. Скоро код библиотеки для разработки на Wasm будет открыт.

Tarantool – высокопроизводительная СУБД, часто используемая для построения highload-систем. Какой из вариантов разработки позволяет достичь максимального быстродействия (которое в таких системах будет не лишним)? В настоящей статье я хотел бы рассмотреть возможные способы вызова C-кода из Lua/LuaJIT/Tarantool (в режиме сервера приложений) и то, как это может ускорить и без того быструю СУБД.

Недавно на работе мы столкнулись с большим потреблением памяти в игре. Связано оно было с хранением большого количества информации о террейне и свойствах его клеток, которое нужно игре для разных геймплейных расчетов. Проблема насущная, особенно остро проявляется как раз в больших массивах или матрицах с большими размерностями.

Довольно типичный случай — у вас есть вполне себе нормальная структура, которая хранит информацию об одном объекте. Но самих объектов очень и очень много. Скажем, у вас 1000x1000 клеток террейна. А это уже целый миллион объектов! И вот ваша структура размером с несчастные 32 байта множится миллион раз и разрастается до объемов 30.5 Mб оперативной памяти.

Эта статья — она не про умные решения этой проблемы, она чуть приземленнее. Прежде чем приступать к дорогостоящим по времени и ресурсам переделкам, стоит совершить, так сказать, нулевой шаг оптимизации - попробовать оптимизировать саму структуру или класс, хранящий информацию, так, чтобы он стал занимать меньше места. Сэкономим на спичках!

Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень) и алгоритмах на языке C!

Если вы видите эту статью, значит еще не все тайны C раскрыты. В этом материале будет еще больше свежих хаков, фанов, трюков, еще больше магии и скорости! А также нетипичных алгоритмов и структур данных, что позволит вам почерпнуть и полезную информацию тоже.

Добро пожаловать в восьмую часть. Прошу под кат — там будет жарко, быстро и очень, очень интересно.

Привет, Хабр! Недавно я задумался: Python — не единственный инструмент, которым я хочу оперировать в своих инструментах. Python, понятно, легко освоить и он применяется везде, но язык-то не идеальный! Ресурсов требует много, да и время выполнения не ахти, а учитывая нынешние темные времена... Мне нужно что-то получше. В общем, тут я вздумал попробовать Си.

Как Вы могли заметить, у микроконтроллеров STM32F4 секторы NOR Flash памяти обладают разным размером: 16kByte(4 шт), 64kByte (1 шт), 128kByte ( 7+ шт.).

Это накладывает определенную специфику на программирование микроконтроллеров STM32F4.

Из каких секций обычно состоит Flash память микроконтроллерной программы?

В этом тексте я предлагаю простое решение проблемы разметки памяти для случая работы с микроконтроллерами STM32F4.

Приветствую всех, кто хочет делать свой код быстрым и оптимальным. В этой статье мы расссмотрим один из способов, как можно просто и легко оптимизировать программу на C++ при работе со структурами/классами, почти не меняя код.

Приветствую всех читающих это продолжение недавней статьи про мои изыскания в мире программирования отечественного микроконтроллера К1946ВК035 в качестве регулятора оборотов бесколлекторных двигателей.

Ровно полгода назад, 18 августа 2025 года, я опубликовал здесь свою первую статью о портировании прошивки AM32 на отечественный микроконтроллер К1946ВК035.

Ссылка на статью - https://habr.com/ru/articles/938128/

Те, кто читал ту статью (а таких людей, уверен, немного), помнят: не весь функционал удалось портировать с сохранением исходной производительности из-за некоторых ограничений в работе периферийных модулей отечественного микроконтроллера.
Напомню суть проблемы: микроконтроллер слишком часто уходит в прерывания для обработки входящих сигналов DSHOT, которые мы пытались обрабатывать сугубо софтварно, без применения DMA (но с небольшими хитростями). Отсюда и проблемы со своевременной обработкой сигналов других частей программы.