👩‍💻 Перечисление (enum)

Иногда вместе со списком элементов необходимо иметь их количество и значение последнего элемента.

Подобное часто применяется для перечисления допустимых индексов каких-либо аппаратных блоков или каких-то статусов.

Не редно видел конструкции вида:

enum dma_instance_e
{
  DMA_INST_0,
  DMA_INST_1,
  DMA_INST_2,
  DMA_INST_LAST = DMA_INST_2,
  DMA_INST_QTY = DMA_INST_LAST + 1,
};

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

Но в коде выше есть проблема: решили добавить дма - необходимо изменить ещё и ласт. Одна правка, а изменяет две строчки, что не только не красиво, но и потенциальная ошибка из-за невнимательности.

➡️Да-да, решили добавить дма. Нам можно, мы микросхемы проектируем 😊

Намного проще поменять порядок элементов и возложить эту задачу на компилятор:

enum dma_instance_e
{
  DMA_INST_0, // 0
  DMA_INST_1, // 1
  DMA_INST_2, // 2
  // <== добавлять тут
  DMA_INST_QTY, // 3
  DMA_INST_LAST=DMA_INST_QTY-1, // 2
};

#си #перечисление #enum

👩‍💻 Switch statement с диапазонами

Очередное расширение GNU.

Допустим у нас ситуация... с такими условиями:

void func(uint32_t var)
{
    if (var >= VALUE_A_START && var <= VALUE_A_END) 
    { /* CODE */}
    else if (var >= VALUE_B_START && var <= VALUE_B_END) 
    { /* CODE */}
    else if (var >= VALUE_C_START && var <= VALUE_C_END) 
    { /* CODE */}
    else if (var >= VALUE_D_START && var <= VALUE_D_END) 
    { /* CODE */}
    else 
    { /* CODE */}
}

В зависимости от попадания в нужный диапазон выполняется то или иное действие.

Попробуем переписать при помощи switch:

void func(uint32_t var)
{
    switch (var)
    {
        case VALUE_A_START:
        case VALUE_A_1:
        case VALUE_A_2:
        // ... здесь куча других case
        case VALUE_A_30: 
        case VALUE_A_31: 
        case VALUE_A_END: 
        /* CODE */ 
        break;

        // Остальные секции: D, C, D
        ...

        default: break;
    }
}

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

Попробуем использовать расширения GNU и переписать код в более удобном для восприятия виде:

void func(uint32_t var)
{
    switch (var)
    {
        case VALUE_A_START ... VALUE_A_END: 
            /* CODE */ 
            break;
        case VALUE_B_START ... VALUE_B_END:
            /* CODE */ 
            break;
        case VALUE_C_START ... VALUE_C_END:
            /* CODE */ 
            break;
        case VALUE_D_START ... VALUE_D_END:
            /* CODE */ 
            break;

        default: break;
    }
}

В итоге код стал проще выглядеть и восприниматься. Мы сохранили читаемость такую же как у "if", но приобрели скорость выполнения конструкции "switch"

Пусть это и расширение GNU, но clang собирает без ругани даже если указать -std=c11 , а не -std=gnu11

#c #switchcase #switch

👩‍💻 Шина событий на костылях. Реализация в FreeRTOS

Паттерн "шина событий" (Event Bus) - это архитектурный шаблон, который позволяет компонентам системы взаимодействовать друг с другом, обмениваясь событиями, без необходимости явного знания о существовании друг друга.

Казалось бы к чему это.

Начнем рассказ с архитектуры ПО, которое работает на нашем видеопроцессоре.

Существует тракт обработки видео и множество модулей, которые выполняют действия в какой-то момент обработки потока кадров:
🔴перед кадром
🔴после кадра
🔴во время обработки кадра
🔴после сжатия
🔴и других событиях.

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

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

Первой попыткой реализации было использование event flags и event groups. Однако у этого подхода есть ограничения в невозможности одновременной подписки нескольких задач на одно событие. Флаг сбрасывает первая разблокированная задача.

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

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

/// \brief Массив очередей событий
/// \note events[ количество событий ][ глубина очереди ]
static event_task_handler_t events
           [ EVENT_BUS_QTY ]
           [ EVENT_LIST_DEPHT ] = {0};

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

