C++ Depth

Проектирование на основе политик — сборка поведения во время компиляции

Mon, 02 Sep 2024 00:00:00 +0000

Что решает проектирование на основе политик

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

Параметр шаблона для каждой оси — множество специализаций.
Флаги и switch во время выполнения — накладные расходы на каждом вызове.
Виртуальные базовые классы — стоимость vtable, принудительное выделение в куче.

Проектирование на основе политик (популяризованное Андреем Александреску в Modern C++ Design) заменяет все три подхода на классы политик как параметры шаблона. Каждая политика инкапсулирует одну ось поведения. Хост-класс компонует их с нулевыми накладными расходами во время выполнения.

Шаблонное метапрограммирование и концепты C++20

Mon, 26 Aug 2024 00:00:00 +0000

Для чего нужно шаблонное метапрограммирование

Шаблонное метапрограммирование (TMP) позволяет писать код, параметризованный по типам — и ограничивать, какие типы допустимы. Цель — ловить ошибки типов на этапе компиляции, а не во время выполнения, и генерировать специализированный код на тип без его ручного написания.

Практические применения:

Принять std::span<uint8_t> и std::vector<uint8_t> в одной функции
Ограничить контейнер тривиально копируемыми типами (безопасны для DMA-передачи)
Включить разные ветви кода в зависимости от того, является ли тип знаковым или вещественным
Абстракции с нулевой стоимостью через if constexpr

Трейты типов — запрос типов на этапе компиляции

<type_traits> предоставляет предикаты о типах:

Стирание типов без виртуальных функций — внутренности std::function и самодельный вариант

Mon, 19 Aug 2024 00:00:00 +0000

Что решает стирание типов

Шаблоны дают типобезопасность и нулевые накладные расходы — но дублируют код для каждого типа и не могут храниться в гетерогенных контейнерах.

Виртуальный вызов даёт полиморфизм времени выполнения — но требует наследования от базового класса, которого у вас может не быть.

Стирание типов даёт оба: хранить объекты любого типа за одним интерфейсом, не требуя от хранимых типов ни от чего наследоваться.

std::function, std::any и std::shared_ptr<void> — всё это стирание типов.

Qt для встраиваемого HMI — паттерны сигнал-слот и многопоточность

Mon, 12 Aug 2024 00:00:00 +0000

Qt для встраиваемых систем

Qt работает на встраиваемых Linux-системах (i.MX6, i.CORE, Pi) через Qt for Device Creation и бэкенды eglfs или linuxfb — X11 не требуется. Также поддерживаются MCU без ОС (STM32, NXP) через Qt for MCUs (QUL), хотя QUL использует подмножество API.

Эта статья сфокусирована на Qt для встраиваемых HMI на Linux: промышленная панель, контроллер сенсорного экрана или встраиваемый ПК. Архитектура сигнал-слот и паттерны многопоточности те же, что и в настольном Qt.

Автоматы состояний для прошивки — от enum/switch до объектов-состояний

Mon, 05 Aug 2024 00:00:00 +0000

Почему прошивке нужны автоматы состояний

Прошивка фундаментально реактивна: внешние события (нажатие кнопки, тик таймера, завершение DMA) управляют переходами между рабочими режимами. Без явной структуры автомата состояний эта логика оседает в виде глубоко вложенных цепочек if-else, разбросанных по ISR и циклам задач — поначалу корректно, при масштабировании необслуживаемо.

Эта статья строит три реализации КА для одного устройства: сенсор с батарейным питанием, которому нужно управлять своими состояниями питания.

Состояния: Idle → Measuring → Transmitting → Sleeping → Idle События: buttonPress, measureDone, txDone, wakeTimer

Примеры CRTP-примесей

Mon, 29 Jul 2024 00:00:00 +0000

Что такое CRTP-примесь

CRTP-примесь добавляет поведение классу, заставляя его наследовать от шаблонного базового класса, получающего конкретный класс в качестве параметра типа:

1template <typename Derived>
2class Mixin {
3    // можно вызывать методы Derived через static_cast<Derived*>(this)
4};
5
6class MyClass : public Mixin<MyClass> {
7    // MyClass теперь имеет всё, что предоставляет Mixin
8};

