Российские микроконтроллеры, такие как Baikal-U (BE-U1000) от “Байкал Электроникс”, К1921ВК01Т от НИИЭТ и 1892ВГ1Я компании НПЦ “ЭЛВИС”, разрабатываются для импортозамещения аналогов STM32 и применяются в АСУ ТП, IoT и управлении двигателями. В статье рассматривается их применимость в полётных контроллерах для дронов и роботов.

Современные полётные контроллеры функционируют под управлением ОС, таких как PX4, Betaflight или ArduPilot, которые требуют определённой производительности от микроконтроллера.

Полетные контроллеры для PX4 (на базе NuttX RTOS), Betaflight и ArduPilot требуют 32-битных ARM Cortex-M процессоров (M4/M7), минимум 168–480 МГц, 256 КБ+ RAM и 1–2 МБ Flash для алгоритмов стабилизации, навигации и логирования.

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

• сенсоры ориентации IMU (гироскопы MPU6000/ICM42688);
• определение высоты датчиком атмосферного давления;
• PWM для управления двигателями (4–16 двигателей);
• интерфейсы UART/SPI/I2C/CAN.

Математические вычисления с плавающей точкой с использованием FPU/DSP-инструкций для PID-регуляторов и фильтров требуют от контроллера соответствия требованиям по тактовой частоте и объёму оперативной памяти. Вот минимальные требования ОС к процессорным ядрам микроконтроллеров:

🧠 Что предлагают российские микроконтроллеры?

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

В таблице ниже представлены некоторые характеристики наших микроконтроллеров:

ОС PX4, Betaflight и ArduPilot на наших микроконтроллерах

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

💡 Наиболее подходящим для полётных контроллеров является наш 🤘 Baikal-U (BE-U1000).

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

⚙️ Портирование PX4, Betaflight и ArduPilot на наши микроконтроллеры

Портирование операционной системы реального времени (RTOS), вроде PX4, Betaflight или ArduPilot, на новые микроконтроллерные платформы — это сложная инженерная задача, требующая понимания как архитектурных особенностей целевого процессора, так и внутреннего устройства ядра ОС. При портировании ОС на российские микроконтроллеры (Baikal-U на RISC-V, К1921ВК01Т и 1892ВГ1Я на ARM Cortex-M) разработчики должны уделить внимание следующим критическим областям.

1. Архитектурные отличия и совместимость с ядром ОС

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

RISC-V архитектура (Baikal-U BE-U1000):

Baikal-U использует открытую архитектуру RISC-V с двумя ядрами (200 МГц + 100 МГц), что значительно отличается от стандартных ARM Cortex-M, используемых в других полётных контроллерах.

NuttX имеет поддержку RISC-V и активно развивается в этом направлении (особенно благодаря проекту PX4). Однако портирование NuttX на Baikal-U потребует создания специального Board Support Package (BSP), так как это не стандартная платформа.

Требуется реализовать правильную работу прерываний через RISC-V CLIC (Core Local Interrupt Controller) вместо стандартного CLINT, так как это критически влияет на время отклика на события (важно для стабилизации дрона).

ARM Cortex-M архитектура (К1921ВК01Т и 1892ВГ1Я):

Оба контроллера используют ARM Cortex-M (M4F и M33), что хорошо поддерживается NuttX и другими RTOS.

Однако К1921ВК01Т работает на более низкой частоте (~125 МГц против рекомендуемых 168+ МГц), что может быть узким местом для вычисления PID-регуляторов в режиме реального времени.

1892ВГ1Я обладает современной архитектурой M33 с встроенной FPU и DSP, но имеет ограниченное встроенное ОЗУ, что требует тщательной оптимизации размера ядра ОС.

2. Board Support Package (BSP) и конфигурация оборудования

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

Ключевые компоненты BSP для полётных контроллеров:

Boot-последовательность и инициализация памяти: загрузчик должен правильно инициализировать ОЗУ, настроить сегменты памяти, загрузить RTOS из Flash и передать управление ядру ОС. Для каждой российской платформы требуется своя реализация, так как разметка памяти отличается.

Конфигурация системных часов (clock setup): это критически важно для обеспечения корректной частоты процессора и периферийных устройств. Для Baikal-U нужно правильно настроить синхронизацию между двумя ядрами и установить необходимые делители частоты. Для ARM-контроллеров требуется конфигурация PLL и распределение часов между периферией (UART, SPI, таймеры для PWM).

Таймеры и системное время (system tick): RTOS требует высокоточного таймера для планирования задач. Для полётных контроллеров критично использовать таймер с разрешением не менее 1 кГц. Разработчик должен выбрать физический таймер и правильно настроить его прерывание для работы с планировщиком RTOS.

3. Обработка прерываний и переключение контекста

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

Что нужно учесть:

Векторизация прерываний: ARM Cortex-M имеет встроенный NVIC (Nested Vectored Interrupt Controller) с автоматическим сохранением контекста. RISC-V требует либо CLIC, либо эмуляции подобного поведения в программном коде. Требуется убедиться, что RTOS правильно использует доступные механизмы.

Приоритизация прерываний: полётный контроллер должен обрабатывать прерывания от датчиков IMU и давления с наивысшим приоритетом, чтобы не пропустить критичные данные. Разработчик должен правильно настроить NVIC/CLIC-приоритеты и убедиться, что конфигурация RTOS совпадает.

Задержка включения контекста: время от момента прерывания до начала выполнения обработчика должно быть минимальным и предсказуемым. Для Cortex-M это нативно поддерживается аппаратно (~13 циклов), а для RISC-V нужна специальная настройка CLIC с расширением fastirq (при наличии).

