Без дифференциации по возрасту, полу и весу от статьи мало толку.
Автору надо обязательно указать свой возраст и вес.
Скажем зарядить мужика весом 100 Кг бегать марафоны это все равно что приговорить к травмам ног.
Вашему автору следовало бы еще указать компилятор, его версию и параметры компиляции.
Еще надо подтвердить из какой памяти выпонялся код, и чем еще была занята шина, как были настроены шинные коммутаторы, какое выравнивание было у данных, были ли запрещены прерывания и как измерялось время. И где гарантия что измеритель времени сам был детерминированным.
Короче, хоть ваш результат и близок к истине, но особого доверия не вызывает.
У вас слишком большой разброс, отношу это на небрежность тестирования. И нет статистики с доверительными интервалами.
Но даже приняв это все, скажите почему вам так принципиально за 3 мкс или за 24 мкс выполнится выделение памяти? Вы что память в обработчиках прерывания выделяете?
Всетаки где вам важен такой детерминизм?
Думаю сервисы вашей библиотеки функций RTOS будут менее детерминированными чем free и malloc.
Хотелось бы посмотреть пример от вас где реально имела бы значение детерминированность вашей библиотеки функций реального времени
Уже много лет не могу найти в интернете кто-бы действительно показал, как он учитывает детерминированность RTOS. Кроме RTOS MQX да ThreadX я не видел серьезных тестов детерминированности.
Классно вы переписали код с С++ на C-и при работе со строками.
А я ведь говорил, что скатитесь к C-и и никуда не денетесь.
Про функции работы с heap вы тоже под воздействием каких-то мифов подобранных из сомнительной литературы. Если бы сподобились измерить время выполнения malloc и free, то увидели бы что они в среднем всегда выполняется за 3 мкс. И разброс этого времени не превышает 2 раз при выделении 2000! блоков одновременно. Это наверняка больше чем вы когда либо выделяли в STM32.
Программирование микроконтроллеров быстро прогрессирует, поэтому я бы на вашем месте не рисковал транслировать устаревшие знания.
Давайте лучше цифры и результаты тестов.
Угол по оси Z постоянно дрейфует.
Поскольку его не к чему привязать. По осям X и Y есть привязка к вектору притяжения земли акселерометром.
Если MPU-6050 заменить на MPU-9250 то можно магнитометром корректировать угол по оси Z. Но магнитометр имеет большую амплитуду шума, поэтому сам угол по Z становится более нестабильным.
Вот и вся дилема.
Кардинального решения не имеет, кроме перехода на более дорогую технологию гироскопов или привлечение других источников привязки.
Моя точка зрения, что все решают либы. Сам язык не важен.
Языки изобретают такие же интроверты, мало понимающие в массовой психологии и не стоит от них ожидать неких ментальных практик лучшего использования мозга.
Они там в своих языках решают свои локальные проблемы связанные с особенностями их инструментов и прикладной областью, которые мы даже не знаем или проблемы организации коллективного программирования.
Единственное что действительно полезно — это либы которые они по ходу создают или портируют. Одновременно с этим они их и документируют.
В малых встраиваемых системах коллективное программирование не играет важной роли. К примеру приложения для Arduino практически всегда программируют в одиночку. Там сама среда не располагает к коллективной работе.
А real-time embedded еще и сильно связан с ассемблером. При отладке постоянно надо смотреть ассемблер сгенерированный компилятором. Чем прямее связь исходников с ассемблером тем легче отлаживать.
Несмотря на то что С-и и C++ похожи, интеграция большинства либ в приложение на C++ требует коррекции либ.
Но дело обстоит так, что трудоемкость коррекция сколько нибудь стоящих либ своей ценой превышает ценность всех тех мелких удобств С++.
Вот и все, ничего личного, только энергозатраты.
У eCOS файловая система и TCP стек были на чистейшем C-и.
Там только ядро да стандартная библиотека были на C++.
Хотя пример удачный.
Вот в таких гибридов превращаются все потуги написать RTOS на C++.
И здесь так будет.
Если бы C++ давал хоть какое-нибудь преимущество в скорости написания или уменьшении отладки или в надежности, то все для embedded было бы давно переписано на C++.
Вон на ПК Python почти мгновенно поднялся, и все библиотеки на него были переписаны. А тут десятилетиями тормоза.
Нет, что ни говорите а в embedded у С++ с текущими либами нет перспектив.
Реальное время и структурированность (если я правильно понял этот ваш термин) несколько несовместимы.
Я сейчас с удовольствием изучил Zephyr OS. Вся написана на C-и. Современная. Поддерживает последний писк моды — mesh сети на Bloetooth.
А у вас я увидел только декларации IoT и ни одного упоминания стека который вы предлагаете для IoT.
Уверен на 99% что у вас не будет стека IoT написанного на C++, максимум опять обертка.
В RTOS нет никаких проблем сделать динамическую загрузку.
В версиях Линукс для ядер без MMU (бывшая uLinux) и в NuttX и в VxWorks и других малых RTOS есть такая возможность.
Проблема только в том, что с загрузкой сторонних приложений не будет работы в реальном времени.
А где не нужно реальное время ставят raspberry pi и прочие модули с линуксом и это получается даже дешевле чем с микроконтроллерами и RTOS.
Промежуточное, я так понимаю, будет все тот же избитый набор: FatFS да lwIP.
Но они то написаны на голом С-и.
Поэтому RTOS-ы на С++ еще долго будут не востребованы.
Для выносных плат у вас неправильно спроектирован вывод SPI шины.
Надо было ставить дифференциальные драйверы.
У вас же моторы, помехи.
А так сможете расположить свои датчики не дальше пары сантиметров и на скорости не больше десятка килогерц.
Словом отстрелялись вы себе по ногам.
orange pi соединен только через UART с микроконтроллером.
А к микроконтроллеру присоединена куча датчиков, драйверов, CAN, USB…
Чтобы всем этим управлять и отлаживать в реальном времени из orange придется ваять сложнейший протокол.
Те же алгоритмы управления как вижу никак не диагносцируются и не отлаживаются.
Датчики ориентации тоже должны быть на одной платформе с моторами, а их нет.
Словом ничего не сделано для действительно удобной отладки и исследований.
Странный выбор микроконтроллера.
ATSAM3X8E можно считать уже морально устаревшим, да и ресурсы у него жидковаты.
Для современной исследовательской платформы стоило выбрать что-нибудь помощней.
Пишите, конечно.
Эти поиски серебряной пули всегда интересны.
Однако если ваш подход ничем внешне (ни нотацией, ни организацией) не отличается от обычного программирования, то в чем его суть? Я также применяю switch-case. Также некоторые переменные у меня имеют тип перечисления. Я также некоторое время сижу в ступоре и думаю сколько состояний должна иметь переменная, типа проектирую. У вас же проектирование тоже никак не формализовано (с чего начинаться, чем заканчиваться)
Но я ничего уже не помню по теории автоматов, никогда сильно в ней не разбирался и даже желания нет разбираться.
Что это с о мной? Как я умудряюсь программировать в терминах состояний? Или я жутко неэффективно программирую?
Вот, допустим, моя реализация монитора VT100. Не предлагаю анализировать этот текст, а только обратить внимание сколько там switch-case. И это все было написано без единой мысли о некоем автоматном программировании.
Скорее всего у вас некий частный случай.
Наверно станут яснее ваши мысли когда вам придется полнее раскрыть в какой области работаете.
А то что вы пытаетесь говорить за все программирование не рассказав о своей личной квалификации только увеличивает недоверие к вашему мнению, уж извините.
По моему опыту отладка всегда! занимает бОльшую часть времени. Даже когда вы использует графическую нотацию. Проектирование с машинами состояний только увеличивает это время, поскольку надо отлаживать еще и автоматы, использовать специальную нотацию, и угадывать где предусмотреть расширяемость и модифицируемость. То что автоматы только на бумаге или в голове не отменяет необходимости в их отладке.
А если вы удачно придумали один автомат и его успешно копируете из проекта в проект, то это не интересно, это не технология.
Подумайте почему в области программирования логических контроллеров, где все алгоритмы отлично описываются автоматами практически ушли от графической нотации автоматов.
Дело в том, что разработка автоматов заставляет рассматривать и реализовывать все состояния.
А в работе реальных вещей нету смысла рассматривать и учитывать подавляющую часть состояний.
Поэтому программу легче писать просто вылавливая и обрабатывая нужные сочетания сигналов. Нет никакой необходимости эти сочетаний кодировать в состояния. И некое проектирование тут ни к чему и даже невозможно.
Скажем на этапе разработки программы для ПЛК можно даже не знать заранее всё поведение объекта. Программа развивается в стиле патчей. Узнали о новом поведении — добавили обработку характерных сочетаний сигналов.
Никаких состояний, никаких диаграмм переходов! Это некая реализация реактивного программирования. Особенно удобно в сочетании с многозадачностью и RTOS.
Это признанная практика.
А автоматы и плохо масштабируются, и совершенно не гибкие и труднее отлаживаются, требуют «проектирования»
Автоматы хороши на низком уровне. Например протокол PPP, реализуется на таблице переходов. Это приемлемо, хорошо формализовано. Но это очень простой протокол. А вот изобразить автоматами WEB сервер уже не выйдет.
Согласен полностью.
Но почему-то именно вопрос удобства и не рассматривается.
По сути автор предлагает всегда сопровождать текстовую нотацию графической.
Это удобство?
Это нужно только начинающим программистам, у которых мозг не сформировал областей нужных паттернов мышления.
Присутствие оператора switch в программе на языке C-и тоже не маркер автоматного программирования.
В принципе автоматное программирование это такой спекулятивный термин, что даже Миро Самек от него отошел.
Читайте Машина Тьюринга
Какую бы программу вы не написали все это можно будет интерпретировать как автомат.
Поэтому если хотите показать настоящее автоматное программирование, то программируйте сразу машину Тьюринга.
Автору надо обязательно указать свой возраст и вес.
Скажем зарядить мужика весом 100 Кг бегать марафоны это все равно что приговорить к травмам ног.
Еще надо подтвердить из какой памяти выпонялся код, и чем еще была занята шина, как были настроены шинные коммутаторы, какое выравнивание было у данных, были ли запрещены прерывания и как измерялось время. И где гарантия что измеритель времени сам был детерминированным.
Короче, хоть ваш результат и близок к истине, но особого доверия не вызывает.
У вас слишком большой разброс, отношу это на небрежность тестирования. И нет статистики с доверительными интервалами.
Но даже приняв это все, скажите почему вам так принципиально за 3 мкс или за 24 мкс выполнится выделение памяти? Вы что память в обработчиках прерывания выделяете?
Всетаки где вам важен такой детерминизм?
Хотелось бы посмотреть пример от вас где реально имела бы значение детерминированность вашей библиотеки функций реального времени
Уже много лет не могу найти в интернете кто-бы действительно показал, как он учитывает детерминированность RTOS. Кроме RTOS MQX да ThreadX я не видел серьезных тестов детерминированности.
А я ведь говорил, что скатитесь к C-и и никуда не денетесь.
Про функции работы с heap вы тоже под воздействием каких-то мифов подобранных из сомнительной литературы. Если бы сподобились измерить время выполнения malloc и free, то увидели бы что они в среднем всегда выполняется за 3 мкс. И разброс этого времени не превышает 2 раз при выделении 2000! блоков одновременно. Это наверняка больше чем вы когда либо выделяли в STM32.
Программирование микроконтроллеров быстро прогрессирует, поэтому я бы на вашем месте не рисковал транслировать устаревшие знания.
Давайте лучше цифры и результаты тестов.
Поскольку его не к чему привязать. По осям X и Y есть привязка к вектору притяжения земли акселерометром.
Если MPU-6050 заменить на MPU-9250 то можно магнитометром корректировать угол по оси Z. Но магнитометр имеет большую амплитуду шума, поэтому сам угол по Z становится более нестабильным.
Вот и вся дилема.
Кардинального решения не имеет, кроме перехода на более дорогую технологию гироскопов или привлечение других источников привязки.
Языки изобретают такие же интроверты, мало понимающие в массовой психологии и не стоит от них ожидать неких ментальных практик лучшего использования мозга.
Они там в своих языках решают свои локальные проблемы связанные с особенностями их инструментов и прикладной областью, которые мы даже не знаем или проблемы организации коллективного программирования.
Единственное что действительно полезно — это либы которые они по ходу создают или портируют. Одновременно с этим они их и документируют.
В малых встраиваемых системах коллективное программирование не играет важной роли. К примеру приложения для Arduino практически всегда программируют в одиночку. Там сама среда не располагает к коллективной работе.
А real-time embedded еще и сильно связан с ассемблером. При отладке постоянно надо смотреть ассемблер сгенерированный компилятором. Чем прямее связь исходников с ассемблером тем легче отлаживать.
Несмотря на то что С-и и C++ похожи, интеграция большинства либ в приложение на C++ требует коррекции либ.
Но дело обстоит так, что трудоемкость коррекция сколько нибудь стоящих либ своей ценой превышает ценность всех тех мелких удобств С++.
Вот и все, ничего личного, только энергозатраты.
Там только ядро да стандартная библиотека были на C++.
Хотя пример удачный.
Вот в таких гибридов превращаются все потуги написать RTOS на C++.
И здесь так будет.
Если бы C++ давал хоть какое-нибудь преимущество в скорости написания или уменьшении отладки или в надежности, то все для embedded было бы давно переписано на C++.
Вон на ПК Python почти мгновенно поднялся, и все библиотеки на него были переписаны. А тут десятилетиями тормоза.
Нет, что ни говорите а в embedded у С++ с текущими либами нет перспектив.
Я сейчас с удовольствием изучил Zephyr OS. Вся написана на C-и. Современная. Поддерживает последний писк моды — mesh сети на Bloetooth.
А у вас я увидел только декларации IoT и ни одного упоминания стека который вы предлагаете для IoT.
Уверен на 99% что у вас не будет стека IoT написанного на C++, максимум опять обертка.
В версиях Линукс для ядер без MMU (бывшая uLinux) и в NuttX и в VxWorks и других малых RTOS есть такая возможность.
Проблема только в том, что с загрузкой сторонних приложений не будет работы в реальном времени.
А где не нужно реальное время ставят raspberry pi и прочие модули с линуксом и это получается даже дешевле чем с микроконтроллерами и RTOS.
Промежуточное, я так понимаю, будет все тот же избитый набор: FatFS да lwIP.
Но они то написаны на голом С-и.
Поэтому RTOS-ы на С++ еще долго будут не востребованы.
Вот тут поподробней.
Какие RTOS вы изучали и что из них скопировали.
Надо было ставить дифференциальные драйверы.
У вас же моторы, помехи.
А так сможете расположить свои датчики не дальше пары сантиметров и на скорости не больше десятка килогерц.
Словом отстрелялись вы себе по ногам.
А к микроконтроллеру присоединена куча датчиков, драйверов, CAN, USB…
Чтобы всем этим управлять и отлаживать в реальном времени из orange придется ваять сложнейший протокол.
Те же алгоритмы управления как вижу никак не диагносцируются и не отлаживаются.
Датчики ориентации тоже должны быть на одной платформе с моторами, а их нет.
Словом ничего не сделано для действительно удобной отладки и исследований.
ATSAM3X8E можно считать уже морально устаревшим, да и ресурсы у него жидковаты.
Для современной исследовательской платформы стоило выбрать что-нибудь помощней.
Эти поиски серебряной пули всегда интересны.
Однако если ваш подход ничем внешне (ни нотацией, ни организацией) не отличается от обычного программирования, то в чем его суть? Я также применяю switch-case. Также некоторые переменные у меня имеют тип перечисления. Я также некоторое время сижу в ступоре и думаю сколько состояний должна иметь переменная, типа проектирую. У вас же проектирование тоже никак не формализовано (с чего начинаться, чем заканчиваться)
Но я ничего уже не помню по теории автоматов, никогда сильно в ней не разбирался и даже желания нет разбираться.
Что это с о мной? Как я умудряюсь программировать в терминах состояний? Или я жутко неэффективно программирую?
Вот, допустим, моя реализация монитора VT100. Не предлагаю анализировать этот текст, а только обратить внимание сколько там switch-case. И это все было написано без единой мысли о некоем автоматном программировании.
Наверно станут яснее ваши мысли когда вам придется полнее раскрыть в какой области работаете.
А то что вы пытаетесь говорить за все программирование не рассказав о своей личной квалификации только увеличивает недоверие к вашему мнению, уж извините.
По моему опыту отладка всегда! занимает бОльшую часть времени. Даже когда вы использует графическую нотацию. Проектирование с машинами состояний только увеличивает это время, поскольку надо отлаживать еще и автоматы, использовать специальную нотацию, и угадывать где предусмотреть расширяемость и модифицируемость. То что автоматы только на бумаге или в голове не отменяет необходимости в их отладке.
А если вы удачно придумали один автомат и его успешно копируете из проекта в проект, то это не интересно, это не технология.
Дело в том, что разработка автоматов заставляет рассматривать и реализовывать все состояния.
А в работе реальных вещей нету смысла рассматривать и учитывать подавляющую часть состояний.
Поэтому программу легче писать просто вылавливая и обрабатывая нужные сочетания сигналов. Нет никакой необходимости эти сочетаний кодировать в состояния. И некое проектирование тут ни к чему и даже невозможно.
Скажем на этапе разработки программы для ПЛК можно даже не знать заранее всё поведение объекта. Программа развивается в стиле патчей. Узнали о новом поведении — добавили обработку характерных сочетаний сигналов.
Никаких состояний, никаких диаграмм переходов! Это некая реализация реактивного программирования. Особенно удобно в сочетании с многозадачностью и RTOS.
Это признанная практика.
А автоматы и плохо масштабируются, и совершенно не гибкие и труднее отлаживаются, требуют «проектирования»
Автоматы хороши на низком уровне. Например протокол PPP, реализуется на таблице переходов. Это приемлемо, хорошо формализовано. Но это очень простой протокол. А вот изобразить автоматами WEB сервер уже не выйдет.
Может следующие статьи что-то раскроют.
Жду.
Но почему-то именно вопрос удобства и не рассматривается.
По сути автор предлагает всегда сопровождать текстовую нотацию графической.
Это удобство?
Это нужно только начинающим программистам, у которых мозг не сформировал областей нужных паттернов мышления.
Присутствие оператора switch в программе на языке C-и тоже не маркер автоматного программирования.
В принципе автоматное программирование это такой спекулятивный термин, что даже Миро Самек от него отошел.
Какую бы программу вы не написали все это можно будет интерпретировать как автомат.
Поэтому если хотите показать настоящее автоматное программирование, то программируйте сразу машину Тьюринга.