Никакой виртуальной диспетчеризации. Никакой vtable. Примесь встраивается при компиляции.

Примесь 1: Loggable

Добавляет метод log(msg), предваряющий сообщение именем класса:

 1template <typename Derived>
 2class Loggable {
 3public:
 4    void log(std::string_view msg) const {
 5        auto& self = static_cast<const Derived&>(*this);
 6        printf("[%s] %.*s\n", self.className(),
 7               static_cast<int>(msg.size()), msg.data());
 8    }
 9};
10
11class SensorTask : public Loggable<SensorTask> {
12public:
13    const char* className() const { return "SensorTask"; }
14
15    void run() {
16        log("started");
17        // ...
18        log("done");
19    }
20};

Если производный класс не предоставляет className(), компилятор выдаёт ошибку в точке первого вызова log — никакого краша во время выполнения.

Паттерн «команда» — отмена/повтор и отложенное выполнение

Mon, 22 Jul 2024 00:00:00 +0000

Операции как объекты

Паттерн «команда» инкапсулирует операцию как объект. Вместо прямого вызова функции, вызывающий создаёт объект команды и передаёт его исполнителю. Исполнитель решает, когда (и нужно ли) его выполнять.

Это позволяет:

Отмену/повтор — каждая команда знает, как отменить себя
Запись макросов — собирать команды для воспроизведения
Отложенное выполнение — ставить команды в очередь на потом
Логирование — записывать команды по мере выполнения
Откат транзакций — выполнить список; при ошибке — откатить все

Базовый интерфейс команды

1class ICommand {
2public:
3    virtual void execute() = 0;
4    virtual void undo()    = 0;
5    virtual ~ICommand()    = default;
6};

Конкретная команда захватывает получателя (объект, над которым она работает) и любые параметры в своём конструкторе:

Профилирование с perf и valgrind — чтение вывода

Mon, 15 Jul 2024 00:00:00 +0000

Измеряйте перед оптимизацией

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

Профилировщик говорит:

Где реально тратится время — часто не там, где думаете
Почему медленно — промахи кэша, неверные предсказания переходов, конкуренция за блокировку
Помогло ли ваше исправление — сравнение до/после

Два инструмента покрывают большинство задач производительности C++ на Linux: perf для счётчиков аппаратной производительности и анализа на уровне CPU; valgrind и его инструменты для ошибок памяти, симуляции кэша и профилирования графа вызовов.

Пул объектов

Mon, 08 Jul 2024 00:00:00 +0000

Когда нужен пул объектов

Куча — универсальна, но проблематична в системах реального времени:

Недетерминированное время выделения
Фрагментация при длительной работе
Режим отказа — крэш во время выполнения, а не ошибка компиляции

Пул выделяет всю память заранее в массиве фиксированного размера. Каждый слот хранит один объект. Выделение — это извлечение указателя; освобождение — помещение указателя. Оба O(1) и детерминированы.

Используйте пул когда:

Объекты одного типа (или одного максимального размера)
Время жизни произвольное (в отличие от аллокаторов-арен)
Скорость выделения ограничена и известна на этапе компиляции

Реализация

 1// object_pool.h
 2#pragma once
 3#include <array>
 4#include <cassert>
 5#include <cstddef>
 6#include <memory>
 7#include <new>
 8
 9template <typename T, size_t Capacity>
