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

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

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

К точке:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одна вещь, которую я нашел полезным на многих машинах, - это простой стековый коммутатор. На самом деле я не написал ни одного для 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 (). Уплотняющий коллектор, который не должен беспокоиться о закрепленных объектах, может быть намного проще, чем тот, который делает.

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

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

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

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

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

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

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

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

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

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

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