Задача которая генерирует событие посылает уведомление каждой задаче из списка.

Таким образом каждая ожидающая задача гарантированно получает уведомление и разблокируется для выполнения, заодно и решается проблема связанная со сбросом флагов в event flags.

Небольшой пример:

Источник событий

static void task_1(void * arg)
{
    /* INIT TASK CODE */
    for (;;){
        /* CODE */
        event_bus_push(EVENT_COMPETE_1);
    }
}

Потребитель событий 1

static void task_2(void * arg)
{
    /* INIT TASK CODE */
    // Подписать текущую задачу
    event_bus_subscribe(EVENT_COMPETE_1); 
    // Подписать задачу 3
    event_bus_unsubscribe_ex(EVENT_COMPETE_1, task_3_handler); 
    for (;;){
        if (event_bus_wait(EVENT_COMPETE_1, 100) == true){
            /* CODE */
        }
    }
}

Потребитель событий 2

static void task_3(void * arg)
{
    for (;;){
        if (event_bus_wait(EVENT_COMPETE_1, 100) != true)
        {
           continue;
        }
        /* CODE */
    }
}

Полный код реализации можно найти в репозитории:
https://github.com/devprodest/event-bus-freertos/tree/main

#eventbus #freertos #шинасобытий

Очередная версия плагинчика для SVN

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

Что нового:
🟡Улучшилась стабильность. Теперь меньше ошибок в консоли.
🟡Код довольно сильно отрефакторен
🟡Добавлено всплывающее окно с дополнительной информацией по комиту (в том числе и сообщение комита)
🟡Исправлена первая проблема на Github от пользователя плагина: информация о последнем открытом отслеживаемом файле отображалась в файле, который не отслеживается, а так же в других окнах, таких как Chat Copilot
🟡Добавлен канал вывода логов "SVN Lens".
🟡Исправлена ​​ошибка с пустой последней строкой. SVN blame её не отображает. Добавлена ​​заглушка "Last empty line is missing from blame".

Github: https://github.com/devprodest/vscode-svn-lens
vscode matketplace: https://marketplace.visualstudio.com/items?itemName=ZaikinDenis.vscode-svnlens

👩‍💻👩‍💻👩‍💻 Современная среда разработки на языке C

В этой статье рассмотривается, как настроить контейнерную среду разработки для проектов на языке C. Также настройку системы сборки с помощью CMake, среды тестирования с помощью Unity и даже то, как использовать контейнерную среду в конвейере непрерывной интеграции!

Статья старая, но не бесполезная. Язык английский.

https://interrupt.memfault.com/blog/a-modern-c-dev-env

#memfault #c #docker #vscode

👩‍💻 Директива embed

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

Сравнивали варианты с ассемлерными вставками, которые применяли раньше, когда пользовались c11 и gcc 8.1, и новой директивой #embed которую только месяц назад втащил в проект вместе с c23

Примерно так может выглядеть код:

const uint8_t font_data[] = {
#embed "font.bin"
};

Плюсы:
🟢Код стал выглядеть сильно стройнее и симпатичнее.
🟢Нет скрытых extern переменных со странными именами.
🟢Файл теперь массив, а не пара указателей на начало и конец.
🟢Проще использовать в коде.
Теперь у области с данными есть имя (массив) и его видно при анализе эльфа.
🟢Адрес к файлу указывается не относительно точки входа для сборки, а действует схожим с #include образом.
🟢Потенциальный простор для оптимизаций. Компилятор может разгуляться и удалить неиспользуемые массивы.

Минусы:
🔴Не все редакторы нормально подсвечивают эту директиву.
🔴Не все компиляторы умеют её использовать. Но clang 19 справляется на отлично
🔴Непривычный синтаксис, но это не страшно.

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

Ну и напоследок, проверить доступность директивы можно макросом __has_embed

#c #с23 #embed

👩‍💻👩‍💻 Полезный Forward declaration (Предварительное объявление)

Это объявление сущности без указания подробностей её внутренностях. По сути позволяет компилятору понять размер и разрешить ссылки при сборке.