10class ObjectPool {
11public:
12    ObjectPool() noexcept {
13        // Строим интрузивный список свободных через хранилище
14        for (size_t i = 0; i < Capacity - 1; ++i)
15            slots_[i].next = &slots_[i + 1];
16        slots_[Capacity - 1].next = nullptr;
17        head_ = &slots_[0];
18    }
19
20    // Выделить сырое хранилище — вызывающий должен создать объект через placement-new
21    T* allocate() noexcept {
22        if (!head_) return nullptr;
23        Slot* s = head_;
24        head_   = s->next;
25        --free_;
26        return reinterpret_cast<T*>(s->storage);
27    }
28
29    // Освободить — вызывающий должен уже уничтожить объект
30    void deallocate(T* ptr) noexcept {
31        Slot* s = reinterpret_cast<Slot*>(ptr);
32        s->next = head_;
33        head_   = s;
34        ++free_;
35    }
36
37    size_t capacity() const noexcept { return Capacity; }
38    size_t available() const noexcept { return free_; }
39    bool   full()  const noexcept { return free_ == 0; }
40    bool   empty() const noexcept { return free_ == Capacity; }
41
42private:
43    union Slot {
44        alignas(T) char storage[sizeof(T)];
45        Slot* next;
46    };
47
48    std::array<Slot, Capacity> slots_;
49    Slot*  head_ = nullptr;
50    size_t free_ = Capacity;
51};

Использование — ручное получение/освобождение

 1static ObjectPool<SensorSample, 32> pool;
 2
 3// Выделить + сконструировать
 4SensorSample* s = pool.allocate();
 5if (s) {
 6    new (s) SensorSample{HAL_GetTick(), readVoltage()};
 7    processQueue.push(s);
 8}
 9
10// После обработки — уничтожить + освободить
11SensorSample* s = processQueue.pop();
12if (s) {
13    s->~SensorSample();       // явный вызов деструктора
14    pool.deallocate(s);
15}

Использование — с unique_ptr (RAII)

unique_ptr с кастомным удалителем автоматизирует шаги уничтожения и освобождения:

Многоуровневая архитектура прошивки — от HAL до приложения

Mon, 01 Jul 2024 00:00:00 +0000

Проблема монолита

Прошивка, начатая как концепт, в итоге выглядит так:

 1// main.cpp — 1200 строк
 2int main() {
 3    HAL_Init();
 4    MX_GPIO_Init();
 5    MX_I2C1_Init();
 6
 7    // Обращение к регистрам BMP280 вперемешку с логикой дисплея
 8    uint8_t id;
 9    HAL_I2C_Mem_Read(&hi2c1, 0x76<<1, 0xD0, 1, &id, 1, 10);
10
11    // Байты команд SSD1306 вперемешку с математикой сенсора
12    HAL_I2C_Mem_Write(&hi2c1, 0x3C<<1, 0x00, 1, initCmds, sizeof(initCmds), 10);
13
14    float temp = (id == 0x60) ? readBmp() : 25.0f;
15    char buf[32];
16    sprintf(buf, "T: %.1fC", temp);
17    drawString(0, 0, buf);  // drawString обращается к HAL внутри
18}

Детали железа (адреса регистров, дескрипторы I2C, последовательности командных байт) переплетены с бизнес-логикой. Замена BMP280 на SHT31 требует поиска по 1200 строкам. Написание юнит-теста для логики сигнализации требует реального МК.

Событийная архитектура — шина событий, pub-sub, развязанные модули

Mon, 24 Jun 2024 00:00:00 +0000

Проблема связанности

Архитектура с прямыми вызовами — по умолчанию:

1void SensorTask::onReading(float value) {
2    display_.update(value);     // SensorTask знает о DisplayTask
3    logger_.log(value);         // SensorTask знает о Logger
4    alarmCheck_.check(value);   // SensorTask знает о AlarmCheck
5}

Добавление нового потребителя (например, DataRecorder) требует правки SensorTask. Удаление потребителя — найти и убрать его вызов. Тестирование SensorTask в изоляции требует заглушек для всех трёх зависимостей.

Событийная архитектура инвертирует это: SensorTask публикует TemperatureEvent; потребители регистрируют интерес и получают его. SensorTask не знает, кто слушает.

Паттерн «активный объект» — поток и очередь как один класс

Mon, 17 Jun 2024 00:00:00 +0000

Проблема разделяемого состояния

Типичный подход к многопоточности: разделяемые данные, защищённые мьютексами.

 1class SensorManager {
 2    std::mutex   mtx_;
 3    SensorData   latest_;       // разделяемое — оба потока обращаются
 4    bool         updated_ = false;
 5public:
 6    void updateFromSensor() {   // вызывается из потока сенсора
 7        std::lock_guard lk(mtx_);
 8        latest_ = readSensor();
 9        updated_ = true;
10    }
11
12    SensorData getLatest() {    // вызывается из потока дисплея
13        std::lock_guard lk(mtx_);
14        updated_ = false;
15        return latest_;
16    }
17};