Конфликты прерываний (priority inversion): если низкоприоритетная задача захватывает ресурс, необходимый высокоприоритетной задаче, возникает инверсия приоритетов. RTOS должна поддерживать механизмы вроде Priority Inheritance для предотвращения этого, особенно важно при использовании мьютексов между датчиками и PID-регулятором.

4. Драйверы периферийных устройств

Полётный контроллер требует работоспособных драйверов для:

• UART — для связи с наземной станцией и передачи телеметрии;
• SPI/I2C — для опроса датчиков IMU, барометра и т.д.;
• PWM — для управления электромоторами (8–16 двигателей);
• CAN (опционально) — для подключения к другим компонентам (ESC — электронным регуляторам скорости);
• таймеров и счётчиков — для точного измерения времени и управления моторами.

Важные аспекты:

Hardware Abstraction Layer (HAL): разработчик должен создать унифицированный интерфейс для драйверов, чтобы приложение (PX4, Betaflight) не привязывалось к конкретному микроконтроллеру. STM32 предоставляет готовый HAL, но для Baikal-U и других российских контроллеров требуется самостоятельно разработать или адаптировать HAL.

DMA-контроллер (Direct Memory Access): для высокоскоростной передачи данных (особенно через SPI при опросе датчиков) требуется настройка DMA, чтобы не блокировать CPU. PX4 требует наличия DMA для работы на требуемых частотах.

Протокол и временные характеристики: датчики IMU (вроде MPU6000) требуют опроса с частотой 1 кГц, а барометры — с частотой 100 Гц. Разработчик должен убедиться, что драйверы SPI/I2C могут обеспечить такие скорости без потери данных.

5. Управление памятью (SRAM, Flash и внешняя память)

Российские микроконтроллеры имеют ограниченный объём встроенной памяти:

Baikal-U: 192 КБ SRAM + 256 КБ Flash (+ 16 МБ XIP Flash) — достаточно для облегчённой версии NuttX + PX4.

К1921ВК01Т: 192 КБ SRAM + 1 МБ Flash — близко к минимуму для PX4.

1892ВГ1Я: кэш 16 КБ/ядро (размер SRAM не указан) + внешняя Flash до 64 МБ — нужна работа с внешней памятью.

Что требуется учесть:

Компоновка памяти (linker script): для каждого контроллера должен быть правильный скрипт компоновщика, определяющий расположение кода, данных, стека и heap в памяти. Неправильная компоновка приводит к перезагрузкам и сбоям.

Размер RTOS: NuttX имеет огромное количество опциональных компонентов. Для работы на ограниченной памяти К1921ВК01Т потребуется отключить невостребованные функции (например, VFS, USB, сетевой стек), оставив только минимум: планировщик, таймер, драйверы датчиков и PWM.

Стек задач: каждая задача в RTOS требует собственный стек. Неправильное распределение стека приводит к stack overflow и повреждению памяти. Требуется тщательное планирование и тестирование на предмет переполнения.

Внешняя память: 1892ВГ1Я может использовать внешнюю Flash (QSPI, SMC), что позволяет хранить алгоритмы и данные вне чипа. Но это добавляет сложность синхронизации и задержек доступа, требуя особой осторожности при работе с real-time кодом.

6. Поддержка арифметики с плавающей точкой (FPU)

PID-регуляторы, фильтры Калмана и другие алгоритмы управления требуют вычислений с плавающей точкой.

Baikal-U (RISC-V): поддерживает FP32 (одинарная точность). FP64 (двойная точность) может быть эмулирована, но с огромным штрафом производительности (~8–20x медленнее).

К1921ВК01Т (Cortex-M4F): имеет аппаратную FPU для FP32, но не для FP64. PX4 основан на EKF2, который использует double для некоторых навигационных расчётов — на этом контроллере потребуется либо оптимизировать фильтр, либо смириться с деградацией производительности.

1892ВГ1Я (Cortex-M33): современная архитектура с поддержкой FP32/FP64 и DSP-расширениями, что оптимально для точных вычислений.

Требуется:

• убедиться, что RTOS и компилятор (обычно arm-none-eabi-gcc) правильно используют FPU;
• включить флаги компиляции -mfpu=fpv4-sp-d16 (для M4F) или -mfpu=fpv5-sp-d16 (для M7/M33);
• протестировать точность вычислений PID и фильтров, особенно на контроллерах без аппаратной поддержки FP64.

7. Тестирование и валидация

Критический шаг, часто недооцениваемый:

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

Тестирование real-time свойств: измерить задержку отклика (latency) при разных нагрузках. Для полётных контроллеров критично, чтобы стабилизирующие контроллеры выполнялись с частотой минимум 200 Гц и без пропусков.

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

Тестирование отказоустойчивости: проверить поведение при потере связи, отказе датчика или сбое в электропитании. PX4 должен безопасно перейти в режим удержания высоты или вернуться на базу.

📦 Наши полётные контроллеры

💡 Существуют ли полётные контроллеры на базе Baikal-U, К1921ВК01Т, 1892ВГ1Я?

Да, они существуют и демонстрируются на профильных мероприятиях! Дело за малым — рассказать о них всё, что можно, и обязательно провести НИОКР по их применению в ваших проектах!

🛸 P.S. Спасибо, что дочитали, поделитесь статьёй с хэштегом #DeepHeads! и подпишитесь на наш канал t.me/deepheads.