Типичным примером является прототип функции

int func(int val);

Таким же образом можно указывать и типы

typedef struct st_type_t st_type_t;
typedef enum e_type_t e_type_t;

Для чего это может быть полезно.

1. Уменьшение связности модулей программы

Представим ситуацию что есть несколько заголовочников.

Файл a.h содержит описание типов структуры sta_t и перечисления eta_t.
Файл b.h - stb_t и etb_t.
Представим, что нам нужен ещё файл c.h, в котором функция будет принимать указатели на sta_t и stb_t. Можно написать два инклюда a.h и b.h. Но тогда получается что файл который будет инклюдить c.h получает все зависимости всех файлов.
Если у нас не только три файла, а большое дерево зависимостей, то в итоге весь код становиться просто спутанным клубком.

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

2. Ускорение сборки

Данный пункт напрямую вытекает из предыдущего. Объясняется это тем, что компилируемый файл имеет меньший размер, так как директива include просто вставляет содержимое файла.

В моём текущем проекте это позволило снизить размеры файлов после препроцессора с 4-6 мегабайт до 500-800 килобайт. Что в общем случае ускорило сборку проекта на 30%.

Ограничения

Для тог что бы это всё работало, компилятор должен смочь вывести размер сущности и то как её использовать. Для указателей (функции в том числе), стандартных типов, и перечислений (не всегда) это делается очень просто и очевидно.
Для структур не получится и в таком случае include внутри хедера будет оправдан

Каркас для прошивки: почему архитектура решает все

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

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

Почему это критически важно?
Выбор архитектуры определяет:
🟡Скорость реакции на события. Мгновенно или когда дойдут руки?
🟡Предсказуемость. Можно ли точно рассчитать время отклика?
🟡Стоимость железа. Будет ли достаточно дешевого 8-битного МК или нужен мощный ARM?
🟡Сроки разработки и поддержки. Можно ли легко добавлять фичи через полгода или каждый раз всё переписывать?
🟡Надежность. Насколько система устойчива к ошибкам и сложным внешним условиям?

Основных пути, о которых пойдет речь:
🔴Суперлуп (Super Loop) - фундамент. Бесконечный цикл, где задачи выполняются строго по очереди. Простота, но беспощадная ограниченность.
🔴Прерывания (Interrupt-Driven) - мир асинхронности. Позволяет мгновенно реагировать на внешние события, прорывая основной цикл.
🔴Планировщик на таймере (Timer-Based Scheduler) - вводит порядок и периодичность. Шаг от хаоса к системе.
🔴RTOS (Real-Time Operating System) - промышленная мощь. Полноценная многозадачность с приоритетами, синхронизацией и четким планированием.
🔴Событийно-ориентированная архитектура (Event-Driven) - философия слабой связанности. Компоненты общаются через сообщения, не зная друг о друге.

Как выбирать?
🟢Насколько сложна моя система? (одна задача vs. множество независимых процессов)
🟢Критично ли время отклика? (мгновенно vs. в течение секунды)
🟢Каковы ресурсы моего МК? (память, частота)
🟢Будет ли проект масштабироваться?
🟢Какой опыт у команды?

В следующих постах разберу каждый архитектурный паттерн в деталях: как он устроен изнутри, где сияет, а где терпит поражение, и для какого типа проектов создан.

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

#встраиваемыесистемы #архитектурапо #прошивка #embedded #разработка #микроконтроллеры #инженерия #впо

Суперлуп: первый и самый простой каркас для прошивки

Представьте, что вы учитесь готовить. Вы не начинаете со сложного торта Прага. Вы начинаете с бутерброда: взял хлеб, намазал масло, положил колбасу. Суперлуп (Super Loop) - это тот самый бутерброд в мире встраиваемого ПО. Это фундамент, на котором всё начинается.

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

while(1) // Вечный двигатель вашей прошивки
{
    check_buttons(); // 1. Опрос кнопок
    read_sensors();  // 2. Чтение датчиков
    process_logic(); // 3. Вычисление логики
    update_display();// 4. Вывод на экран
}

Как это работает на практике?

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

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