Для двух потоков это работает, но по мере роста числа вызывающих конкуренция за блокировку растёт, а рассуждения о том, какой поток владеет каким состоянием, усложняются. Каждый метод — потенциальное место дедлока.

Кэш-дружественные структуры данных: AoS vs SoA на практике

Mon, 10 Jun 2024 00:00:00 +0000

Почему важна организация данных

Современные CPU быстрые; память — медленная. Промах кэша на современном CPU стоит 100–300 нс — сотни тактов, в течение которых CPU простаивает. Правильная организация данных может быть важнее любой алгоритмической оптимизации.

Кэш-линия — единица передачи между RAM и кэшем CPU. На x86 и ARM Cortex-A кэш-линия составляет 64 байта. Доступ к одному байту загружает 64 байта. Если следующий нужный байт находится в той же кэш-линии — бесплатно. Если в 65 байтах дальше — ещё один промах.

Паттерны «фабрика» и «строитель»

Mon, 03 Jun 2024 00:00:00 +0000

Зачем централизовать создание объектов

Когда подсистема создаёт свои зависимости напрямую, она связана с их конкретными типами. Изменение реализации означает изменение кода подсистемы:

1// Задача сенсора создаёт собственные зависимости — привязана к Bmp280 и UartLogger
2class SensorTask {
3    Bmp280     sensor_;   // конкретный тип
4    UartLogger logger_;   // конкретный тип
5public:
6    SensorTask() : sensor_(hi2c1), logger_(huart2) {}
7};

Тестирование в изоляции требует реального железа. Замена Bmp280 на мок требует правки SensorTask. Паттерн «фабрика» выносит решение о создании за пределы класса, использующего объект.

Фабричный метод

Фабричный метод — функция, которая создаёт и возвращает объект, скрывая конкретный тип за интерфейсом:

std::variant и std::optional — типобезопасные альтернативы void*

Mon, 27 May 2024 00:00:00 +0000

Проблема void*

C-код передаёт значения неизвестного типа через void* и целочисленный тег:

1typedef struct {
2    int type;    // 0=int, 1=float, 2=string
3    void* data;
4} Value;
5
6// Приведение на основе тега — неопределённое поведение при ошибке
7float f = *(float*)val.data;

Ничто не мешает передать неправильный тип. Тег может рассинхронизироваться с данными. void* требует явного управления памятью.

C++ улучшает это с помощью union + enum, но объединения по-прежнему управляются вручную — можно забыть установить дискриминант, забыть уничтожить активный член или прочитать не тот член.

CRTP — статический полиморфизм и примеси

Mon, 20 May 2024 00:00:00 +0000

Проблема с виртуальным диспетчингом

Виртуальные функции — стандартный механизм C++ для полиморфизма времени выполнения, но они несут цену:

Указатель на vtable в каждом объекте — каждый экземпляр полиморфного класса хранит скрытый указатель (8 байт на 64-битной платформе) на его vtable
Косвенный вызов — каждый виртуальный вызов загружает указатель на vtable, загружает указатель на функцию из таблицы, затем вызывает через него — 2 разыменования указателя до первой инструкции функции
Нет инлайнинга — компилятор не может встроить код через виртуальный вызов в общем случае; он не знает, какой override будет вызван

На Cortex-M4 на 168 МГц косвенный вызов стоит 3–5 нс — незначительно для большинства кода. Но для внутреннего цикла DSP, вызывающего функцию обработки на частоте 1 МГц выборок, 3 нс на вызов — это 0.5% вашего CPU-бюджета только на один диспетчинг.

Руководство по выбору контейнера: vector, deque, list, array

Mon, 13 May 2024 00:00:00 +0000

Ответ по умолчанию

Используйте std::vector. Это правильный контейнер для подавляющего большинства случаев. Выбирайте что-то другое только при наличии конкретной причины.

