RTOS для вбудованих систем


57

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

Я використовував мікроконтролери з низькими ресурсами (MSP430, PIC) і шукав RTOS, які я можу використовувати.

До речі:

  1. Ресурсна вартість системи
  2. Переваги системи
  3. Недоліки системи
  4. Прийоми в реалізації
  5. Ситуації, в яких не слід застосовувати RTOS.

Я не використовую такі системи, як arduino, проекти, з якими я працюю, не можуть підтримувати вартість такої системи.


2
Мене бентежить те, за що це отримав перемогу. Якщо виборець міг би дати мені відгуки, я намагаюся уникнути такої дії в майбутньому.
Кортук

1
ditto. Це чудове питання ....
Jason S

Я прийняв питання, бо, навіть думаючи, що це відкрито, я отримав ряд чудових відповідей і хотів нагородити хоча б одного письменника за зусилля.
Кортук

Відповіді:


29

Я не мав особливого особистого досвіду з іншими, ніж QOS, ніж QNX (що в цілому чудово, але це не дешево, і я мав дуже поганий досвід роботи з конкретним постачальником плати і QNX ми не байдуже ставимось до інших систем ніж їх найпоширеніший), який занадто великий для ПІК та MSP430.

Де ви отримаєте вигоду від RTOS, є в таких областях, як

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

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

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

Якщо терміни / планування не надто складні, вам може бути краще використовувати добре розроблену машину штату. Настійно рекомендую прочитати практичні державні діаграми на C / C ++, якщо ви ще цього не зробили. Цей підхід ми використовували в деяких наших проектах, де я працюю, і це має деякі реальні переваги перед традиційними державними машинами для управління складністю .... це дійсно єдина причина, що вам потрібен RTOS.


Я працюю в стартап-компанії, де найдосвідченіші хлопці з вбудованими системами якраз поза коледжем (тобто я та інший хлопець, який працює зі мною вже близько 2 років). Я витрачаю дуже велику частину часу, навчаючи себе про галузеву практику під час свого робочого тижня. Як я читав, мене проінформували всі, окрім нашої системи з найнижчими витратами, RTOS було б великим покращенням.
Кортук

Схоже, існує дуже низька ресурсна система RTOS для таких речей, як PIC та MSP430, які можуть допомогти створити детерміновану систему із дуже складної, а також значно очистить наше управління збереженням розділених модулів. Я був членом команди з двома людьми, яка ефективно створила систему збору даних та маршрутизації на місцях. Тепер, коли я дивлюсь на RTOS, я бачу, що він ідеально підходить для того, що ми розробили.
Кортук

Вибачте за використання трьох слотів для публікації, ваша відповідь дуже корисна, я шукаю дуже низький ресурс, але ця інформація є цінною, дякую за допомогу.
Кортук

не хвилюйтеся з приводу кількості коментарів (одне, що їм не вистачає в StackExchange, це підтримка дискусій ... Формат Q / A охоплює більшість речей, але не деякі) ... звучить так, що ви маєте досить гарну справу з тим, що ви шукаєте. Я не дивився на FreeRTOS, про який згадував Стів, але якщо він був перенесений на мікроконтролери низького класу, можливо, він зробить необхідне управління плануванням.
Jason S

Здається, зберегти стан кожного потоку, хоча стек (щось на зразок 50 заяв "push / pull") і може обробляти тимчасові переривання. Моя система зазвичай використовує переривання порту для комутації потоків, але це завдання виглядає виконаним. Я хочу, щоб цей веб-сайт обробляв дискусію в кращому форматі.
Кортук

26

Ви пробували FreeRTOS ? Він безкоштовний (підлягає T&C) і переноситься як на MSP430, так і на кілька ароматів PIC.

Він невеликий порівняно з деякими іншими, але це також полегшує навчання, особливо якщо ви раніше не використовували RTOS.

Доступна комерційна ліцензія (не вільна), а також версія IEC 61508 / SIL 3.


Дякую тони, я вивчу це протягом тижня, я залишаю питання відкритим для інших відповідей, але ви чудова допомога!
Кортук

12

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