Когда выбирать Суперлуп?
🟡Система тривиальна? (Мигание светодиодом, простейший термометр).
🟡Задачи всегда выполняются быстро? (Ни одна функция не занимает больше пары миллисекунд).
🟡Ресурсы микроконтроллера исчезающе малы? (Мало памяти, низкая частота).
🟡Время отклика не критично? (Не страшно, если система отреагирует на кнопку через 100 мс, а не через 1 мс).

Идеальные кандидаты: Электронные таймеры, простые термостаты, мигалки, детские игрушки, системы с одним основным действием.

Сильные стороны:
➕Предельная простота. Понять и написать может даже новичок. Это главный обучающий инструмент.
➕Нулевые накладные расходы. Нет планировщика, переключения контекста, стеков для задач. Весь ресурс МК - на полезную работу.
➕Абсолютная предсказуемость. Время отклика системы = сумме времен выполнения всех функций до нужной. Всё считается на бумажке.
➕Никаких проблем синхронизации. Нет прерываний, нет разделяемых ресурсов между задачами - значит, нет гонок данных (race condition) и deadlock'ов.
➕Полный контроль. Разработчик точно знает, что и в какой момент выполняется.

Слабые стороны:
➖Катастрофическая отзывчивость. Если функция read_sensors() внезапно займет 500 мс на измерение, всё встанет. Нажатия кнопок не обработаются, дисплей не обновится.
➖Спагетти-код. При добавлении новых функций код быстро превращается в запутанный ком, где всё зависит от всего. Сопровождать такой код - мучение.
➖Неэффективное использование процессора. Пока система ждет события (например, нажатия кнопки), процессор бесполезно крутит пустой цикл, тратя энергию, вместо того чтобы уйти в режим сна.
➖Нет реального параллелизма. Полная неспособность обрабатывать несколько внешних событий, требующих внимания одновременно.
➖Жёсткая связанность. Изменение в одной функции часто влечёт за собой правки в других.

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

#суперлуп #superloop #архитектурапрошивки #embedded #встраиваемыесистемы #программированиемк #новичкам

Прерывания: как заставить систему реагировать мгновенно

Чтобы система реагировала на события мгновенно, переходим к архитектуре на основе Прерываний (Interrupt-Driven).

Основная логика переносится в обработчики прерываний (ISR), которые асинхронно вызываются аппаратурой микроконтроллера.

Суперлуп часто остается для фоновых, не срочных задач.

volatile bool button_pressed = false;

void button_isr(void) {
    button_pressed = true;
}

int main(void) {
    setup_hardware();
    enable_interrupts();

    while(1) {
        update_clock();

        if(button_pressed) {
            button_pressed = false;
            handle_button_action();
        }
        sleep_mode();
    }
}

Как это работает на практике?
Аппаратура МК генерирует сигнал прерывания при событии. Процессор немедленно сохраняет контекст, выполняет ISR и возвращается к прерванному коду. Ключевой принцип - асинхронность и приоритет.

Когда выбирать архитектуру на прерываниях?
🟢Требуется ли мгновенная реакция? (Нажатие кнопки, аварийный датчик)
🟢Нужна ли максимальная энергоэффективность? (Устройство на батарейке)
🟢Система в основном "спит и ждет" событий? (Пульт ДУ, датчик двери)
🟢Готовы ли вы к сложной отладке асинхронного кода?

Идеальные кандидаты: Пульты, коммуникационные шлюзы (UART, SPI), системы аварийного останова.

Сильные стороны:
➕Максимальная отзывчивость. Реакция за микросекунды
➕Энергоэффективность. Основной цикл может спать (WFI)
➕Реальная асинхронность. Система живет в ритме внешнего мира
➕Четкое разделение. Код реакции изолирован в ISR

Слабые стороны:
😀Кошмар отладки. Ошибки трудно воспроизвести
😀Проблемы синхронизации. Общие данные требуют защиты
😀Риск переполнения стека. Длинные или вложенные ISR опасны
😀Непредсказуемость. При высокой нагрузке время отклика неопределенно
😀"Размазанная" логика. Код разбросан по множеству ISR

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