Это не отговорка — это следствие того, как работают кэши CPU. Вектор хранит элементы последовательно в памяти. Итерация по вектору из N элементов касается N кэш-линий по порядку. Все остальные стандартные контейнеры разбрасывают элементы по памяти, увеличивая количество промахов кэша.

1std::vector<float> vec(1000);     // 1000 float, одно выделение, последовательный доступ
2std::list<float>   lst(1000);     // 1000 узлов, 1000 выделений, случайный паттерн доступа

На современном CPU итерация по lst может быть в 10–50 раз медленнее, чем по vec при том же количестве элементов — исключительно из-за эффектов кэша.

Потокобезопасный синглтон — C++11 и новее

Mon, 06 May 2024 00:00:00 +0000

Правильная реализация

 1class Config {
 2public:
 3    static Config& instance() {
 4        static Config inst;   // C++11 §6.7: инициализация потокобезопасна
 5        return inst;
 6    }
 7
 8    void set(std::string_view key, std::string value) { /* ... */ }
 9    std::string get(std::string_view key) const { /* ... */ }
10
11private:
12    Config() = default;                          // запрет конструирования
13    Config(const Config&) = delete;
14    Config& operator=(const Config&) = delete;
15};
16
17Config::instance().set("baud", "115200");

Это вся реализация. Никакого мьютекса, никакого std::call_once, никаких атомарных флагов.

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

Распределители памяти: пул, арена и избежание фрагментации

Mon, 29 Apr 2024 00:00:00 +0000

Проблема кучи

malloc / new разработаны для общего выделения памяти: произвольные размеры, произвольные времена жизни, произвольный порядок. Эта универсальность имеет цену:

Фрагментация — выделение и освобождение блоков разных размеров создаёт промежутки в куче, которые будущие запросы не могут заполнить. Система с 10 кБ свободной памяти всё равно может не справиться с запросом 1 кБ, если свободное пространство разбросано в островках по 500 байт. Долгоработающие системы (серверы, встраиваемые устройства, медиаплееры) деградируют со временем.

Паттерн «стратегия» — объекты политик vs шаблоны

Mon, 22 Apr 2024 00:00:00 +0000

Запах цепочки if-else

В прошивке и настольном C++ накапливается этот паттерн:

1float filter(float sample, FilterType type) {
2    if      (type == FilterType::None)     return sample;
3    else if (type == FilterType::LowPass)  return lowPass(sample);
4    else if (type == FilterType::Median)   return median(sample);
5    else if (type == FilterType::Kalman)   return kalman(sample);
6    return sample;
7}

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

Паттерн «стратегия» заменяет цепочку на заменяемый объект поведения. Вызывающий выбирает, какую стратегию использовать; алгоритм инкапсулирован внутри неё.

Семантика перемещения и передача данных без копирования

Mon, 15 Apr 2024 00:00:00 +0000

Проблема копирования

До C++11 возврат объекта из функции означал его копирование:

1std::vector<float> getReadings() {
2    std::vector<float> v(1000);
3    fill(v);
4    return v;  // копирование — 1000 float выделяются и memcpy-копируются
5}
6
7auto readings = getReadings();  // ещё одна копия

Компиляторы применяли оптимизацию возвращаемого значения (RVO) в простых случаях, но сложный код, контейнеры контейнеров или нетривиальные пути возврата — всё это откатывалось к копированию. Большие структуры данных передавались по указателю или ссылке во избежание затрат.

Семантика перемещения даёт C++ механизм системы типов для передачи владения ресурсами без их копирования.

HAL vs прямой доступ к регистрам на STM32

Mon, 08 Apr 2024 00:00:00 +0000

Ложная дихотомия

Встраиваемое сообщество часто представляет HAL vs регистры как религиозный спор. Сторонники HAL указывают на переносимость и сопровождаемость; сторонники доступа к регистрам — на размер кода и скорость. Оба правы в разных контекстах.

Полезный вопрос не «что лучше?», а «в каком слое моей прошивки должен жить каждый?»

Что даёт HAL

HAL STM32 (Hardware Abstraction Layer) оборачивает регистры периферии в C-функции с обработкой ошибок, логикой таймаутов и поддержкой DMA:

