ОСРВ для встраиваемых систем

57

Я видел много статей, которые говорят мне, что я должен использовать RTOS для управления временем и ресурсами. Мое время не позволило мне провести собственное исследование, поэтому я прихожу к чипхакеру за советом.

Я использую микроконтроллеры с низким ресурсом (MSP430, PIC) и искал ОСРВ, которые я могу использовать.

К точке:

  1. Ресурсная стоимость системы
  2. Преимущества системы
  3. Недостатки системы
  4. Хитрости реализации
  5. Ситуации, в которых ОСРВ не должны / не должны использоваться.

Я не использую такие системы, как arduino, проекты, с которыми я работаю, не могут покрыть стоимость такой системы.

Kortuk
источник
2
Я смущен относительно того, за что это получило отрицательное голосование. Если избиратель может дать мне обратную связь, я постараюсь избежать таких действий в будущем.
Кортук
1
то же самое. Это отличный вопрос ....
Джейсон С
Я принял вопрос, потому что, даже подумав, что это открытый конец, у меня было много отличных ответов и я хотел вознаградить хотя бы одного автора за усилия.
Кортук

Ответы:

29

У меня не было большого личного опыта работы с ОСРВ, отличной от QNX (которая в целом хороша, но она недешевая, и у меня был действительно плохой опыт работы с конкретным поставщиком плат, а также отношение QNX к безразличному отношению к другим системам). чем их самый распространенный), который слишком велик для PIC и MSP430.

Где вы получите выгоду от ОСРВ в таких областях, как

  • управление потоками / планирование
  • межпотоковая связь + синхронизация
  • Ввод / вывод в системах с stdin / stdout / stderr или последовательными портами, поддержкой Ethernet или файловой системой (по большей части не MSP430 или PIC, за исключением последовательных портов)

Для периферийных устройств PIC или MSP430: для последовательных портов я бы использовал кольцевой буфер + прерывания ... что-то, что я пишу один раз для системы и просто повторно использую; другие периферийные устройства Я не думаю, что вы найдете много поддержки от RTOS, так как они зависят от производителя.

Если вам нужно время с точностью до микросекунды, ОСРВ, вероятно, не поможет - ОСРВ имеют ограниченную синхронизацию, но, как правило, в их расписании имеется дрожание синхронизации из-за задержек переключения контекста ... QNX, работающий на PXA270, имел дрожание в типичных десятках микросекунд, максимум 100-200 мкс, поэтому я бы не стал использовать его для вещей, которые должны работать быстрее, чем около 100 Гц или которые требуют синхронизации гораздо более точной, чем около 500 мкс. Для такого рода вещей вам, вероятно, придется реализовать собственную обработку прерываний. Некоторые ОСРВ будут хорошо играть с этим, а другие сделают это по-королевски мучительным: ваше время и время не могут хорошо сосуществовать.

Если синхронизация / планирование не слишком сложны, вам лучше использовать хорошо разработанный конечный автомат. Я очень рекомендую прочитать Практические диаграммы состояний в C / C ++, если вы еще этого не сделали. Мы использовали этот подход в некоторых наших проектах, где я работаю, и у него есть некоторые реальные преимущества перед традиционными конечными автоматами в управлении сложностью ... что действительно является единственной причиной, по которой вам нужна ОСРВ.

Джейсон С
источник
Я работаю в стартап-компании, где самые опытные парни из встроенных систем только что закончили колледж (т.е. я и другой парень, который работает со мной около 2 лет). Я провожу очень большую часть времени, обучая себя отраслевой практике в течение моей рабочей недели. Поскольку я читал, мне сообщили для всех, кроме нашей самой дешевой системы, RTOS была бы большим улучшением.
Кортук
Похоже, что система RTOS с очень низким уровнем ресурсов для таких вещей, как PIC и MSP430, может помочь создать детерминированную систему из очень сложной, что также значительно упрощает управление разделением модулей. Я был частью команды из двух человек, которая эффективно создала полевую систему сбора и маршрутизации данных. Теперь, когда я смотрю на RTOS, я вижу, что она идеально подходит для того, что мы разработали.
Кортук
Извините за использование трех почтовых слотов, ваш ответ очень полезен, я ищу решение с очень небольшим ресурсом, но эта информация очень важна, спасибо за помощь.
Кортук
не беспокойтесь о количестве комментариев (ИМХО одна вещь, которой не хватает в платформе StackExchange, - это поддержка обсуждений ... формат Q / A охватывает большинство вещей, но не некоторые) ... звучит так, как будто вы довольно хорошо разбираетесь в том, что Вы ищете. Я не смотрел на FreeRTOS, о котором упоминал Стив, но если он был портирован на микроконтроллеры младшего класса, возможно, он обеспечит необходимое управление расписанием.
Джейсон С
Кажется, что он сохраняет состояние каждого потока через стек (что-то вроде 50 операторов push / pull) и может обрабатывать прерывания по времени. Моя система обычно использует прерывание порта для переключения потоков, но задача выглядит выполнимой. Я хотел бы, чтобы этот тип сайта обрабатывал обсуждение в лучшем формате.
Кортук
26

