Комментарии 11
Интересно. Я только начал изучать STM32 и хотя Cube избавляет от погружения в тонкости, применение симуляторов должно сильно ускорить прототипирование, переводя процесс разработки на этаж выше. Конечно, специалисты-железячники посчитают это попсой, вручную конфигурируя регистры, но таких специалистов не так много.
Эта самая Engee свободна от разного рода санкций?
Как пользователь таких движков скажу вам, что Engee наверняка не симулирует периферию STM32. Там эти блоки вероятно вставляются, но при симуляции игнорятся. Ну так делают все, даже монстры типа Keil не рискуют полностью симулировать периферию.
Если посмотрите PlatformIO ,то увидите что это просто собрание всего мусора интернета хоть как-то связанного с микроконтролерами.
STM32CubeMX это даже в какой-то степени конкурент PlatformIO, совместить их будет невозможно.
Самый простой путь на сегодня - это сконфигурировать начальный вариант в STM32CubeMX, потом с помощью VSCode Copilot дополнить до нужных фичей и вычистить от артефактов кроссплатформенности. Все эти драйвера для IMU типа MPU6050 и прочих Copilot с правильным AI генерит влет, прямо по pdf файлам даташитов. Выискивать по интернету какие-то либы не надо если это не фреймворки стеков TCP, BLE, USB ...
Полезность разработки таких примитивных алгоритмов, как вычисление поворотов и пространственные преобразования в среде типа Engee или MATLAB тоже уже под большим вопросом. Copilot идеально разбирается в кватернионах и калманах. Напишет чистейший текст с исчерпывающими коментами прям с интринсиками (intrinsics) вашего компилятора.
Значительно удобнее сгенерированного в этих средах кода.
Симуляция периферии в контексте модельно-ориентированного проектирования (МОП) не так интересна. Это решается на этапе тестирования программно-аппаратной реализации (на HIL стендах). В контексте МОП интересны алгоритмы в модели и алгоритмический код. Если у Вас проекте 90% кода периферий, а 10% - алгоритмов, то модельная разработка, видимо, не ваш подход.
Однако сам "контекст МОП" поменялся.
Именно вычислительные алгоритмы ИИ решает как семечки, еще и тесты для них напишет и графику нарисует.
И актуальней для простых разработчиков не SIL, а RCP.
В этой статье с медленным IMU на шине I2C это был бы более эффективный вариант , вместо неуклюжей иммитации периферии.
Соглашусь. Наверно, можно даже объединить подходы - Engee с блочным подходом и готовыми структурами использовать для прототипирования алгоритма с проверкой моделированием, а также автозагрузкой на таргет с RTOS-обёрткой. А дальше, кому хочется - можно генерировать алгоритм в код и в кубике дописывать ручками. Кстати, и Engee ничего не мешает генерировать код периферии, описанной на самом низком уровне в Си. Если интересно - могу поискать подобный пример для Engee.
А насчёт санкций - сама Engee свободна. Разраб - отечественный, сервера - отечественные (наши или на Вашем предприятии), генератор кода, пакеты поддержки, библиотеки блоков, расчётное ядро и тд и тд - отечественные. Оговорюсь только, что для сборки/компиляции/загрузки кода модели на таргет Engee использует внешние инструменты - то есть, те же cubemx/arduino-cli/... пока что Вам всё равно понадобятся. Но если Вы используете в своём продукте STM, возникает вопрос, на сколько уже он будет свободен от санкций. Так что если потом будет интересно отечественное железо, можете посмотреть примеры с генерацией под МИК32 / Миландр.
А можно получившийся исходник для STM32 посмотреть?
Один из первых робочих драфтов есть здесь
А причем здесь УОМЗ - Уральский оптико-механический завод, да нще и с его логотипом?
Автоматическая генерация кода для встраиваемых систем: проект УОМЗ