1// HAL: инициализация SPI и передача 8 байт
2HAL_SPI_Transmit(&hspi1, buffer, 8, HAL_MAX_DELAY);

Преимущества:

std::span и std::string_view — избежание ненужных копий

Mon, 01 Apr 2024 00:00:00 +0000

Проблема: функции, берущие слишком много в собственность

Функция, обрабатывающая буфер, часто выглядит так:

1void process(const std::vector<float>& data);

Это работает — но излишне ограничено. Вызывающий должен иметь std::vector. Массив, внутреннее хранилище кольцевого буфера, DMA-буфер на стеке — ничего из этого нельзя передать без копирования или reinterpret.

Или сырой вариант с указателем:

1void process(const float* data, size_t len);

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

Кольцевой буфер — безопасный для встраиваемых, шаблонный

Mon, 25 Mar 2024 00:00:00 +0000

Зачем кольцевой буфер

Кольцевой буфер (циклический буфер) — стандартный инструмент для передачи данных между производителем и потребителем, когда:

Производитель и потребитель работают с разной скоростью
Нужно избежать динамического выделения памяти
Требуется связь ISR → задача без мьютекса

Это аппаратный примитив под другим названием: UART’ы, SPI DMA и аудиокодеки используют кольцевые буферы внутри. Ваша прошивка тоже должна.

Требования к кольцевому буферу для встраиваемых

Без кучи — фиксированная ёмкость, известная на этапе компиляции
Без блокировок — push и pop возвращаются немедленно
Безопасен для ISR — безопасен, когда одна сторона — ISR-производитель, другая — задача-потребитель на одноядерном МК
Ёмкость — степень двойки — позволяет быстрый остаток через битовое AND

Реализация

 1// ring_buffer.h
 2#pragma once
 3#include <array>
 4#include <cstddef>
 5#include <optional>
 6
 7template <typename T, size_t Capacity>
 8class RingBuffer {
 9    static_assert((Capacity & (Capacity - 1)) == 0,
10                  "Ёмкость должна быть степенью двойки");
11    static constexpr size_t MASK = Capacity - 1;
12
13public:
14    // Добавить элемент. Возвращает false если полный.
15    bool push(const T& item) {
16        const size_t w = write_;
17        const size_t next = (w + 1) & MASK;
18        if (next == read_) return false;   // полный
19        buf_[w] = item;
20        write_ = next;
21        return true;
22    }
23
24    // Извлечь элемент. Возвращает пустой optional если пустой.
25    std::optional<T> pop() {
26        const size_t r = read_;
27        if (r == write_) return std::nullopt;  // пустой
28        T item = buf_[r];
29        read_ = (r + 1) & MASK;
30        return item;
31    }
32
33    bool empty() const { return read_ == write_; }
34    bool full()  const { return ((write_ + 1) & MASK) == read_; }
35
36    size_t size() const {
37        return (write_ - read_) & MASK;
38    }
39
40    size_t capacity() const { return Capacity - 1; }  // один слот зарезервирован как сторожевой
41
42private:
43    std::array<T, Capacity> buf_{};
44    volatile size_t write_ = 0;
45    volatile size_t read_  = 0;
46};

Ключевые решения при проектировании

volatile на индексах — предотвращает кэширование компилятором индексов чтения или записи в регистрах. На одноядерном Cortex-M, где одна сторона — ISR, volatile достаточен. На многоядерных или при оптимизирующих компиляторах, переупорядочивающих записи, вместо этого используйте std::atomic<size_t> с memory_order_relaxed (см. ниже).

Паттерн наблюдатель — минимальная реализация на C++

Mon, 18 Mar 2024 00:00:00 +0000

Паттерн в одном абзаце

Наблюдатель позволяет объекту (субъекту) уведомлять список зависимых (наблюдателей), когда его состояние меняется — не зная, кто они и что делают. Субъект хранит список обратных вызовов; наблюдатели регистрируют себя; субъект вызывает каждый callback при изменении. Это всё.

Версия 1 — std::function, список с выделением на куче

