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

11

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

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

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

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

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

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

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

smeeb
источник
3
Если вам даже не ясно, что предлагает ОСРВ, тогда почему вы заинтересованы в написании приложений для них? Будет ли RTOS выгодна вам или нет, зависит полностью от того, чего вы пытаетесь достичь. С учетом сказанного, вы должны научиться ходить, прежде чем вы сможете бежать. Запрограммируйте на голое железо, и когда вы столкнетесь с проблемами и решите их, вы по-настоящему узнаете, в чем заключаются преимущества и недостатки.
whatsisname
Спасибо @whatsisname (+1) - это хороший совет, и я, скорее всего, возьму вас на вооружение. Тем не менее, я не думаю, что это было бы ошибкой , все еще интересоваться тем, что предлагают ОСРВ, даже если я нуждаюсь в них месяцами или годами. Я предполагаю, что я хотел бы видеть всю картину спереди, с высоты 30 000 футов. Еще раз спасибо!
Смееб

Ответы:

11

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

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

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

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

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

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

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

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

Карл Билефельдт
источник
Это отличный анализ, и он действительно дал мне понять. Я согласен с тем, что вы говорите, но больше согласен с ответом @Atsby. Особенно, если целью является обучение / совершенствование моих собственных навыков. В производственной системе, вероятно, лучше использовать продукт COTS или RTLinux, но чтобы иметь возможность отладки этого продукта на низком уровне, когда что-то идет не так, мне лично нужно было бы написать код, который бы выполнял в этом списке столько раз, сколько возможный.
Сэм Хаммами
7

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

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

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

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

Atsby
источник
Спасибо @Atsby! Этот ответ действительно помог мне решить, стоит ли тратить время на дальнейшее изучение Bare Metal. Я написал, что такое библиотека GPIO на голом железе для Pi, и теперь я думаю, что настало время сделать еще один или два шага дальше. Благодаря!
Сэм Хаммами