#прерывания #isr #архитектурапрошивки #embedded #встраиваемыесистемы #realtime

Планировщик на таймере - порядок во времени

Следующий шаг к структурированию - Планировщик на таймере (Timer-Based Scheduler).

Это эволюция суперлупа, где системный таймер периодически генерирует прерывание (тик), которое проверяет, каким задачам пора выполняться, и выставляет флаги.
Основной цикл проверяет эти флаги и запускает соответствующие задачи.

volatile uint32_t tick_count = 0;
#define TASK1_PERIOD 100 // Выполнять каждые 100 мс
#define TASK2_PERIOD 500 // Выполнять каждые 500 мс

void systick_isr(void) {
    tick_count++;
}

int main(void) {
    uint32_t last_task1 = 0, last_task2 = 0;
    setup_timer();
    enable_interrupts();

    while(1) {
        uint32_t now = tick_count;

        // Задача 1: каждые 100 тиков
        if((now - last_task1) >= TASK1_PERIOD) {
            last_task1 = now;
            read_sensors();
        }

        // Задача 2: каждые 500 тиков
        if((now - last_task2) >= TASK2_PERIOD) {
            last_task2 = now;
            update_display();
        }

        idle_task();
    }
}

Как это работает на практике?
🔴Системный таймер генерирует регулярные прерывания (например, каждую 1 мс - системный тик).
🔴Каждый тик инкрементирует счетчик времени.
🔴Основной цикл постоянно проверяет, не наступило ли время для выполнения очередной задачи, сравнивая текущее время с временем последнего запуска и заданным периодом.

Когда выбирать планировщик на таймере?
🟡Нужна ли предсказуемая периодичность? (Опрос датчиков раз в 100 мс)
🟡Требуется ли лучшее структурирование, чем у суперлупа?
🟡Можно ли допустить задержку реакции до следующего тика?
🟡Хватит ли ресурсов МК для системного таймера и флагов?

Идеальные кандидаты: Системы управления с четкими циклами (термостаты, регуляторы), устройства с периодическим опросом датчиков, информационные дисплеи, мигалки с разными периодами.

Сильные стороны:
➕Детерминированность. Задачи выполняются с фиксированной периодичностью
➕Лучшая модульность. Задачи изолированы, их проще добавлять и модифицировать
➕Контроль времени. Можно замерять длительность выполнения каждой задачи
➕Эффективность. Нет переключения контекста как в RTOS

Слабые стороны:
😀Кооперативная модель. Долгая задача блокирует всю систему
😀Задержка реакции. Событие обработается только в следующем "тике"
😀Статическое планирование. Периоды задач жестко заданы при компиляции
😀Накопление задержек. Если задача выполняется дольше, сдвигается весь график

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

#планировщик #scheduler #таймер #архитектурапрошивки #embedded #встраиваемыесистемы #кооперативнаямногозадачность

RTOS - мощь многозадачности

Для сложных систем требуется полноценная многозадачность.

Здесь на сцену выходит RTOS (Real-Time Operating System), например, FreeRTOS, Zephyr или Azure RTOS.

Её ядро - это вытесняющий планировщик, который на основе приоритетов решает, какую задачу (поток) выполнять прямо сейчас.

// Поток 1: Высокоприоритетный, обрабатывает прерывания
void high_priority_task(void *params) {
    while(1) {
        xQueueReceive(irq_queue, &data, portMAX_DELAY);
        process_critical_data(data);
    }
}

// Поток 2: Средний приоритет, управление интерфейсом
void ui_task(void *params) {
    while(1) {
        update_display();
        vTaskDelay(pdMS_TO_TICKS(100));
    }
}

// Поток 3: Низкий приоритет, фоновая логика
void background_task(void *params) {
    while(1) {
        calculate_statistics();
        vTaskDelay(pdMS_TO_TICKS(1000));
    }
}

int main(void) {
    xTaskCreate(high_priority_task, "IRQ", 512, NULL, 3, NULL);
    xTaskCreate(ui_task, "UI", 256, NULL, 2, NULL);
    xTaskCreate(background_task, "BG", 128, NULL, 1, NULL);
    vTaskStartScheduler();
}