Я не маю жодного досвіду роботи з комерційними RTOS, але я використовую домашні вироби роками! Вони чудово допомагають вам розділити розробку коду між багатьма програмістами, оскільки вони по суті можуть отримати "завдання" або "нитку" для роботи зі свого боку. Ви все ще повинні координуватись, і хтось повинен контролювати весь проект, щоб переконатися, що кожне завдання може визначити його термін.

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

Я також роздивився би програму програмування, керовану подіями, керовану QP-nano Miro Samek, яка може працювати з RTOS або без нього, і все ще надасть вам можливість у режимі реального часу. За допомогою цього ви поділяєте свій дизайн на ієрархічні машини стану замість традиційних завдань. Джейсон S згадав про книгу Міро у своєму пості. Відмінне прочитання!


9

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

_taskswitch:
  xch a, SP
  xch a, _altSP
  xch a, SP
  рет

На 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 (непідписаний короткий val)
{
  робити
    taskwitch ();
  while ((непідписаний короткий) (milisecond_ clock - val)> 0xFF00);  
}

Зауважте, що програма переключення завдань не має жодних засобів виконувати будь-які "очікування умови"; Все, що він підтримує, - це закрутка. З іншого боку, перемикач завдань настільки швидкий, що спроба перемикача задач (), поки інша задача чекає закінчення таймера, переключиться на інше завдання, перевірить таймер і повернеться назад швидше, ніж типовий перемикач завдань визначив би, що це не потрібно, щоб завдання перемикати.

Зауважте, що багатозадачність кооперативу має деякі обмеження, але це дозволяє уникнути потреби у великій кількості блокування та іншого коду, пов’язаного з мютексами, у випадках, коли інваріанти, які тимчасово порушуються, можуть бути відновлені швидко.