Вы пробовали FreeRTOS ? Он бесплатный (подлежит T & C) и был портирован как на MSP430, так и на несколько разновидностей PIC.

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

Доступна (не бесплатная) коммерческая лицензия, а также версия МЭК 61508 / SIL 3.

Стив Мельникофф
источник
Огромное спасибо, я посмотрю в течение недели, оставлю вопрос открытым для других ответов, но вы мне очень помогли!
Кортук
12

Я только что узнал о NuttX RTOS, которая может работать даже на 8052 (8-битной) системе. Здесь не так много портов, но выглядит интересно. POSIX может быть плюсом, потому что он может сделать часть вашего кода немного более переносимой, если вы перейдете на более мощный процессор и захотите запустить Linux или QNX в реальном времени.

У меня нет опыта работы с коммерческими ОСРВ, но я годами пользуюсь самодельными! Они прекрасно помогают вам разделить разработку кода между многими программистами, потому что каждый из них, по сути, может получить «задачу» или «поток» для работы со своей стороны. Вам все еще нужно координировать, а кто-то должен контролировать весь проект, чтобы убедиться, что каждая задача может быть выполнена в срок

Я также рекомендую вам исследовать скорость монотонного анализа или RMA при использовании ОСРВ. Это поможет вам гарантировать, что ваши критические задачи будут выполнены в установленные сроки.

Я также хотел бы взглянуть на основанную на событиях инфраструктуру программирования QP-nano Миро Самека, которая может работать с ОСРВ или без нее и при этом предоставлять вам возможности в реальном времени. С его помощью вы делите свой дизайн на иерархические конечные автоматы вместо традиционных задач. Джейсон С. упомянул книгу Миро в своем посте. Отличное чтиво!

Джей Аткинсон
источник
9

Одна вещь, которую я нашел полезным на многих машинах, - это простой стековый коммутатор. На самом деле я не написал ни одного для PIC, но я ожидал бы, что подход будет прекрасно работать на PIC18, если оба / все потоки используют в общей сложности 31 или менее уровней стека. На 8051 основной программой является:

_taskswitch:
  хч а, ИП
  xch a, _altSP
  хч а, ИП
  RET

На PIC я забываю имя указателя стека, но процедура будет выглядеть примерно так:

_taskswitch:
  movlb _altSP >> 8
  movf _altSP, w, b
  movff _STKPTR, altSP 
  MOVWF _STKPTR, c
  вернуть

В начале вашей программы вызовите подпрограмму task2 (), которая загружает altSP с адресом альтернативного стека (16, вероятно, будет работать хорошо для PIC18Fxx) и запускает цикл task2; эта рутина никогда не должна вернуться, иначе все умрет мучительной смертью. Вместо этого он должен вызывать _taskswitch всякий раз, когда он хочет передать управление основной задаче; основная задача должна затем вызывать _taskswitch всякий раз, когда она хочет уступить второй задаче. Часто у одного будут милые маленькие рутины как:

void delay_t1 (беззнаковое короткое значение)
{
  делать
    taskswitch ();
  while ((unsigned short) (millisecond_clock - val)> 0xFF00);  
}

Обратите внимание, что переключатель задач не имеет каких-либо средств для выполнения «ожидания условия»; все, что он поддерживает, - спиннинг. С другой стороны, переключение задач происходит так быстро, что попытка переключателя задач (), пока другая задача ожидает истечения таймера, переключится на другую задачу, проверит таймер и переключится назад быстрее, чем обычный переключатель задач. определил бы, что это не нужно переключать задачи.

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

