На две задачи ставить RTOS скорее всего не стоит.
Скажем первичные начальные загрузчики выполняют две задачи обычно: мигают светодиодом и грузят во Flash.
Так тут RTOS не нужна.

Сама RTOS с неактивными задачами тратит 1-2% процессорного времени. В основном это работа процедур обработки системного тика который штатно делают частотой 100 Гц.
Можно переводить процессор в состояние idle если задачи не активны.

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

RTOS реально абсолютно необходима когда вы интенсивно используете стороннее middleware.
Скажем GUI, прикладной уровень TCP стека, файловые системы, протоколы IoT, интерпретаторы скриптов, парсеры, базы данных и т.д.
В таких случаях без движка вытеснения одних задач другими даже светодиодом будет трудно моргать.

Как классические примеры работы с RTOS можно посмотреть открытые проекты управления роботами, мультикоптерами и т.д.
Там популярны NuttX, ChibiOS, FreeRTOS
Перспективно вроде бы CMSIS-RTOS API, которое сейчас реализовано поверх Keil RTX, поскольку это развивает сам ARM в проекте mbed.org

Я бы конечно рекомендовал MQX. Очень хорошая поддержка в IAR и Keil, есть версия Lite для чипов с 2 кб RAM. Быстрее работает чем FreeRTOS, а сервисов больше.

Спасибо за мнение. Я так понимаю MQX платная в общепринятом понимании...

Интересно что есть общее мнение "применение ОС делает жизнь однозначно легче".

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

Так что сомнения, сомнения, сомнения....

Звучит как "ну уговорите же меня".


Отладка не усложняется, потому что код каждой задачи становится заметно проще.

Я вот FreeRTOS использую, так большую часть кода вообще на компьютере отлаживаю.

Это только так кажется. Без ОС ведь с прерываниями работаете? А это тоже разновидность обмена между потоками.

MQX бесплатная.

Лучше бы описали подробнее ваш случай, мы бы его разобрали в применении к RTOS.

Но вообще как раз с отладкой RTOS друг от друга отличаются значительно.
Труднее всех отлаживать это как раз опенсорсные изначально оси.

В коммерческих изначально, но потом открытых осях, как MQX все гораздо легче.
Интеграция в IAR скажем означает, что можете видеть состояния всех задач, всех мьютексов, очередей и т.д. Кто ожидает, кто активен, сколько стека свободно, кто в какой последовательности выполняется и т.д.
Любая переменная доступна , встроенные логи для произвольных сообщений, логи ядра RTOS.

Не имея RTOS вам все равно нужны логи, только делать их вам нужно вручную.

Осциллографический реалтайм движок FreeMaster в MQX позволяет в реальном времени на максимальной скорости снимать осциллограммы с любого сигнала или переменной в программе.
Эт тоже всегда надо, но без RTOS придется делать вручную.

Логи писать в файл на SD карте тоже захочется рано или поздно. Без RTOS файловую систему нормально не внедрите.

Сколько ресурсов времени занимают ваши задачи тоже без RTOS труднее понять.

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

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


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

Наверное еще от задачи зависит, если это какая-то обработка и регулировка, то это один расклад. А если это перекладка и перераспределение данных между модулями проца, то это несколько другое... как мне видится. Может в этом и отгадка, поскольку все мы делаем разные задачи, потому по разному встает вопрос целесообразности ОС?...

Хорошо, когда все нюансы в ТЗ подробно расписаны, а клиент и исполнитель одинаково понимают и сложные, и, казалось бы, очевидные элементарные вещи.
Хорошо ещё, когда нет сложных законов управления, зависящих от кучи переменных (в том числе от времени), все комбинации значений которых непросто тестировать.

Это уже слегка не в тему, но, по опыту, люди не желают платить за дополнительный функционал. Если сравнивать два изделия, допустим, одно из которых стоит 300 рублей, другое - 400, и за 400 дают пару-тройку каких-то фич помимо базового функционала того, что за 300, то объемы продаж того, что за 300, превышают объемы продаж того, что по 400 на порядок, и, нередко, не на один. Так что, опять же, продажи определяют направление модернизации... Это первое. А второе - при любом раскладе, если норма прибыли у устройства небольшая, а спрос постоянный, стоит снижать себестоимость всеми возможными путями. Это прямое содержимое Вашего кармана.

AlexandrY спасибо! Есть над чем подумать.