(Редагувати): пара застережень щодо автоматичних змінних та таких:

  1. якщо рутина, яка використовує перемикання завдань, викликається з обох потоків, зазвичай потрібно буде скласти дві копії процедури (можливо, #including один і той же вихідний файл двічі, з різними операторами #define). Будь-який заданий вихідний файл буде або містити код лише для одного потоку, або ж буде містити код, який буде скомпільовано двічі - один раз для кожного потоку - тому я можу використовувати макроси типу "#define delay (x) delay_t1 (x)") або #define delay (x) delay_tx (x) "залежно від того, який потік я використовую.
  2. Я вважаю, що компілятори PIC, які не можуть "побачити" викликану функцію, припускають, що така функція може переносити будь-які регістри процесорів, тим самим уникаючи необхідності зберігати будь-які регістри в програмі переключення завдань [приємна вигода порівняно з переважне багатозадачність]. Кожен, хто розглядає подібний перемикач завдань для будь-якого іншого процесора, повинен бути обізнаний з умовами використання реєстру. Натискання на регістри перед перемикачем завдань і вискакування після них - простий спосіб піклуватися про речі, якщо припустити, що існує достатня кількість стека.

Спільна багатозадачність не дозволяє повністю уникати питань блокування та подібного, але це дійсно значно спрощує речі. Наприклад, у превентивному RTOS із ущільнювальним сміттєзбірником потрібно дозволити закріплювати предмети. При використанні кооперативного комутатора це не обов'язково за умови, що код передбачає, що об'єкти GC можуть переміщуватися в будь-який час виклику taskwitch (). Колектор для ущільнення, який не повинен турбуватися про закріплені об'єкти, може бути набагато простішим, ніж той, що робить.


1
Дивовижна відповідь. Я думаю, що було б цікаво отримати деякі посилання на ресурси щодо наближення до моєї власної RTOS. Моя увага тут справді полягала в тому, щоб отримати високоякісний RTOS від постачальника, який зробив роботу із забезпечення важкого реального часу, але це може бути цікавим проектом для любителів.
Кортук

1
Класно, ніколи не вважав завдання просто переключенням
ІП

1
@JGord: Я робив крихітні перемикачі завдань на 8x51 та TI DSP. 8051, показаний вище, розрахований на точно два завдання. DSP один використовується з чотирма, і це трохи складніше. У мене просто була шалена ідея: можна було впоратися з чотирма завданнями, просто скориставшись трьома майстрами завдань. Щоразу, коли одне з перших двох завдань хоче переключити завдання, воно повинно викликати TaskSwitch1 та TaskSwitch2. Коли одне з двох інших завдань хоче переключити задачі, воно повинно викликати Taskswitch1 та Taskswitch3. Припустимо, код починається з стека0, і кожен перемикач завдань встановлюється відповідним номером стека.
supercat

@JGord: Хм ... це не зовсім працює; це здається, що дає 3-х напрямний кругообіг і ігнорує третій перемикач. Ну, експериментуйте, і я думаю, ви, мабуть, знайдете хорошу формулу.
supercat

7

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

На AVR32 я використовую FreeRTOS. Знову дуже надійний до цих пір, але у мене були деякі розбіжності в конфігурації / версії між версією, яку публікує FreeRTOS, і версією, що постачається з рамкою Atmel. Однак це має перевагу в тому, що вона безкоштовна!


5

Грудневе видання Everyday Practical Electronics має частину 3 серії про операційні системи в режимі реального часу для PIC (у колонці PIC n 'Mix) і містить детальну інформацію про налаштування FreeRTOS з MPLAB та PICKit 2. Попередні дві статті (про які я не бачили), як видається, обговорювали достоїнства різних RTOS та зупинялися на FreeRTOS. Після того, як поточна стаття налаштує середовище розробки, вони продовжують розробляти бінарний цифровий годинник. Здається, що на цю тему потрібно принаймні ще одну частину.

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


4

Компілятор CCS для PIC постачається з простим RTOS. Я не пробував цього, але якщо у вас є цей компілятор, було б легко експериментувати.


1
Я насправді спробував це як своє перше. Це не RTOS в будь-якому реальному значенні цього слова. Це ні в якому разі не перешкоджає. Це вимагає регулярного використання команд прибутковості, щоб RTOS міг вирішувати, хто працює наступним чином, ви повинні навмисно постійно їх вводити, якщо інша програма повинна взяти на себе.
Кортук

2
Я думаю, що це все ще називається RTOS. Це просто звучить, як у нього є спільний планувальник замість повністю превентивного планувальника.
Джей Аткінсон

Так, це технічно все ще RTOS, але я мав і все ще маю це дуже мало. Я знаю, що це особиста річ, але для мене це має бути превентивним, щоб бути цінним. Я все ще +1, оскільки це була хороша відповідь і цінність.
Кортук

3

Питання, що пов'язані між собою: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18


Дякую! Схоже, у більшості людей питання не виникало, але все ж цікаво.
Кортук

Я розмістив запитання на ТАК, запросивши користувача прийти до E&R за допомогою!
Кортук

Я думаю, що ми "отримали" запитання щодо SO, воно задавало щось інше, але пов'язане з цим питанням. Щодо вашого коментаря щодо сертифікації; це залежить від багатьох речей. Дивлячись на відповіді тут, мені подобається відповідь DoxaLogos, що стосується QP-nano; мій досвід призводить до того, що я віддаю перевагу коду, керованому подіями, через потоки та неявну контекстну комутацію потоків.
janm

2

Ви мало сказали про свою заявку. Чи буде ви використовувати RTOS, багато в чому залежить від того, що вам потрібно зробити в PIC. Якщо ви робите кілька різних асинхронних речей, для яких потрібні строгі часові рамки, або у вас є кілька потоків, тоді RTOS може бути надмірним.

Існує багато способів організації часу на мікроконтролері залежно від того, що найважливіше:

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

  2. Всі переривання: Все, що відбувається в PIC, спрацьовує перериванням. Перерви можна визначити пріоритетними відповідно до важливості події.

  3. Заклейте його в петлю і зробіть все так швидко, як тільки зможете. Ви можете виявити, що це забезпечує відповідні часові рамки.


Я розумію інші методи, але хочу розширитись до RTOS. Я буду виконувати кілька завдань і мати жорстку систему в режимі реального часу, але готовий почати без вимог жорсткого реального часу. Дякую, що знайшли час для відповіді, але я хочу вивчити RTOS, щоб я міг використовувати його в умовах високого попиту.
Кортук
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.