(Изменить): пара предостережений относительно автоматических переменных и таких:

  1. если подпрограмма, которая использует переключение задач, вызывается из обоих потоков, обычно необходимо скомпилировать две копии подпрограммы (возможно, #include дважды включая один и тот же исходный файл с разными операторами #define). Любой данный исходный файл будет содержать код только для одного потока, или же он будет содержать код, который будет скомпилирован дважды - один раз для каждого потока - поэтому я могу использовать макросы, такие как "#define delay (x) delay_t1 (x)" или #define delay (x) delay_tx (x) "в зависимости от того, какой поток я использую.
  2. Я полагаю, что компиляторы PIC, которые не могут «видеть» вызываемую функцию, будут предполагать, что такая функция может уничтожить все регистры ЦП, что исключает необходимость сохранения любых регистров в подпрограмме переключения задач [хорошее преимущество по сравнению с упреждающая многозадачность. Любой, кто рассматривает подобный переключатель задач для любого другого ЦП, должен знать об используемых соглашениях регистра. Передача регистров перед переключением задач и последующее их извлечение - это простой способ позаботиться о вещах, при условии наличия достаточного места в стеке.

Совместная многозадачность не позволяет полностью избежать проблем с блокировками и тому подобным, но она действительно сильно упрощает вещи. Например, в превентивной ОСРВ с компактным сборщиком мусора необходимо разрешить закрепление объектов. При использовании кооперативного переключателя в этом нет необходимости при условии, что в коде предполагается, что объекты GC могут перемещаться при каждом вызове taskswitch (). Уплотняющий коллектор, который не должен беспокоиться о закрепленных объектах, может быть намного проще, чем тот, который делает.

Supercat
источник
1
Потрясающий ответ. Думаю, было бы интересно получить ссылки на ресурсы по приближению к моей собственной ОСРВ. Я сосредоточился здесь на получении качественной ОСРВ от поставщика, который позаботился о том, чтобы в режиме реального времени обеспечить работу, но для меня это может быть забавным хобби-проектом.
Кортук
1
Круто, никогда не думал о задачах, как просто переключение SP ...
NickHalden
1
@JGord: я сделал крошечные переключатели задач на 8x51 и на TI DSP. Показанный выше 8051 предназначен для двух задач. DSP one используется с четырьмя, и это немного сложнее. У меня просто была сумасшедшая идея: можно справиться с четырьмя задачами, просто используя три переключателя задач. Каждый раз, когда одна из первых двух задач хочет переключать задачи, она должна вызывать TaskSwitch1 и TaskSwitch2. Когда одна из вторых двух задач хочет переключиться между задачами, она должна вызвать Taskswitch1 и Taskswitch3. Предположим, что код начинается в stack0, и каждому переключателю задач присваивается соответствующий номер стека.
суперкат
@JGord: Хм ... это не совсем работает; Похоже, что он дает трехсторонний циклический перебор и игнорирует третий переключатель. Ну, поэкспериментируй, и я думаю, ты найдешь хорошую формулу.
Суперкат
7

Я использовал Salvo на MSP430. Это потребовало очень мало ресурсов процессора и, при условии соблюдения правил реализации, было очень простым в использовании и надежным. Это кооперативная ОС, требующая, чтобы переключатели задач выполнялись на внешнем уровне вызова функций функций задач. Это ограничение позволяет ОС работать на очень маленьких устройствах памяти без использования большого количества стекового пространства, поддерживающего контексты задач.

На AVR32 я использую FreeRTOS. Снова очень надежный, но у меня были некоторые расхождения в конфигурации / версии между версией, которую публикует FreeRTOS, и версией, поставляемой с фреймворком Atmel. Это, однако, имеет то преимущество, что это бесплатно!

uɐɪ
источник
5

Декабрьское издание Everyday Practical Electronics содержит часть 3 из серии «Операционные системы реального времени для PIC» (в столбце «PIC n 'Mix») и содержит подробную информацию о настройке FreeRTOS с MPLAB и PICKit 2. Предыдущие две статьи (которые я описал не видел), кажется, обсуждал достоинства различных ОСРВ и остановился на FreeRTOS. Как только текущая статья настроит среду разработки, они приступят к разработке двоичных цифровых часов. Похоже, что на эту тему есть еще как минимум одна часть.

Я не уверен, насколько доступен EPE в США, но там, похоже, есть магазин в США, связанный с их сайтом, и могут быть электронные копии.

амосс
источник
4

Компилятор CCS для PIC поставляется с простой ОСРВ. Я не пробовал, но если у вас есть этот компилятор, было бы легко поэкспериментировать.

Жанна Пиндар
источник
1
Я действительно попробовал это как мой первый. Это не ОСРВ в любом реальном смысле этого слова. Это не является преимуществом в любом случае. Требуется регулярное использование команд yield, чтобы ОСРВ могла решать, кто будет работать дальше, вы должны преднамеренно вводить их постоянно на случай, если другая программа должна вступить во владение.
Кортук
2
Я думаю, что это все еще называется ОСРВ. Просто звучит так, как будто у него есть кооперативный планировщик вместо полностью вытесняющего планировщика.
Джей Аткинсон
Да, технически это все еще ОСРВ, но я имел и все еще очень мало ценю это. Я знаю, что это личная вещь, но для меня это должно быть преимуществом, чтобы быть ценным. Я все еще +1, так как это был хороший ответ и ценность.
Кортук
3

Тесно связанный вопрос: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

оборота Дэвидкари
источник
Спасибо! Похоже, что большинство людей не поняли вопрос, но это все еще интересно.
Кортук
Я отправил вопрос о SO, приглашая пользователя прийти в E & R за помощью!
Кортук
Я думаю, что мы «получили» вопрос о SO, он задавал что-то другое, но связанное с этим вопросом. Что касается вашего комментария там о сертификации; это зависит от многих вещей. Глядя на ответы здесь, мне нравится ответ DoxaLogos со ссылкой на QP-nano; Мой опыт побуждает меня предпочитать управляемый событиями код по потокам и неявное переключение контекста потоков.
2010 года
2

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

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

  1. Постоянная частота кадров: для PIC, работающего с сервоконтроллером, который должен работать, например, с частотой 1000 Гц. Если для выполнения алгоритма PID требуется менее 1 мс, вы можете использовать оставшуюся часть миллисекунды для выполнения других задач, таких как проверка шины CAN, считывание датчиков и т. Д.

  2. Все прерывания: все, что происходит в PIC, запускается прерыванием. Прерывания могут быть приоритетными в зависимости от важности события.

  3. Вставьте это в петлю и делайте все как можно быстрее. Вы можете найти, что это обеспечивает подходящие временные рамки.

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