Вместе с кодом игры опубликованы сетевой сервер, сетевые сервисы для авторов модов и редактор миссий. Для разработки модов предлагается использовать язык SQS. Игра была опубликована в 2001 году, после чего переиздана в Steam в 2011 году. Опубликованный код модернизирован для поддержки стандарта C++20 и переведён на сборку с использованием CMake и Clang. Помимо Windows добавлена поддержка платформы Linux. Для рендеринга графики используется OpenGL 3.3.
Игровые ресурсы, включая модели, текстуры, звуки и миссии, опубликованы отдельно под лицензией APL‑SA (Arma Public License Share Alike), допускающей использование и распространение в некоммерческих целях. Игровые данные можно извлечь из бесплатной демо‑версии, поставляемой через Steam. Демо‑версия поставляется для Windows и Linux, и представляет собой готовую сборку на основе опубликованного кода.
Как разработать Linux-драйвер реального устройства для платформы RISC-V
Если вы хотите лучше разобраться во внутреннем устройстве Linux и узнать, как его ядро взаимодействует с физическими устройствами, то приходите на бесплатный офлайн мастер-класс YADRO. Вместе пройдем полный цикл создания драйвера дисплея LCD1602 для VisionFive2: от теории до добавления новых функциональных элементов и запуске на одноплатнике.
Что будем делать:
загрузим информацию о дисплее в ядро через Device Tree Overlay;
выведем текст на дисплей через драйвер Linux для embedded-систем;
считаем содержимое дисплея из ядра Linux и выведем в консоль;
научимся управлять подсветкой и курсором через интерфейсы Linux Kernel Driver;
займемся обработкой IRQ по нажатию кнопки;
разберем типичные ошибки при разработке Linux-драйверов.
Мастер-класс проведет Никита Косырев, инженер-программист группы системного ПО в YADRO. Никита — энтузиаст embedded-систем и архитектуры RISC-V, несколько лет занимался разработкой драйверов периферийных устройств в ядре Linux.
Приглашаем инженеров, которые хотят лучше разобраться в низкоуровневой разработке для Linux и особенно тех, кто работает с user space-приложениями.
Мастер-класс пройдет офлайн 3 июля в московском офисе YADRO, количество мест ограничено. Участие бесплатное, но регистрация обязательна.
graphics.h — это часть библиотеки BGI (Borland Graphics Interface) родом из 1990-х. В современных IDE её нет: она несовместима с 64-битными системами и не является частью стандарта C++. Тем не менее в учебных задачах она до сих пор встречается — особенно там, где нужно быстро визуализировать алгоритм или сдать лабораторную.
Когда это оправдано
изучение основ C/C++ и хочется видеть результат за пределами консоли
разбор алгоритмов компьютерной графики
подготовка к экзамену по предмету, где преподаватель требует именно graphics.h
Для production-кода и серьёзных учебных проектов лучше сразу смотреть в сторону актуальных библиотек: SDL2 (2D, кроссплатформенная), SFML (ООП-подход, проще в освоении) или OpenGL/GLFW (если нужна 3D-графика и аппаратное ускорение).
О библиотеке
Адаптация для современных Windows называется WinBGIm — её разработал и поддерживает Майкл Мэйн, профессор Колорадского университета в Боулдере. Библиотека открыта для использования и модификации. Скачать можно на официальном сайте: winbgim.codecutter.org.
Если хочется сначала почитать вводный разбор — на Хабре есть статья с обзором WinBGIm, здесь же показан небольшой практический пример-скриншот: инженерная утилита с графическим выводом, которая впоследствии была переписана с использованием современного UI на C++.
Как запустить: общий принцип
Для работы используется адаптация WinBGIm — три файла: graphics.h, winbgim.h и libbgi.a.
Известный баг: в оригинальном graphics.h на строке 302 встречается int right=0 — это вызывает ошибку компиляции. Исправляется заменой на int txtright=0.
Dev-C++
Скопировать graphics.h и winbgim.h в MinGW64\x86_64-w64-mingw32\include
Должно открыться окно с белым кругом на чёрном фоне. Если компиляция падает с ошибкой cannot find -lbgi — проверьте путь до libbgi.a. Ошибка undefined reference обычно означает, что флаги линкера не подхватились.
Дайте посмотреть на нормальный С++ проект, созданный вайб-кодингом
Чтобы корректировать развитие PVS-Studio я заинтересован смотреть C++ проекты, созданные с использованием генеративного AI или, по-простому, вайб-кодинга. Но вот незадача: все кругом пишут про этот самый вайб-кодинг, но я не знаю, как и где искать такие открытые проекты.
Мне попадается какая-то белиберда типа enhance-client, сгенерированная за $15. Но это даже смотреть несерьёзно. По присутствию в репозитории .obj, .iobj, .ipdb файлов и прочего мусора видно, что автор не понимает, что он делает. Проект не компилируется по разным причинам, например, из-за того, что заложен какой-то огрызок файла bytes.hpp (у массива нет конца).
Если немного поправить и проверить, что удалось собрать, то там лезут перлы вида:
void enhance::modules::autototem::run()
{
....
auto env = enhance::instance->get_env();
if (!env)
{
env->DeleteLocalRef(player);
return;
}
....
}
Предупреждение PVS-Studio: V522 [CWE-476, CERT-EXP34-C, SEC-NULL] Dereferencing of the null pointer ‘env’ might take place. autototem.cpp 757
Явное разыменование нулевого указателя.
Или бессмысленные сравнения значения типа int с константой 0.1f:
int sdk::minecraft_client::get_attack_cooldown() { .... }
void enhance::modules::shield_breaker::run()
{
....
if (sdk::instance->get_attack_cooldown() > 0.1f)
....
}
Предупреждение PVS-Studio: V674 [CWE-682, CERT-FLP36-C] The ‘0.1f’ literal of the ‘float’ type is compared to a value of the ‘int’ type. shield_breaker.cpp 628
Такие ляпы нет смысла серьёзно разбирать и описывать.
Можно спросить: “А что ты хочешь от поделок за 15$?” Да, в общем-то, ничего, но вместо нормальных проектов попадаются они. Мне интересно изучить большие открытые проекты нормального качества, при написании которых активно используется GenAI. А то пока ощущение, что термин “вайб-кодинг” есть, а C++ проектов нет. Или за них стыдно? :)
Если вы знаете подобные большие проекты, то присылайте ссылки на них в комментарии. Заранее спасибо.
Doom запускался на 486-м процессоре с 4 МБ RAM ещё в 1993 году.
И самое интересное - весь мир игры рендерился через BSP-дерево, binary space partition tree.
Джон Кармак строил это дерево при загрузке уровня, а не на каждом кадре. Карта заранее делилась на области, а порядок отрисовки уже был сохранён внутри структуры.
Во время рендера движку не нужно было каждый раз заново вычислять видимость. Он просто проходил по дереву.
Как это работало:
• BSP-узел делит пространство на переднюю и заднюю часть
• если игрок спереди - сначала рендерится переднее поддерево
• если игрок сзади - сначала рендерится заднее поддерево
• порядок уже задан самой структурой дерева
Именно поэтому Doom не нуждался в z-buffer.
Корректная видимость появлялась не из трюков с глубиной, а из самого порядка обхода BSP-дерева.
Очень маленький код, но за ним стоит одна из самых красивых инженерных идей в истории игровых движков.
🖥 Создатель C++ разнёс вайбкодинг: “сеньоры не хотят разгребать этот мусор”
Бьёрн Страуструп, легендарный создатель C++, в новом двухчасовом интервью резко прошёлся по вайбкодингу.
Главная претензия простая: сгенерированный код пока слишком часто выглядит красиво только на демке. В реальном проекте он приносит баги, раздувает кодовую базу, плодит уязвимости и плохо поддаётся нормальной проверке.
Особенно больно это бьёт по опытным разработчикам. Им потом приходится не “магически ускоряться с ИИ”, а читать, чинить и переписывать слоп, который кто-то нагенерировал за пять минут.
Похожая история уже достала и Линуса Торвальдса. Его буквально завалили кривыми AI-отчётами по ядру Linux: вроде бы люди “помогают”, а на практике создают шум, который мешает настоящей разработке.
Если человек не понимает архитектуру, безопасность, тесты и границы задачи, то вайбкодинг превращается не в ускорение, а в генератор технического долга.
Сеньоры не боятся ИИ.
Они просто не хотят провести остаток карьеры, разгребая чужой промптованный мусор.
В 2000-х Fisher-Price тайком сделал новый tapeout 6502 и засунул его в детскую игрушку Pixter. Автор статьи полностью разобрал всю линейку: от проклятой BEX-шины и resistive touch на BJT+R-2R-лестнице до PWM-аудио, которое «фундаментально не понимает жизнь», и кастомных melody-чипов (включая DDR-мини-синтезатор в Symphony Painter). В итоге — два полноценных эмулятора (uARM и uPixter), дампы всех картриджей, разбор native ARM callout’ов и куча цифровой археологии.
Если вам нравятся истории, где дешёвое железо побеждает здравый смысл, а реверс-инженер выходит победителем
«Драйверы устройств FreeBSD: от первых шагов к освоению ядра» — это бесплатная книга с открытым исходным кодом, которая проведёт вас от состояния «Я никогда не писал код ядра» до состояния «Я могу писать, отлаживать и отправлять драйверы FreeBSD производственного качества». Это скорее пошаговый курс, чем справочник, структурированный вокруг 38 глав, 6 приложений и десятков практических заданий, которые компилируются и загружаются в реальной системе FreeBSD 14.x, пояснил автор проекта Эдсон Бранди.
Что такое LDL? Это графическая библиотека с единым API для всех систем как старых, так и новых.
Раньше я писал её на C++98, что давало хорошую портабельность. Но сейчас я пересмотрел многие тезисы, которые декларировал на GitHub, чтобы наконец добраться до первого релиза.
Новая стратегия
Я решил выпускать релизы без реализации полного функционала (графика, звук, шрифты и т.д.) постепенно, итеративно.
Перешёл на C89 для максимальной переносимости. Это не только DOS или Windows 3.x, но и старые системы вроде Solaris, PlayStation 1 и другие.
Для первого релиза реализую минимальный базовый функционал: графику (OpenGL, Vulkan), окна и события. По возможностям аналог GLFW.
С каждым следующим релизом буду добавлять: 2D-рендер, звук, шрифты и прочее.
Лицензия и целевые платформы
Лицензия меняется на LGPLv3.
На старте поддерживаются Windows и Linux.
Качество и инструменты
При разработке использую:
AddressSanitizer (ASan)
UndefinedBehaviorSanitizer (UBSan)
Различные анализаторы кода
Я считаю, что такая стратегия полезнее, чем годами доводить библиотеку до версии 1.0 в офлайн-режиме.
Примеры и бэкенды
Добавлю десятки примеров с OpenGL 1.x, OpenGL 3.x и Vulkan.
Буду добавлять бэкенды для LDL: не только под ОС, но и поверх других графических библиотек — SDL, SFML, GLFW и т.д.
API остаётся единым для всех бэкендов.
Это позволит сразу добавить поддержку звука и шрифтов (через бэкенды), а в нативных версиях реализовывать их позже.
2D-рендер без границ
Одной из главных задач LDL я вижу создание единого 2D-интерфейса, который стирает различия между поколениями графики.
Вам не нужно думать о том, что находится в системе: современная видеокарта с Vulkan, старый ускоритель с OpenGL 1.2 или вообще только центральный процессор (Software Rendering).
Единый интерфейс: Вы используете одни и те же команды для рисования пикселей, линий и спрайтов.
Адаптивность: LDL сам выберет наиболее эффективный способ вывода изображения. На современной системе это будет аппаратное ускорение, а на «железе» без видеокарты оптимизированный программный растеризатор.
Визуальная честность: Ваш визуальный стиль останется неизменным, на чем бы он ни запускался. Это дает возможность делать игры и приложения, которые выглядят и работают одинаково и на ретро-ноутбуке, и на современном мониторе.
Философия: Машина времени в вашем коде
Зачем тратить силы на поддержку систем, которые многие считают «трупами»?
1. Борьба с цифровым забвением
Современный софт живет 3–5 лет. Мы выбрасываем железо не потому, что оно сломалось, а потому, что софт стал слишком тяжелым и ленивым. LDL — это протест против «запланированного устаревания». Я хочу, чтобы код, написанный сегодня, мог дышать в железе любой эпохи.
2. Инженерный аскетизм
Когда у тебя гигабайты памяти, ты перестаешь ценить каждый байт. Написание библиотеки под C89 для слабого железа — это духовная практика для программиста. Это возвращение к искусству находить изящные решения в условиях жестких ограничений. Каждый сэкономленный такт процессора — это дань уважения инженерам прошлого.
3. Преемственность поколений
Мы стоим на плечах гигантов, но часто забываем их имена. LDL сохраняет возможность для диалога между эпохами. Это инструмент, который позволяет современному разработчику почувствовать «металл» старых машин, не теряя связи с современными технологиями вроде Vulkan.
Итог
LDL — это Little Directmedia Layer. Он маленький не потому, что слабый, а потому, что в нем нет ничего лишнего. Это попытка создать код, который будет принадлежать не конкретной версии ОС, а истории программирования в целом.
Один API. Один код. Тридцать лет компьютерной истории.
Разработчик Александр Гомес Гайгалас (Alexandre Gomes Gaigalas), автор библиотеки coral для создания переносимых shell-скриптов, опубликовал проект C89cc.sh. Это компилятор для языка C, написанный целиком на Shell.
Компилятор поддерживает стандарт C89 и может генерировать исполняемые файлы в формате ELF64 для систем x86-64. Исходный код проекта содержит около восьми тысяч строк и открыт под лицензией ISC.
Всё, что нужно знать для начала работы в PVS-Studio
Статический анализатор PVS-Studio — это инструмент для поиска ошибок в коде на протяжении всего жизненного цикла проекта. В новой статье разберём основные особенности анализатора PVS-Studio, сценарии и варианты анализа, а также узнаем всё, что нужно знать для начала работы с инструментом.
NixOS: идея, до которой индустрия доросла только сейчас.
Кажется, NixOS наконец выходит из категории системы «для своих» и становится все заметнее в инженерной среде. Это закономерно: он очень точно попал в проблемы, с которыми команды массово столкнулись только в последние годы.
История началась в 2003 году, когда исследователь Элко Долстра и его коллеги в Утрехтском университете запустили проект Nix. Это исследовательский проект, который включал пакетный менеджер и собственный декларативный язык. Идея была сделать так, чтобы пакеты и зависимости собирались предсказуемо, не конфликтовали между собой и не превращали систему в хаос после очередного обновления. Чуть позже из этой логики вырос NixOS, где тот же подход применили уже ко всей операционной системе.
В этом и был главный поворот. Nix с самого начала смотрел на систему не как на набор вручную настроенных файлов и команд, а как на то, что можно описать целиком. Пакеты хранятся изолированно, разные версии могут спокойно жить рядом, а состояние машины задается через конфиг. За счет этого обновления становятся атомарными.
Это особенно интересно на фоне обычных Linux‑дистрибутивов. Там текущее состояние системы часто является результатом длинной цепочки действий: что‑то поставили, что‑то удалили, где‑то поправили конфиг, где‑то забыли. В NixOS логика другая: ты описываешь желаемое состояние, а система приводит машину именно к нему. Если новая конфигурация не взлетела, предыдущее состояние никуда не исчезает.
😏 Почему NixOS набирает популярность именно сейчас? Потому что индустрия наконец доросла до его сильных сторон. Чем больше у команды окружений, CI/CD, инфраструктуры как кода и цены ошибки, тем важнее воспроизводимость и предсказуемость. То, что раньше выглядело как нишевая экзотика, сегодня все чаще выглядит как очень здравый инженерный выбор.
Многие современные immutable‑системы по сути идут в ту же сторону, куда NixOS пошел еще много лет назад.
А если хочется не просто прочитать про Nix, а разобраться, как он работает на практике, приходите на наш открытый воркшоп.
📹 Открытый воркшоп в рамках ИнженеркаТех Плюс, 18 марта в 19:00 по МСК. Александр Сергеев из сообщества RULKC, Russian Linux Kernel Community, расскажет про Nix и функциональный подход к пакетам и сборке.
Если вы хотите получить полный контроль над окружением и наконец закрыть вопрос воспроизводимых сборок, этот воркшоп для вас. Разберем ключевые концепции Nix и наглядно покажем, чем он отличается от привычных систем управления пакетами.
Помогите добить реверс bike tracker на MC60 + STM32L486 – что здесь за интерфейсы и как лучше подступиться.
Больше фото в конце!
Есть у меня bike tracker infocar bikeAngel AMB02. Разобрал его и сейчас пытаюсь спокойно, без лома через колено, понять архитектуру платы, интерфейсы и нормальный маршрут реверса. По фото и маркировке пока получается такая картина:
есть SIM-слот, батарейный блок и несколько непонятных тестовых/сервисных точек.
Из того, что пока смущает –MC60 и STM32 здесь явно живут как два разных мозга, и я пока не до конца понимаю, кто кого будит, кто держит power sequencing и где именно проходит основной UART.
На плате нет «человеческих» кнопок boot/reset, поэтому неочевидно, насколько реалистично подлезть к MC60 напрямую без плясок с его boot/pwrkey линиями. Не уверен, не зашита ли вся критичная логика именно в STM32, из‑за чего идея «просто заменить SIM и жить» может оказаться слишком наивной.
Что уже удалось идентифицировать по плате:
MC60 — сотовая часть, GPS и Bluetooth а STM32L486 — управляющий MCU,
SPI flash рядом с белым разъёмом , возможный сервисный коннектор / debug-разъём;
батарейный блок выглядит как 1S Li-ion pack на нескольких параллельных банках.
Моя цель сейчас не «ломать прод», а именно картировать железо, найти UART между STM32 и MC60 — понять, где SWD на STM32. Определить, можно ли безопасно снять дамп / хотя бы проверить RDP. Понять, есть ли смысл лезть в SPI flash отдельно да и прикинуть, насколько жизнеспособен вариант со своей SIM и своим софтом. Инструменты у меня пока довольно базовые: паяльник и USB‑UART, нормального анализатора и ST‑Link пока нет. (Заказал себе пока, ST‑link v2 Clone M89 для STM).
Поэтому особенно интересны советы именно по порядку действий: с чего лучше начать, чтобы не убить плату и не потратить неделю впустую.
Прошу помощи. Не могу найти документацию на плату. Купил когда-то на а**-э*****сс, но к ней не было в комплекте вообще ничего. За время поисков удалось найти только два фрагмента схемы. Мб есть у кого такая....
P.S. Если вам будет интересно, а у меня силы и карма - то расскажу, что там и как в отдельной статье. А теперь и ответ на всех мучающий вопрос: "Почему пингвин пошёл в горы?"
На неделе вспомнил про wchar_t в Си, пока в очередной раз работал с Unicode, но в Windows. Штука… Неоднозначная.
Часть WinAPI жёстко завязана на WCHAR (wchar_t). Но в Windows он до сих пор определён размером в 16 бит. Тот же GCC на Debian мне говорит, что у него wchar_t — все 32 бита.
Т.е. перевод строки из char в wchar_t генерирует валидный UTF-16 в Windows, но UTF-32 в Linux…
Кажется, char32_t должен решить эту чехарду в будущем… Хотя бы с точки зрения размерности… Пусть это и не исправит проблемы WinAPI…
Но действительно ли так часто нужно работать с полноценным code point в Unicode? Зачем? Только чтобы посчитать общее количество символов? Это же просто сделать и на основе char!
Авторы UTF-8 Everywhere дают развёрнутый ответ на этот и многие другие вопросы. Идея хорошо проработана, есть даже прекрасный FAQ для любопытных.
На этой веб-странице собрали самые веские доводы для использования исключительно UTF-8. Везде. Всегда.
Надоело искать парные вкладки (.h/.cpp) в VS Code? Я навайбкодил расширение, которое их магнитит.
Привет! Меня всегда немного раздражала одна мелочь в VS Code.
Открываешь Source.cpp, хочешь посмотреть заголовок, а Source.h открыт где-то в конце списка вкладок или вообще затерялся среди десятка других файлов. Приходится глазами искать его или тянуться к дереву проекта.
Стандартные методы сортировки тут не помогают, поэтому я написал Tab Magnet.
Как это работает: Вы просто кликаете на файл в Explorer-е. Tab Magnet проверяет, открыта ли его "пара" (например, .h для .c или .html для .component.ts), и если да - автоматически переносит её поближе, чтобы они стояли бок о бок.
Функционал:
Знает, что заголовки лучше держать справа, а тесты — рядом с кодом.
Поддерживает из коробки C/C++, C#, Web (JS/TS/HTML/CSS) и Angular.
Можно настроить свои правила (например, для Go тестов или специфичных структур папок).
В течении нескольких последних дней активно почитывал книгу Дженса Густеда “Modern C”.
Книга будет хороша как общий справочник, набор best practices кодинга на C, да и просто посмотреть, какие трюки в C23 можно делать.
Удивительно, что столь детальную и кропотливую работу можно найти в свободном доступе. Распространяется книга по лицензии CC 4.0 в вариации BY-NC-ND. Это очень радует.
Книга структурирована по уровню вовлечённости в C. От самых базовых элементов до многопоточных программ.
Для опытных разработчиков больше всего будут интересны Takeaways. Они резюмируют текст и позволяют фокусироваться на самом интересном. В конце книги есть листинг всех Takeaways, разбитый по разделам книги.
Иногда может показаться, что для тестирования программ нужно обязательно взять монструозный фреймворк, внедрить его в свою систему сборки, а потом при каждой проверке искать, какие же assert он умеет делать.
На практике это не всегда так.
Да, мир Си — дикий запад. Но, тем лучше, всегда есть выбор.
Джон Брюер приводит превосходный пример того, каким может быть минималистичный фреймворк для тестирования. Всего пара макро и одна переменная, восхитительно!
Только что в один из своих проектов на микроконтроллере RP2040 понадобилось интегрировать графический дисплей для отображения погодной информации. Выбор пал на распространенные монохромные OLED-дисплеи разрешением 128х64 точки.
Из плюсов этих дисплеев для меня: высокая яркость и контрастность, простота интерфейса, дешевизна и высокая плотность информации в небольшом размере.
Контроллер у всех этих дисплеев стандартный - SH1106.
Свои проекты я пишу на С с использованием нативной Pico SDK. Поиск библиотеки для нужной платформы на С результатов не дал. Все, что на данный момент есть, - различные ардуино-библиотеки и микропитон.
В итоге было принято решение портировать на RP2040 одну из реализаций для STM32. Эта библиотека умеет рисовать графические примитивы в виде вертикальных и горизонтальных линий, прямоугольников пустых и заполненных, растровых изображений а также есть различные функции вывода текста и числовой информации.
Библиотека позволяет задать разрешение экрана а разворачивать экран на 90/180/270 градусов.
Изначально библиотека включала в 2 шрифта с размерами знакомест 5х7 и 7х10 точек.
Для своих целей я самостоятельно разработал большой шрифт 12х16 точек (на фото он).
Всем привет, это снова stalker320. Делаю что-то вроде анонса, я тут изучаю что появилось в C23 и думаю записать пару уроков с помощью него, так как пара новых функций выглядят теперь довольно интересными, к примеру, при объявлении перечисления теперь можно указать размер поля (: char). Вот он в исходном виде:
Компьютерное зрение для кода: что PVS-Studio разглядел в OpenCV
Что общего у компьютерного зрения и статического анализа? Оба ищут смысл в данных. OpenCV находит образы среди миллионов пикселей, а PVS-Studio — ошибки среди тысяч строк кода. Изучим же исходники крупнейшей библиотеки компьютерного зрения.
На примере 14 фрагментов кода из OpenCV предлагаю посмотреть, как статический анализ помогает избежать попадания багов в релиз и облегчить жизнь разработчикам.
Давайте посмотрим на кусок кода из проекта:
template<typename T>
struct Ptr : public std::shared_ptr<T>;
// ....
Ptr<FlannNeighborhoodGraph> FlannNeighborhoodGraph::create(....)
{
return makePtr<FlannNeighborhoodGraphImpl>(....);
}
void Utils::densitySort (const Mat &points, int knn,
Mat &sorted_points, std::vector<int> &sorted_mask)
{
// ....
FlannNeighborhoodGraph &graph = // <=
*FlannNeighborhoodGraph::create(....);
std::vector<double> sum_knn_distances (points_size, 0);
for (int p = 0; p < points_size; p++) {
const std::vector<double> &dists = graph.getNeighborsDistances(p);
for (int k = 0; k < knn; k++)
sum_knn_distances[p] += dists[k];
}
// ....
}
Если вы думаете, что использование умных указателей раз и навсегда решает проблему "висячих" ссылок и доступов к памяти, то здесь всё пошло не так. Давайте разбираться. Сейчас код работает следующим образом:
Функция create создаёт и возвращает умный указатель на тип FlannNeighborhoodGraphImpl, и его счётчик ссылок на объект равен единице;
Создаётся ссылка graph на значение этого умного указателя, при этом счётчик ссылок на объект не изменяется;
Указатель является временным объектом, и поэтому после завершения инициализации счётчик ссылок уменьшится до нуля, что приведёт к освобождению управляемого объекта. Теперь ссылка указывает на разрушенный объект;
В цикле for происходит обращение к невалидной ссылке.
В итоге код, который казался правильным, приводит к неопределённому поведению. Кроме того, эту проблему находит не только PVS-Studio, но и санитайзер. Пруф.
Для исправления необходимо сохранить умный указатель, тогда объект типа FlannNeighborhoodGraph будет жить до конца блока. Можно сделать так:
std::vector<double> sum_knn_distances (points_size, 0);
{
// get neighbors
auto graph = FlannNeighborhoodGraph::create(....);
for (int p = 0; p < points_size; p++) {
const std::vector<double> &dists = graph->getNeighborsDistances(p);
for (int k = 0; k < knn; k++)
sum_knn_distances[p] += dists[k];
}
}
Дополнительно ограничили область видимости graph, чтобы ресурс освободился после выполнения циклов.
Хотите узнать больше?
Статический анализ выявляет скрытые дефекты даже в больших работающих проектах. Какие ещё опасные фрагменты кода мы нашли в коде OpenCV? Полный разбор можно найти в отдельной статье.
Слышали ли вы про то, что злобные C и C++ компиляторы могут удалить вызов memset в конце функции во время оптимизаций? У нас даже про это есть диагностика V597.
Это давно известная, но при этом живучая потенциальная уязвимость CWE-14: Compiler Removal of Code to Clear Buffers. В следующем коде компилятор удалит заполнение памяти нулями (вызов memset), так как после этого буфер не используется. Раз не используется, то заполнение буфера с точки зрения языка C++ не имеет каких-либо наблюдаемых эффектов и, следовательно, является лишим. Т. е. его можно и нужно удалить с целью оптимизации.
Код позаимствован из статьи про проверку проекта PPSSPP.
Проблема насущная, и для её решения в стандарт C23 внесли новую функцию memset_explicit, которая теперь обязательна для реализации в стандартной библиотеке вместо memset_s. Так вот, автор предложения (Miguel Ojeda, P1315) в своём документе сослался на нашу диагностику (ссылка N3).
И похоже, что он давно про нас знает, т. к. умудрился вставить ссылку ещё аж на старый сайт viva64.
Не зря столько лет говорим про memset. Приятно, что нас уже в proposal-ы затаскивают :)
Вместе с экспертами из "ФанкСэйфети" разбирались с такими сущностями, как ГОСТ Р МЭК 61508, уровнями SIL, стандартом MISRA C, сертификацией по функциональной безопасности и т. д.
В конце была активная дискуссия, во время которой отвечали на интересные вопросы. По её итогу приводим дополнительную информацию и ссылки.
Тип недостатка: Необоснованный выбор инструментов, в том числе инструментов статического анализа исходного кода, для выстраивания и выполнения процессов РБПО.
Описание: В настоящий момент ФСТЭК России не предъявляет требования наличия сертификата соответствия к большинству типов инструментов анализа кода и архитектуры. При этом к инструментам предъявляются следующие требования: ...
Примечание 3. Был вопрос, связанный с объединением требований ФБ и ИБ в одном стандарте. Некоторые усилия в этом направлении предпринимаются, см. примеры ГОСТов ниже:
ГОСТ Р 59506-2021/IEC TR 63074:2019. Безопасность машин. Вопросы защиты информации в системах управления, связанных с обеспечением функциональной безопасности.
ГОСТ Р 71452-2024/IEC/PAS 63325:2020. Требования к функциональной безопасности и защите системы контроля промышленной автоматизации (IACS) на протяжении жизненного цикла.
Однако необходимо понимать, что у ФБ и ИБ разные цели и разные подходы, поэтому объединение технических требований может создать путаницу, и сейчас меры по объединению некоторых аспектов ФБ и ИБ носят, прежде всего, организационный характер.
Как анализировать C и C++ код без привязки к сборочной системе на Windows
Код, написанный на C и C++, может использоваться для самых разных целей. И под каждые из этих целей есть свои инструменты сборки. Например, при разработке программного обеспечения для встраиваемых систем используются специальные компиляторы и сборочные системы.
Иногда бывает так, что появляется целый "зоопарк" самописных скриптов сборки, а его последний "смотритель" уволился ещё в прошлом году (играет Гражданская Оборона — "Зоопарк").
Хотелось бы всё равно как-то анализировать такой код без необходимости разбираться в хрупкой и непонятной системе сборки. Что же делать?
На самом деле, решение есть! Смысл взаимодействия анализатора со сборочной системой состоит в том, чтобы получить необходимую для анализа информацию. Но получить её можно и другим способом: из запущенного процесса компиляции.
В новой статье посмотрим, как воспользоваться этим механизмом для ОС Windows в анализаторе PVS-Studio, и как сделать его использование в процессе разработки удобным.
Ускоренный найм для инженеров C/C++: оффер за 3 дня
Телеком-команда YADRO создает решения для мобильных сетей нового поколения: базовые станции GSM и LTE, а также весь программный стек — от низкоуровневых протоколов до систем управления. Сейчас в команде открылись вакансии инженеров, отбор на которые можно пройти гораздо быстрее, чем обычно.
SPRINT OFFER — это формат ускоренного найма: все этапы отбора проходят всего за три дня. Чтобы попасть в программу, достаточно подать заявку до 19 октября.
Software Engineer (телеком-платформа)
Вам предстоит разрабатывать платформенное решение для телеком-систем. На его основе строятся современные узлы сотовых сетей LTE- и GSM-стандартов — например, базовые станции и системы управления. В это роли вы будете:
Развивать платформу, обеспечивающую middleware-сервисы, высокую доступность и управление узлами для приложений, входящих в состав базовой станции LTE/GSM.
Разрабатывать компоненты платформы в технологическом стеке C++/Linux.
Собирать и анализировать метрики для оценки производительности продукта.
Создавать и оптимизировать высокопроизводительные каналы коммуникации между компонентами, а также работать с подсистемами временной синхронизации, управления конфигурацией инфраструктуры и компонентов.
Поддерживать средства развертывания и обновления приложений.
Разрабатывать API для взаимодействия с аппаратным обеспечением и операционной системой при конфигурации и управлении инфраструктурой.
Обеспечивать качество продукта: исправлять дефекты, писать unit-тесты, проводить код-ревью, разрабатывать техническую документацию.
Создавать инструменты, упрощающие работу других разработчиков.
Участвовать в диагностике и анализе проблем работы системы в тестовых и полевых сценариях.
Создавайте высоконагруженные системы, которые обеспечивают стандарты связи разных поколений. Работа охватывает три уровня. L1 — низкоуровневое программирование, работа с радиоканалом и сигналами, близкая к железу. L2 — логика, работа с алгоритмами и математическими моделями. L3 — высокоуровневое программирование, бизнес-логика. В этой роли вы будете:
Разрабатывать решения совместно с командой — от этапа исследования и прототипирования до коммерческого внедрения пакетного ядра сети 5 поколения (5G).
Создавать программное обеспечение для базовых станций LTE, реализуя полный стек протоколов 3GPP.
Разрабатывать спецификации и дизайн программного обеспечения.
Интегрировать решения с другими компонентами системы — как программными, так и аппаратными.
Поддерживать и оптимизировать код, обеспечивая стабильность и производительность продукта.
Исследовать и устранять проблемы, влияющие на надежность, производительность и масштабируемость системы.
Инженер по безопасности компании Fortinet представил экспериментальный инструмент KittyLoader. Это небольшой загрузчик, написанный на C и Ассемблере, который автор сам называет крайне ненадёжным и не предназначенным для практического применения.
Решение KittyLoader задумывалось как учебный проект и демонстрация базовых принципов работы загрузчиков, а не как готовое решение для использования. Исходный код проекта открыт на GitHub, любой желающий может изучить репозиторий и поэкспериментировать с модификациями загрузчика.
По словам автора, проект KittyLoader не стоит рассматривать как инструмент для реальных задач: он создан в первую очередь ради интереса и в образовательных целях. Несмотря на минимализм и очевидные ограничения, KittyLoader может быть полезен исследователям и студентам, которые хотят понять, как устроена загрузка и выполнение программ на низком уровне.
В прошлом году я помог Дмитрию Свиридкину подготовить и опубликовать цикл из 12 статей "Путеводитель C++ программиста по неопределённому поведению". Теперь этот расширенный, доработанный и обобщённый материал доступен в виде печатной книги:
Экскурс в неопределенное поведение C++ / Д. О. Свиридкин, А. Н. Карпов, – СПб.: БХВ-Петербург, 2025. – 384 с. – (Профессиональное программирование)
ISBN 978-5-9775-2073-7
Книга представляет собой обширный справочник типичных, а также очень редко встречающихся ошибок, характерных для программ на C++, Rust и других языках для низкоуровневого и системного программирования, в частности на ассемблере. Все рассмотренные проблемы так или иначе связаны с неопределенным, неуточненным и определяемым реализацией поведением языковых конструкций. Наибольшее внимание уделено неопределенному поведению, возможным признакам его присутствия в программах и методам поиска, диагностики и устранения такого поведения.
Книгу можно найти в offline и online магазинах.
Ещё какое-то количество книг я и коллеги раздадим в качестве сувениров и призов на различных мероприятиях, таких как:
В прошлой статье мы пришли к выводу, что QMP — это лучше, чем ничего. Но хочется большего — библиотеку или программу (желательно, уже готовую), которая умеет читать/писать и узнавать об изменении состояния через poll() / pselect() / select() / epoll() / read().
В таком случае для каждой модели GPIO нужен «клей», похожий на тот, что используется с chardev — мы включаем его прямо в модифицированный QEMU. Очевидное название такого «клея» — gpiodev. Вот его основные функции, которые сейчас почти полностью соответствуют GPIO UAPI в Linux:
сообщать количество линий, конфигурацию, название и потребителя каждой линии,
читать и задавать состояние линии,
отслеживать изменения состояния и конфигурации линии (вход/выход, запрос/освобождение).
«Клей» состоит из двух групп, первая — это индивидуальные для каждого модуля GPIO функции, которые gpiodev использует, чтобы запросить специфическую информацию:
LineInfoHandler() — информация о линии: имя, флаги и потребитель,
LineGetValueHandler() — состояние линии: условный 0 или 1,
LineSetValueHandler() — задать состояние линии: 0 или 1.
По аналогии с GPIO UAPI напрашиваются также функции LineGetMultiValueHandler() и LineSetMultiValueHandler() для запроса и выставления линий, но я решил ограничиться минимальным набором.
Можно ли организовать прозрачное взаимодействие с устройствами внутри QEMU — использовать те же библиотеки и инструменты, как и для реальных устройств? Читайте во второй части трилогии о долгом пути до GPIO в QEMU.
Что ты сделал для хип-хопа IT-инфраструктуры в свои годы? Писал UEFI и BMC для высоконагруженного оборудования
В YADRO есть распределенная команда, которая разрабатывает и сопровождает собственные программные реализации UEFI (BIOS) и BMC. Для самого разного оборудования — от серверов до телеком- и клиентского оборудования.
Реализуют программную поддержку новых аппаратных продуктов компании, определяют протоколы и методы взаимодействия между программными и аппаратными компонентами продуктов YADRO.
Проводят верификацию микрокода и выполняют проверку прошивок микросхем всех продуктов компании. Выстраивают стратегию тестирования.
Исследуют новые программные и аппаратные технологии для применения в продуктах. Рефакторят код для повышения производительности.
Придумывают методы безопасного обновления прошивок BIOS и BMC, чтобы обеспечить минимальный или нулевой даунтайм.
Добавляют новые фичи и меняют существующие — от WebUI до политик управления аппаратными компонентами.
Команде нужно больше инженеров — разработчиков на С/C++, тестировщиков, автоматизаторов и техлидов. Знакомься с вакансиями на сайте и вовлекайся в трушные инженерные задачи на современном технологическом стеке.
Решил по фану реализовать конвертор милей в километры на C. Ссылка тут.
Advanced distance converter: miles to kilometers
Usage: ./bin/fib_miles2km [OPTIONS] [distance]
Options:
-h, --help Show help information
-f, --fib=ARG Convert miles to km using basic Fibonacci
-b, --basic=ARG Convert miles to km using standard formula
-i, --fib-interp=ARG Convert using Fibonacci interpolation
-c, --fib-cache=ARG Convert using cached Fibonacci
-g, --fib-golden=ARG Convert using golden ratio
Предлагаю два варианта, которые я условно решил назвать MMIO и PCI. Последний — тоже MMIO, но в QEMU они добавляются разными путями. Начнем с сердца любой MMIO-модели — апертуры.
Апертура и адресное пространство
Как я упоминал в одной из своих статей, любое MMIO-устройство — это MemoryRegion с заданными шириной доступа и размером. Для того, чтобы он был виден CPU или другому устройству, такому как DMA, его нужно разместить в соответствующем адресном пространстве — например, пространстве, назначенном для cpu0:
Фактически это означает, что все семейство инструкций Load/Store будет вызывать mmio_gpio_register_read_memory()/mmio_gpio_register_write_memory() при совпадении адреса чтения/записи с адресом региона в адресном пространстве.
Передаваемые аргументы и возвращаемое значения интуитивно понятны. Отмечу, что hwaddr addr — это адрес относительно начала нашего региона, а не абсолютный адрес.
Нам остается лишь создать устройство и добавить его регион в файле машины:
Почти десять лет назад Никита Шубин, ведущий инженер по разработке СнК в YADRO, сделал возможность чтения и записи GPIO для QEMU. Читайте первую часть трилогии о долгом пути до GPIO в QEMU.
В языке C (и C++ тоже) существуют три различных типа: char, unsigned char и signed char.
При этом типы unsigned char и signed char предназначены для хранения чисел. "Предназначены" стоит воспринимать как "рекомендуется использовать для этих целей", фактически, программист волен в этих типах хранить и, выражаясь терминами языка Си, символы.
Когда выбрать unsigned char, а когда signed char? Нужно подумать сколько значений может принимать ваша переменная. Например, если вы храните результат ввода с клавиатуры и у вас вообще не стоит проверка на длину введенного числа, то ... То ваша программа порочна. Следует ограничивать предельную размерность всех данных. Итак, если у вас пользователь вводит число из диапазона [0..255], тогда используйте unsigned char. Если у вас переменная может быть в диапазоне [-128..127] то используйте signed char. И так далее. Если у вас числа уже не помещаются даже в uint64_t, гуглите Длинная арифметика.
Тип char предназначен для хранения только символов. В зависимости от настроек компилятора char при компиляции транслируется или в signed char или в unsigned char. Хранение чисел в char возможно, но является признаком быдлокода.
char a = 'a'; //верно
char b = 200; //задумайтесь, может тип указать как uint8_t ?
Отдельно хочу отметить, что в 1999 году уже до всех дошло, что каждый раз писать ансигнед чар долго, очень долго. Были введены синонимы (typedef) в файле stdint.h
typedef unsigned char uint8_t;
typedef signed char int8_t;
Я рекомендую вам использовать эти синонимы вместо длинных названий сигнед чар и ансигнед чар.
К слову. Крайние значения для каждого типа хранятся в limits.h. Я напоминаю, что использование магических чисел - плохая практика. Поэтому обратите внимание на возможность написания UCHAR_MAX вместо 255 и так далее см. вики
Для тех, кто пишет код под 8-bit архитектуры (привет, atmega) но планирует в дальнейшем переход на другие платформы, обратите внимание на такие типы, как uint_least8_t...
Главной особенностью LLVM является промежуточное представление кода (англ. Intermediate Representation, IR), форма, которую использует LLVM для представления кода в компиляторе. LLVM IR был разработан для выполнения функций промежуточного анализа и преобразований внутри оптимизатора компилятора. Ее создание имело целью решение множества специализированных задач, включая поддержку легковесных оптимизаций среды выполнения, кроссфункциональные и межпроцедурные оптимизации, полный анализ программы и агрессивные реструктурирующие преобразования. Промежуточное представление кода определено как язык первого порядка с четкой семантикой.
IR (Intermediate Representation) в контексте LLVM — это промежуточное представление кода. Это низкоуровневое, независимое от платформы и типобезопасное представление программного кода, которое используется в качестве промежуточного языка между интерфейсной частью и серверной частью компилятора.
Этот код LLVM IR соответствует следующему коду на языке C, обеспечивающему возможность сложения целых чисел двумя разными способами:
unsigned add1(unsigned a, unsigned b) {
return a+b;
}
// возможно не самый лучший способ сложения двух чисел
unsigned add2(unsigned a, unsigned b) {
if (a == 0) return b;
return add2(a-1, b+1);
}
Как видно из этого примера, LLVM IR — низкоуровневый RISC-подобный набор виртуальных инструкций. Как и настоящий набор инструкций RISC, он поддерживает линейные последовательности простых инструкций (сложение, вычитание, сравнение и ветвление). Эти инструкции имеют трехадресную форму. Это значит, что они берут некоторое количество входных данных и вычисляют результат в другом регистре. LLVM IR поддерживает метки и в целом выглядит как необычная форма языка ассемблера.
Строго говоря, промежуточное представление LLVM является четко определенным и единственным интерфейсом оптимизатора. Это означает, что всё, что необходимо знать, чтобы писать фронтенды для LLVM, это: что такое LLVM IR, как он работает и какие инварианты ему необходимы. Так как LLVM IR имеет текстовую форму, то имеет смысл создавать фронтенд, который выводит LLVM IR в виде текста, а затем отправляет его на оптимизатор и необходимый генератор кода при помощи каналов Unix.
Мы все с вами привыкли, что в питоне можно "зарайзить" исключение в любой момент: raise Exception Но, что если в какой-то момент времени мы не можем вызывать исключение?
Простейший пример: что произойдет при запуске такого скрипта?
# ex.py
class BrokenDel:
def __del__(self):
raise ValueError('del is broken')
obj = BrokenDel()
del obj
print('done!') # будет ли выведено?
Тут может быть два варианта:
Или del вызовет ValueError и программа завершится
Или случится какая-то магия, ошибка будет вызвана, напечатается, но программа продолжится
» python ex.py
Exception ignored while calling deallocator :
Traceback (most recent call last): File "/Users/sobolev/Desktop/cpython/ex.py", line 3, in __del__ raise ValueError('del is broken')
ValueError: del is broken
done!
Знакомьтесь – unraisable exceptions 🤝
Как оно работает?
В некоторых местах C кода у нас есть необходимость вызывать исключения, но нет технической возможности. Пример, как выглядит упрощенный dealloc для list?
static void
list_dealloc(PyListObject *op)
{
Py_ssize_t i;
PyObject_GC_UnTrack(op); // убираем объект из отслеживания gc
if (op->ob_item != NULL) {
i = Py_SIZE(op);
while (--i >= 0) {
// уменьшаем счетчик ссылок каждого объекта в списке
Py_XDECREF(op->ob_item[i]);
}
op->ob_item = NULL;
}
PyObject_GC_Del(op);
}
А, как вы можете знать, чтобы в C коде вызвать ошибку, нужно сделать две вещи:
Взывать специальное АПИ вроде PyErr_SetString(PyExc_ValueError, "some text")
И вернуть NULL как PyObject * из соответствующих АПИ, показывая, что у нас ошибка. Если вернуть NULL нельзя, то мы не можем поставить ошибку в текущий стейт интерпертатора. А тут у нас void и вернуть вообще ничего нельзя. Потому приходится использовать вот такой подход с unraisable exception
Они создают ошибку, но не выкидывают её обычным способом, а сразу отправляют в специальный хук-обработчик. Данный хук не производит классическое "выбрасывание" исключения, а просто его печатает по-умолчанию. Ниже посмотрим, как его можно кастомизировать.
В питоне оно используется где-то 150 раз. То есть – прям часто. Примеры:
Ошибки при завершении интерпретатора, попробуйте сами:
Бета-тестирование: обновлённый парсер для анализа кода на языках C и C++
Уже несколько месяцев наша команда активно тестирует новую версию парсера, и мы достигли значительного прогресса. Благодаря отзывам пользователей, мы смогли выявить и устранить множество неточностей в работе анализатора. Однако наша цель — создать максимально надёжный инструмент, поэтому мы продолжаем процесс тестирования и приглашаем вас присоединиться.
Уже больше года команда разработки PVS-Studio кропотливо работает над обновлением собственного парсера для анализа кода на языках C и C++. Это большое обновление, хоть и не видно для большинства пользователей. Оно служит фундаментом для дальнейших усовершенствований анализатора.
Отличная новость для пользователей Linux: по вашим многочисленным просьбам мы добавили возможность тестирования на Linux! Теперь пользователи обеих операционных систем (Windows и Linux) могут помочь нам в улучшении продукта. Если вы ещё не участвовали в тестировании, сейчас самое время присоединиться!
До 6 июня2025 года вы сможете протестировать специальную версию анализатора. На этом этапе для нас крайне важна обратная связь от пользователей. К релизу мы хотели бы удостовериться, что новый компонент не приведёт к существенному замедлению анализа или нестабильности у пользователей.
Как присоединиться к тестированию?
Просто заполните специальную форму на нашем сайте. В ответном письме вы получите подробную информацию о тестировании, инструкцию по установке тестовой версии и, при необходимости, временную лицензию на PVS-Studio.
Расскажите о своём опыте!
Если во время использования анализатора вы заметите баги, падения, странные срабатывания или замедление, пожалуйста, сообщите нам об этом! Для этого вы можете ответить на письмо, которое мы присылали ранее, или написать через форму обратной связи. Любые отзывы, баг-репорты и предложения будут очень полезны для нас.
Тяжела и неказиста жизнь простого программиста статических анализаторов кода
Команда PVS-Studio, содействуя разработке методики испытаний статических анализаторов под руководством ФСТЭК, составляла некоторые синтетические тесты. Писать синтетические тесты сложнее, чем кажется, и с их достоверностью всегда масса нюансов. Я никогда не любил синтетические тесты и продолжаю их не любить. Но что делать, они тоже нужны, когда речь заходит о необходимости подтвердить, что в анализаторах реализован определённый набор технологий.
Даже зная и понимая нюансы составления синтетических тестов, мы всё равно наступили на собственные грабли! Переиграли сами себя :)
Есть составленные нами тесты, в которых в функцию srand или её аналог передаётся константное значение. Это приводит к тому, что функция rand каждый раз будет генерировать одинаковую последовательность псевдослучайных чисел. Такой код, согласно ГОСТ Р 71207-2024, п. 6.3.г, может являться ошибкой некорректного использования системных процедур и интерфейсов, связанных с обеспечением информационной безопасности (шифрования, разграничения доступа и пр.).
Когда тесты подготавливались в Compiler Explorer, всё работало: PVS-Studio выдавал предупреждение V1057. А сейчас, когда код мило и скромно лежит в файлах, не работает. На Compiler Explorer работает, а вне — нет. Магия. Уже собрались баг в анализаторе искать.
Ах нет, всё просто. Файлы с тестами называются test_err_*.cpp. И в детекторе срабатывает исключение N4: "Находимся в файле, содержащем в названии слова check/test/bench". Тьфу. Причём получается, что анализатор прав: это действительно тест, а не настоящий баг :) Вот оно, несовпадение реальности и синтетических проверок в действии. Выкрутимся как-нибудь, но решил описать, так как случай интересный.
Зачем такое исключение? При разработке анализатора самое важно состоит не в том, чтобы выдать предупреждение, а в том, чтобы постараться не выдать лишнее. У всех анализаторов ложноположительных срабатываний всегда больше, чем хочется.
При экспертизе коллекции проектов стало ясно, что если это файлы с тестами, то писать srand(константа) абсолютно нормально. Более того, так специально делают, чтобы тесты вели себя повторяемо от запуска к запуску. Вот и было принято решение сделать соответствующее исключение. Теоретически это может скрыть реальную ошибку, но на практике в большой коллекции проектов, на котором мы прогоняем новые диагностические правила, такого не было. Зато в юнит-тестах этих проектов такое встречалось часто, и, соответственно, предупреждение оказывалось бессмысленным.
Был рад поведать немного интересного из жизни разработчиков статических анализаторов кода. А если хочется послушать что-то ещё, приглашаю на подкаст "Статический анализ по серьёзному" с моим участием 27 мая в 19:00 по Москве.
Предлагаю Вашему вниманию мой авторский учебник по программированию микроконтроллеров.
Всё утро его писал.
Называется "Практические Аспекты Программирования Микроконтроллеров."
Эта книга адресована всем нынешним программистам микроконтроллеров, студентам технических ВУЗов, а также всем тем, кто думает заниматься программированием микроконтроллеров. По жанру больше похоже на Art House.
Представлены основы программирования микроконтроллеров. Изложены правила составления исходного кода и организации программ для микроконтроллеров. Из каких частей состоят полноценные прошивки? Какие шаблоны проектирования выбирают для микроконтроллеров? Показано, как собирать прошивки, отлаживать код, генерировать документацию, тестировать код, организовать работы. В конце каждой главы даны контрольные вопросы, тесты и практические задания.
Эта книга станет для вас компасом в мире программирования микроконтроллеров.
Есть две версии учебника: censored и unleashed. Версию UnLeashed я буду высылать только под NDA в ответ на сообщение.
В версию UnLeashed (без цензуры) добавлены ещё 3 главы "Вы в самом деле хотите стать программистом микроконтроллеров?" "Особенности российского национального программирования микроконтроллеров." и "Градация Навыков в Embedded Программировании"
Учебник постоянно и непрерывно улучшается: исправляются найденные опечатки, добавляются новые главы и иллюстрации. Поэтому последняя версия лежит на git hub.