Как это работает на практике?
RTOS создает иллюзию параллельного выполнения нескольких задач (потоков). Планировщик на основе приоритетов решает, какой поток должен выполняться в каждый момент времени. Если поток с более высоким приоритетом готов к выполнению, он немедленно вытесняет текущий поток. Потоки могут общаться через механизмы синхронизации: очереди, семафоры, мьютексы.

Когда выбирать RTOS?
🔴Система требует настоящего параллелизма? (Независимые процессы)
🔴Нужна ли мгновенная реакция на события высокой важности?
🔴Проект достаточно сложен для команды разработчиков?
🔴Есть ли достаточно ресурсов МК (RAM, Flash)?
🔴Готовы ли вы изучать многопоточное программирование?

Идеальные кандидаты: Сложные устройства с графическим интерфейсом, сетевыми подключениями, множеством датчиков и исполнительных механизмов (умные термостаты, навигаторы, промышленные контроллеры).

Сильные стороны:
➕Вытесняющая многозадачность. Задача с высшим приоритетом получает CPU немедленно
➕Отличная модульность. Код делится на независимые потоки
➕Богатый набор инструментов. Очереди, семафоры, мьютексы "из коробки"
➕Эффективное ожидание. Поток может "уснуть" в ожидании события
➕Портативность. Код легче переносить между разными МК

Слабые стороны:
😀Накладные расходы. Переключение контекста, память под стеки каждого потока
😀Высокий порог входа. Нужно глубоко понимать многопоточность
😀Классические проблемы. Инверсия приоритетов, дедлоки, гонки данных
😀Требует ресурсов. Нужен более мощный МК с достаточным количеством RAM

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

#rtos #freertos #операционнаясистема #архитектурапрошивки #embedded #многозадачность #realtime

Событийно-ориентированная архитектура - общение сообщениями

Самый высокоуровневый подход - Событийно-ориентированная архитектура (Event-Driven Architecture, EDA).

Здесь нет центрального цикла. Компоненты системы общаются через сообщения (события): одни модули их "издают" (publish), другие - "обрабатывают" (subscribe).

Часто строится поверх RTOS или как большая state-машина.

// Издатель события (например, драйвер кнопки)
void button_isr(void) {
    event_t btn_event = { .type = EVENT_BUTTON_PRESSED, .data = 1 };
    event_bus_publish(&btn_event); // Отправка в шину событий
}

// Подписчик события (обработчик интерфейса)
void ui_handler(const event_t *event) {
    if(event->type == EVENT_BUTTON_PRESSED) {
        update_display("Button pressed!");
    }
}

// Инициализация системы событий
int main(void) {
    event_bus_init();
    event_bus_subscribe(EVENT_BUTTON_PRESSED, ui_handler);
    
    while(1) {
        event_bus_process(); // Обработка очереди событий
        idle_task();
    }
}

Как это работает на практике?
Система строится вокруг шины событий (event bus) или диспетчера сообщений.
Компоненты не вызывают функции друг друга напрямую, а отправляют события в шину.
Другие компоненты, подписанные на определенные типы событий, получают и обрабатывают их. Это создает полностью асинхронную и слабосвязанную архитектуру.

Когда выбирать событийно-ориентированную архитектуру?
🟢Система состоит из множества независимых компонентов?
🟢Требуется ли высокая гибкость и возможность расширения?
🟢Важна ли тестируемость и изоляция модулей?
🟢Система по природе реактивная (событие → реакция)?
🟢Готовы ли вы к сложному проектированию с самого начала?

Идеальные кандидаты: Сложные IoT-устройства, системы домашней автоматизации, продвинутые HMI-интерфейсы, сетевые шлюзы, приложения с множеством асинхронных источников данных.

Сильные стороны:
➕Слабая связанность. Модули ничего не знают друг о друге
➕Гибкость и масштабируемость. Новый функционал = новый подписчик
➕Идеально для реактивных систем. Отражает суть embedded
➕Упрощённое тестирование. Модули можно тестировать изолированно

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

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

#событийнаяархитектура #eventdriven #архитектурапрошивки #embedded #шинасобытий #реактивноепрограммирование