Мой случай на самом деле такой. У меня намечается вялый проект на сроки гораздо большие чем надо для его реализации. Потому хочу попробовать что-то новое, в частности применить ОС.
Задача там примитивна сбор данных с нескольких каналов АЦП, минимальная первичная обработка, и выдача их по SPI. Если я воткну туда ОС это однозначно вызовет вопросы, если при этом производительность не пострадает, то я на них отвечу, а если сильно пострадает, то будет ОЙ... Это маленький модуль большой системы, на одну конкретную функцию.


Если же говорит про задачи где я вижу реальный смысл применения ОС, так там система выглядит так.
Процессор связан с РС по езернет(ТСР/IP) и с другой стороны с FPGA через 2 SPI и UART, третей силой выступает HID манипулятор через USB.
Задачи процессора - это ТСР стэк, протокол поверх ТСР, и обмен с FPGA, упаковка-распаковка данных, контрольные суммы, хэндшейки и т.д. А также обработка USB.

По UART валиться статусы, их надо собирать, проверять что они пришли правильно и с заданным временным расписанием отправлять в РС.

По SPI идут данные РС - FPGA и обратно. Процессор только забирает что послать из ТСР, формирует пакеты для FPGA с добавлением чек сумм, а потом проверяет что они дошли до FPGA, и сообщает об этом РС, а также забирает данные из FPGA если есть ответы и шлет их РС.
USB, пока примитивная обработка HID манипулятора, и формирование управляющих сигналов для FPGA
Все остальное делает FPGA с буферизацией данных для работы и ответов, но оперативность поступления свежих данных для работы FPGA весьма важна.

Система построена и нормально работает, обеспечивая где-то 1-5 мСек реакцию системы, состояние манипулятора обрабатывается раз в 10 мСек и когда он обрабатывается это немного притормаживает общий цикл, плюс иногда ТСР стэк свои очереди чистить, на АРП отвечает и так далее... Так что время реакции плавает, но это нормально.

Но в системе есть CAN и еще 3 UARTа их заложили на будущее, и они никак не олапачиваются сейчас. Но все чаще возникаю мысли на них что-то повесить. И вот добавление этого в эту стройную систему вызывает некую боль. И мне кажется будь в системе ОС я бы просто добавил задачи и не страдал так, как буду страдать, когда буду внедрять доп функции и тестировать как поехала времянка от новых конечных автоматов.

За анализ системы с точки зрения ОС буду очень благодарен.












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



Это разные товары вы говорите про товары с эластичным спросом. Есть товары которые продаются Н штук в год, и сделай их хоть 1 доллар, все равно их больше Н не купять, а заломи цену в 2 раза, и опять их купят ровно Н штук. И тут как раз вопрос чтобы купили Н у тебя а не у конкурента.

Вот есть система тестов и диагностики продукта. Ей пользуются по 100 раз на дню. И если есть система которая стоит 2000 и делает диагностику 1 минуту 30 сек, и есть система за 5000 с временем диагностики 50 секунд. Даже вопросов не будет все купят вторую. Систему покупают один раз на много лет, разница в 3000 размажется и пропадет, а вот 40 секунд выигрыша времени накопиться в часы...

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

Вот есть и такие рынки...

На мой взгляд для всего описанного вовсе не нужна RTOS (в части RT). Это все очень хорошо должно лечь на обычный Linux, если ресурсы позволяют. Правда Cortex ему не M, а А нужен. Но зато там почти все уже написано до нас и за нас.


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

Поднять TCP без RTOS и еще что-то с ним параллельно это сильно.
Не удивительно что вас потянуло на RTOS.

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

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

По моему, ОС нужна если задачи в основном асинхронные и их больше 3, грубо говоря.
Если это тупо state machine, можно и простой луп.

Засады с ОС:
1) чем больше кода, тем больше багов - я в CoOS выловил уже 3.
2) Вылавливать баги бывает очень нетривиально. На 1 баг, например, у меня ушло 2 недели: полдня кодировал ловушку, потом 2-3 дня ждал,
пока попадется. Баг сильно зависел от "направления и силы ветра в четверг".
3) анализировать и искать хомуты тоже сложней, я добавил к описаниям таска несколько счетчиков, имя функции, линия и т.д.
Каждый раз заходя в функцию, назначал их. Таки поймал. Проблема была что через много часов случайно ОС уходила в дедлок

А так - довольно легкая, удобно, приятно..
Ресурсов есть мало.
В принципе мне нравится. Хочу попробовать другую ОС, но боюсь багов.
Тут уже все вроде исследовано.

Сообщение отредактировал A. Fig Lee - Apr 7 2015, 10:13

Это должно автоматически распространяться и на другие операционки?


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

Это распространяется на любой код И ОС, и не ОС.

То есть вероятность того, что A. Fig Lee возьмёт любую другую операционку и найдёт в ней 3 бага, велика?