Простейшая современная реализация на C++. Наследование на стороне наблюдателя не требуется — подходит любой вызываемый объект.

 1#include <functional>
 2#include <vector>
 3#include <algorithm>
 4
 5template <typename... Args>
 6class Event {
 7public:
 8    using Handler = std::function<void(Args...)>;
 9    using Token   = size_t;
10
11    Token subscribe(Handler h) {
12        Token id = nextId_++;
13        handlers_.push_back({id, std::move(h)});
14        return id;
15    }
16
17    void unsubscribe(Token id) {
18        handlers_.erase(
19            std::remove_if(handlers_.begin(), handlers_.end(),
20                           [id](const Entry& e) { return e.id == id; }),
21            handlers_.end());
22    }
23
24    void emit(Args... args) const {
25        for (const auto& e : handlers_)
26            e.handler(args...);
27    }
28
29private:
30    struct Entry { Token id; Handler handler; };
31    std::vector<Entry> handlers_;
32    Token nextId_ = 0;
33};

Использование:

FreeRTOS: задачи и очереди

Mon, 11 Mar 2024 00:00:00 +0000

Неправильный старт с FreeRTOS

Самая распространённая ошибка при добавлении FreeRTOS в проект — воспроизвести структуру bare-metal кода с помощью задач:

 1// Задача 1 — читает сенсор
 2void sensorTask(void*) {
 3    while (true) {
 4        g_sensorValue = readAdc();    // пишет в глобальную переменную
 5        vTaskDelay(pdMS_TO_TICKS(10));
 6    }
 7}
 8
 9// Задача 2 — обрабатывает данные
10void processTask(void*) {
11    while (true) {
12        float v = g_sensorValue;      // читает глобальную — гонка данных
13        process(v);
14        vTaskDelay(pdMS_TO_TICKS(10));
15    }
16}

Здесь гонка данных на g_sensorValue. На Cortex-M это работает, потому что 32-битные выровненные чтение/запись атомарны на ARMv7-M — но это неопределённое поведение в C++, не работает для многобайтовых типов и не переносимо между семействами МК.

Умные указатели и модели владения в C++

Mon, 04 Mar 2024 00:00:00 +0000

Владение — это концепция; умные указатели — инструмент

До unique_ptr и shared_ptr владение было неявным — соглашение, записанное в комментариях и поддерживаемое только дисциплиной. «Кто вызывает create(), должен вызвать destroy()». Это работало до тех пор, пока не переставало: исключения, ранние возвраты и множество путей выхода приводили к утечкам.

Умные указатели делают владение явным и проверяемым системой типов. unique_ptr<T> не просто хранит указатель — он говорит: «Я единственный владелец этого объекта. Когда я выхожу из области видимости, объект уничтожается».

Конечные автоматы — три подхода

Mon, 26 Feb 2024 00:00:00 +0000

Почему автоматы важны во встраиваемом ПО

Большинство прошивок — конечные автоматы, даже если так не задумывались. Устройство, которое загружается, настраивает периферию, ждёт данных, обрабатывает их и обрабатывает ошибки, имеет минимум пять состояний. Когда эта логика живёт в клубке флагов, вложенных if и глобальных переменных, о ней невозможно рассуждать — и невозможно тестировать.

Явный КА заставляет перечислить все состояния и все переходы. В этой статье сравниваются три подхода на примере менеджера соединений: Idle → Connecting → Connected → Disconnecting → Idle.

Проектирование на основе интерфейсов в C++

Mon, 19 Feb 2024 00:00:00 +0000

Что такое интерфейс

В C++ нет ключевого слова interface. Интерфейс — соглашение: класс только с чисто виртуальными методами и виртуальным деструктором. Никаких членов-данных, никакой реализации.

1struct ISensor {
2    virtual float read()  = 0;
3    virtual bool  ready() = 0;
4    virtual ~ISensor()    = default;
5};

Вот и всё. Любой класс, наследующий от ISensor и реализующий оба метода, является сенсором с точки зрения любого кода, зависящего от ISensor.

Цель — отделить что от как. Код, зависящий от ISensor, не знает — и не должен знать — общается ли он с BMP280 по I2C, NTC-термистором на канале АЦП 3 или генератором синусоиды в юнит-тесте.

