Преимущества RTOS по сравнению с Bare Metal для программирования на MCU?

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

Мне интересно больше узнать о встроенных ОСРВ и писать приложения для них. В настоящее время я смотрю на Embox и RIOT, потому что они открыты, современны, активны и, кажется, имеют отличную документацию. Моя цель состоит из двух этапов: Этап 1 состоит в том, чтобы выяснить, как скомпилировать и прошить эти ОС на MCU (возможно, AVR или ARM). Фаза 2 состоит в том, чтобы затем написать простую программу на C (в основном, безголовый демон), которая со временем будет развиваться как «приложение для хобби». Затем я бы прошил / развернул эту программу на том же MCU, тем самым успешно развернув пакет приложений, состоящий из Embox / RIOT и моего приложения, расположенного поверх него.

Перед тем, как идти вниз любые дороги , которые в конечном итоге привести к тупикам, я наткнулся на эту статью , что делает очень хорошую работу, объясняя , почему в режиме реального времени приложение, написанное на C / ассемблере и мелькал в микроконтроллеры, не на самом деле нужно RTOSes под ними ,

Так что теперь я действительно запутался и ставлю под сомнение некоторые из моих фундаментальных представлений о теории вычислений. Я думаю, что я пытаюсь принять решение, использовать ли Embox / RIOT или нет вообще:

• Продолжайте курс и используйте «стек приложений» на MCU для обоих приложений OS +; или же
• Прислушайтесь к предупреждению статьи и просто используйте MCU для запуска моего приложения "голый металл"

Очевидно, что первое - это больше работы, и поэтому лучше было бы иметь веские основания для того, чтобы идти по этому пути. Поэтому я спрашиваю: каковы реальные преимущества этих (и подобных) встроенных ОСРВ для разработчиков приложений MCU / C? Какие особенности могут быть полезны моему приложению C (возможно, не изобретая колесо?) При использовании ОСРВ? Что теряется из-за отказа от ОСРВ и выхода из строя?

Я прошу конкретные примеры здесь, а не ажиотаж в СМИ, который вы получаете, когда заходите в статью в Википедии для RTOS ;-)

Микроконтроллерные программы состоят из ряда задач . Допустим, вы хотели сделать телескоп с компьютерным управлением. Задачи будут:

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

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

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

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

• Ваш буфер переполнен, поэтому вы хотите убедиться, что задача может прерывать другие задачи, прежде чем она переполнится.
• Вы хотите сэкономить заряд аккумулятора, когда ничего не нужно.
• Вы хотите удостовериться, что все задачи получают честный удар. Если это readSensorsзаймет слишком много времени, вы захотите прервать его и вернуться к нему позже.
• Вы хотите иметь возможность просто сбросить одну задачу, не затрагивая другие.
• Вы хотите, чтобы утечка памяти или другая ошибка в одной задаче не устраняли другие задачи.
• Вы хотите, чтобы у разных задач были разные приоритеты.
• Вы хотите иметь возможность ставить в песочницу ненадежную задачу.
• Вы хотите, чтобы иметь возможность выполнять задачи с различной скоростью. Возможно, ваши датчики могут считываться только 10 раз в секунду, но вы хотите выполнить шаг двигателя 100 раз в секунду.

Один или два из этих предметов могут быть обработаны вручную относительно легко. Если таких проблем достаточно часто, и вы начинаете обобщать их в библиотеки, вы в основном заново изобрели RTOS. Если управление задачами вашей программы достаточно сложное, даже если вы не используете готовую ОСРВ, в конечном итоге вы плохо ее изобретаете.

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

Я написал свою собственную многопоточную библиотеку для ARM Cortex-M0.

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

Большим преимуществом roll-your-own является то, что вы знаете код и можете портировать его на микросхемы, которые RTOS может не поддерживать. Кроме того, вы тратите меньше времени на размышления над такими вопросами, как «произойдет ли сбой, я попытаюсь использовать функции A и B одновременно?» Поскольку вы написали код, вы знаете ответ.

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