RTOS для встроенных систем

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

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

К моменту:

  1. Стоимость ресурсов системы
  2. Преимущества системы
  3. Недостатки системы
  4. Трюки реализации
  5. Ситуации RTOS должны /должны не используется.

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

55 голосов | спросил Kortuk 2 WedEurope/Moscow2009-12-02T23:59:25+03:00Europe/Moscow12bEurope/MoscowWed, 02 Dec 2009 23:59:25 +0300 2009, 23:59:25

9 ответов


29

У меня не было особого опыта работы с RTOS, отличным от QNX (это здорово в целом, но это не дешево, и у меня был очень плохой опыт работы с конкретным продавцом платы и отношением QNX к нам для систем, отличных от их наиболее распространенных), которые слишком велики для ПОС и MSP430.

Где вы будете использовать RTOS в таких областях, как

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

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

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

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

ответил Jason S 3 ThuEurope/Moscow2009-12-03T08:07:37+03:00Europe/Moscow12bEurope/MoscowThu, 03 Dec 2009 08:07:37 +0300 2009, 08:07:37
25

Вы пробовали FreeRTOS ? Это бесплатно (с учетом T & C) и портирован как на MSP430, так и на несколько вариантов ПОС.

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

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

ответил Steve Melnikoff 3 ThuEurope/Moscow2009-12-03T03:05:08+03:00Europe/Moscow12bEurope/MoscowThu, 03 Dec 2009 03:05:08 +0300 2009, 03:05:08
11

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

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

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

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

ответил Jay Atkinson 4 J0000006Europe/Moscow 2010, 01:35:03
9

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

_taskswitch:
  xch a, SP
  xch a, _altSP
  xch a, SP
  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 (unsigned short val)
{
  делать
    taskswitch ();
  while ((unsigned short) (millisecond_clock - val)> 0xFF00);
}

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

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

(Edit): пара предупреждений об автоматических переменных и т. д.

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

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

ответил supercat 16 MaramWed, 16 Mar 2011 07:06:06 +03002011-03-16T07:06:06+03:0007 2011, 07:06:06
7

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

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

ответил ʎəʞo uɐɪ 8 TueEurope/Moscow2009-12-08T19:16:22+03:00Europe/Moscow12bEurope/MoscowTue, 08 Dec 2009 19:16:22 +0300 2009, 19:16:22
5

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

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

ответил Amos 9 WedEurope/Moscow2009-12-09T14:09:17+03:00Europe/Moscow12bEurope/MoscowWed, 09 Dec 2009 14:09:17 +0300 2009, 14:09:17
4

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

ответил Jeanne Pindar 4 J0000006Europe/Moscow 2010, 06:36:57
3
ответил Jeanne Pindar 4 J0000006Europe/Moscow 2010, 06:36:57
2

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

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

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

  2. Все прерывания: все, что происходит в ПОС, инициируется прерыванием. Прерывания могут быть приоритетными в соответствии с важностью события.

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

ответил Rocketmagnet 25 Jam1000000amTue, 25 Jan 2011 01:32:26 +030011 2011, 01:32:26

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132