Внедрение зависимостей без фреймворка

Mon, 12 Feb 2024 00:00:00 +0000

Что такое внедрение зависимостей на самом деле

Внедрение зависимостей (DI) — не фреймворк, не библиотека паттернов и не дизайн-философия. Это одна конкретная техника:

Дай объектам то, что им нужно; не позволяй им строить это самим.

Всё. Если класс создаёт свои зависимости сам, он владеет ими и вы не можете их заменить. Если класс получает зависимости при создании, вызывающий решает, что он получит.

 1// НЕ внедрение зависимостей
 2class DataLogger {
 3    Stm32SpiFlash flash_;   // создаётся здесь — владеем навсегда
 4public:
 5    DataLogger() : flash_(SPI1, GPIOA, GPIO_PIN_4) {}
 6};
 7
 8// Внедрение зависимостей
 9class DataLogger {
10    IStorage& storage_;     // внедряется вызывающим
11public:
12    explicit DataLogger(IStorage& s) : storage_(s) {}
13};

Разница — одна строка в классе и одна строка в месте вызова. Выигрыш — тестируемость, переносимость и возможность менять реализации, не трогая бизнес-логику.

Lock-free очереди — SPSC, MPSC и когда использовать каждую

Mon, 05 Feb 2024 00:00:00 +0000

Зачем lock-free

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

Lock-free очереди избегают этого, используя атомарные операции, всегда делающие прогресс без блокировки ядра. Компромисс: корректность требует тщательного упорядочивания памяти, а ошибки реализации — тихие, редкие и катастрофические.

Многоуровневая структура проекта с CMake

Mon, 29 Jan 2024 00:00:00 +0000

Проблема плоских проектов

Большинство C++-проектов начинаются с размещения всего в одной директории:

project/
├── main.cpp
├── sensor.cpp
├── sensor.h
├── logger.cpp
├── logger.h
├── uart.cpp
...
CMakeLists.txt   ← один файл, 300 строк

Работает, пока проект не растёт. Затем появляется:

монолитный CMakeLists.txt, которого никто не хочет трогать
заголовки с относительными путями #include "../../../sensor.h"
нет возможности повторно использовать модули в другом проекте
тесты, включающие половину кодовой базы для тестирования одной функции

Исправление — многоуровневое расположение директорий с одним CMakeLists.txt на модуль.

АЦП + DMA на STM32 — прерывание-управляемая конвейерная архитектура

Mon, 22 Jan 2024 00:00:00 +0000

Проблема опроса АЦП

Наивный подход к чтению АЦП на STM32 выглядит так:

1while (true) {
2    HAL_ADC_Start(&hadc1);
3    HAL_ADC_PollForConversion(&hadc1, 10);
4    uint32_t val = HAL_ADC_GetValue(&hadc1);
5    process(val);
6}

Работает для одного канала на низких частотах дискретизации. Рассыпается, когда нужно:

несколько каналов с точными интервалами
CPU для чего-то ещё во время дискретизации
стабильное тактирование (опрос вносит джиттер)

Правильный инструмент — непрерывное преобразование АЦП, управляемое DMA, с двойной буферизацией через пару прерываний half-transfer / transfer-complete. Эта статья строит такой конвейер с нуля.

SOLID на практике — встраиваемый C++

Mon, 15 Jan 2024 00:00:00 +0000

Почему SOLID важен на микроконтроллере

Проект STM32 на 50 тыс. строк — именно то место, где игнорирование SOLID причиняет наибольшую боль. Нетестируемые ISR-обработчики, main.cpp на 800 строк, перекомпиляция HAL ради замены сенсора — симптомы кодовой базы, выросшей без архитектурной дисциплины.

Эта статья разбирает каждый принцип с конкретными примерами до/после на C++, взятыми из конвейера сенсор → фильтр → дисплей на STM32. Для каждого принципа:

однострочное определение
нарушение из реального кода прошивки
исправление
заметка о том, почему это важно именно на микроконтроллере

S — Принцип единственной ответственности

Класс должен иметь только одну причину для изменения.