caxapa.ru :: Какие существуют принципиальные/фундаментальные ограничения на применение RTOS?

Peter_M (14.08.2019 17:30, просмотров: 36289)

Какие существуют принципиальные/фундаментальные ограничения на применение RTOS? Как определяются простые границы применения? Ясно, что применять или не применять RTOS в своих проектах можно по многим субъективным причинам. Что я имею в виду? Вот у вас есть задание разработать некое устройство/систему, вы сформировали свое видение "что" и "как" надо разработать. Потом решаете вопрос, применять RTOS или нет. При этом аппаратных ограничений нет - с памятью программ для ядра RTOS и памятью данных для объектов RTOS проблем нет – хватает с запасом. Можно ли сразу сказать (в зависимости от класса, к которому можно отнести вашу задачу (задание), что применение RTOS здесь невозможно (на основе каких-то метрик или свойств RTOS спроецированных на выбранный вами микроконтроллер)? Например, в вашей проектируемой системе нужно будет обрабатывать один быстрый процесс с периодом 50 мкс. Если сделать его обработку в задаче RTOS у которой настроен тик/квант работы планировщика 1 мс, то значит RTOS, не подходит? Если уменьшать системный тик до 10 мкс, то в итоге упремся на накладные расходы - во время реакции RTOS и далее время переключения контекста (от 1 до 20 мкс в зависимости от RTOS, производительности МК). И фактически RTOS только и будет что переключать контекст и работать в одной задаче. То есть я правильно понимаю, что принципиальное ограничение для применения RTOS это квант времени работы диспетчера, и если он не может быть значительно меньше 1мс? Сразу прощу прощения за кашу в моей голове, я начинающий в этом. Спасибо!

Ответить

- ёмоё, ну откуда вы взяли этот маразм, что у RTOS скорость реакции напрямую зависит от частоты систика? Уже в который раз на него натыкаюсь в интернетах. lloyd(240 знак., 03.09.2019 15:06)
- Если ресурсов хватает, то нет таких границ. Быстрые короткие обработчики нужно делать в прерываниях хоть с, хоть без ртос. - =AlexD=(03.09.2019 09:03)
- Если ты готов реализовать алгоритм работы устройства целиком (в одиночку или коллективом) нахуй все РТОС, если нет, то это самое оно. - Codavr(02.09.2019 19:33 - 19:36)
- Если разработку будут вести несколько человек, то однозначно надо использовать RTOS при таких условиях. Что касается вашей задачи - Задача с требуемым периодом обработки просто висит на событии. Событие устанавливается в прерывании таймера с il-2(189 знак., 15.08.2019 18:43)
  - О, RTOS, великий и всемогущий! ;) Если люди могут договориться, то они договорятся хоть с лупом, хоть с ртосом. - VLLV(15.08.2019 20:02)
- У нас вот цикл 125 мкс, без rtos исторически так сложилось... но очень бы хотелось, потому как долгие неприоритетные задачи сейчас приходится "размазывать" руками - sav6622(14.08.2019 18:02)
  - В чём проблема размазать? Вроде бы protothreads делает это довольно простой задачей. - SciFi(14.08.2019 18:07)
    - Анализировал я их для применения, но чего то так и не дошел, непомню что остановило. Надо бы вернуться взвесить снова. - sav6622(14.08.2019 18:35)
      - Кооперативную не хотите попробовать? Написана на С, без ассемблера - =AK=(02.09.2019 05:37, ссылка)
        
        1) Гм, если размер int не равен разрядности процессора - можно огрести забавных глюков. LightElf(230 знак., 02.09.2019 17:32)
        
        Я с 8-битными Ардунками пользовал, глюков не заметил. =AK=(112 знак., 03.09.2019 00:17)
        
        1) просто везло или не заметили. У вас счётчик задержки модифицируется и основной задачей и обработчиком прерывания, без каких-либо средств обеспечения атомарности LightElf(67 знак., 03.09.2019 01:11)
        
        Под Ардуиной я даже прерывания не использую, задержки сделаны на основе millis() - =AK=(03.09.2019 02:13, ссылка)
        
        Если б я еще знал, что такое millis(). Вообще, использовать setjmp/longjmp нужно аккуратно и вдумчиво, там граблей разложено много. Конкретно у вас есть конструкция res = setjmp(bla-bla), которая, ЕМНИП, с точки зрения стандарта есть Undefined LightElf(724 знак., 03.09.2019 09:54 - 10:20, ссылка)
        
        millis(0 - стандартная функция Ардуино, возвращает uint32_t, кол-во миллисекунд с момента старта. Об атомарности позаботились в ней. =AK=(2209 знак., 03.09.2019 11:24 - 11:51)
        
        Кстати, да. Но допилить вроде бы несложно. - SciFi(03.09.2019 10:39)
        
        Это да. Но там еще грабли есть со стеком. Суть, кагбэ, в том, что вообще говоря никто не гарантирует, что выпрыгнув однажды из функции по longjmp можно будет в нее потом запрыгнуть назад. Компилятор имеет полное право раскладывать на стеке свои LightElf(249 знак., 03.09.2019 11:08)
        
        Вот, кстати, прекрасная цитата. "Оставь надежду, всяк сюда входящий": SciFi(380 знак., 03.09.2019 11:49)
        
        Это мне не понятно. Я же не надеюсь на постоянство содержимого стека, при выходе сохраняю контекст, при входе - восстанавливаю. Какая при этом разница, кто там что перезатер в промежутке? - =AK=(03.09.2019 11:30)
        
        Компилятор имеет полное право раскладывать в стеке свое грязное белье и никому об этом не говорить. - LightElf(03.09.2019 11:55)
        
        Не вижу, как это соотносится с моим предыдущим высказыванием. - =AK=(03.09.2019 12:16)
        
        setjmp сохраняет регистры процессора и указатель стека. Содержимое стека она не сохраняет. А там компилятор может разложить всякое, после longjmp это всякое окажется ниже указателя стека и его может порушить любой залетевший дятел. - LightElf(03.09.2019 13:18)
        
        В описании ограничений coos ясно сказано, что из функций вызывать DELAY() нельзя, можно только из самой задачи. =AK=(410 знак., 03.09.2019 13:32 - 13:57, ссылка)
        
        Сама задача (COOS_Task0, COOS_Task1 и тыды в файле main.c LightElf(90 знак., 03.09.2019 14:32)
        
        Угу, функция. Но для ее восстановления стек не нужен, только регистры, а главное - PC. Как из нее вышли, так в нее и вернемся. - =AK=(03.09.2019 14:35)
        
        Не буду повторяться - LightElf(03.09.2019 14:58, ссылка)
        
        C ESP32 бабушка натрое сказала =AK=(444 знак., 03.09.2019 15:22 - 15:25)
        
        Насколько я понял, есть два варианта ABI для Xtensa. Называются Windowed и CALL0. Windowed ABI весьма замутненный, камменты реализации setjmp жгут напалмом. - LightElf(03.09.2019 17:09, ссылка)
        
        Что вижу (сорец на гитхабе) - о том и пою. Обсуждать какой-то другой код за глаза - не готов. - LightElf(03.09.2019 14:08)
        
        Там к сорцам еще описание приложено, README.md Как интегральная составная часть. А за "проверку на вшивость" - спасибо. - =AK=(03.09.2019 14:12 - 14:26)
        
        Э-э, так нечестно. Если компилятор любит так безобразничать, пусть отслеживает, что вот тут longjmp, отставить безобразия. - SciFi(03.09.2019 11:28)
        
        Насколько я помню, setjmp/longjmp не предназначены для впрыгивания "внутрь" (вниз по стеку). Они, кагбэ, предназначены для выпрыгивания из вложенных функций (вверх по стеку). Т.е. если A() вызывает B(), а B() вызывает C(). То из C() выпрыгнуть в LightElf(214 знак., 03.09.2019 11:53)
        
        Если из функции вышли, возвращаться туда не имеет физического смысла, это кагбэ очевидно. Фарш невозможно провернуть назад :-) - SciFi(03.09.2019 11:58)
        
        Спасибо, интересно - Vit(02.09.2019 11:28)
        
        "Написана без ассемблера", а setjmp и longjmp что такое? - Ale3000(02.09.2019 10:37)
        
        Это функции стандартной библиотеки С setjmp. =AK=(168 знак., 02.09.2019 11:43)
        
        Тогда и оператор if/while за ассемблер посчитаем, там же JC/JNC/JZ/JNZ используется. - Dingo(02.09.2019 10:46)
        
        Нет. Здесь longjmp из одной функции в другую ходит. На С такое сделать нельзя никак. - Ale3000(02.09.2019 11:18)
        
        if/while тоже нельзя средствами самого же языка никак нельзя. А то, что setjump/longjump выбивается из основной идеологии языка - нет ничего совершенного. Лучше задать вопрос: Dingo(326 знак., 02.09.2019 11:42)
        
        Тогда уж и protothreads от Adam Dunkels посмотрите. - Dingo(02.09.2019 06:12 - 06:17, ссылка, ссылка)
        
        Я смотрел, не понравилось. Вижу единственное достоинство в том, что она вообще ни от чего не зависит. =AK=(212 знак., 02.09.2019 11:47 - 11:54)
        
        Что не понравилось? Как по мне, НАЗВАНИЯ_МАКРОСОВ оставляют желать, а в остальном всё прекрасно. - SciFi(02.09.2019 12:11)
        
        Неудобно пользоваться. =AK=(343 знак., 02.09.2019 12:45)
        
        Нет ничего проще: SciFi(286 знак., 02.09.2019 13:17)
        
        Ну а в coos это просто DELAY(val); - =AK=(02.09.2019 13:25)
        
        Можно ещё сократить: DLY(v) :=) - SciFi(02.09.2019 13:29)
        
        Важнее pt выбросить. На кой этим голову забивать. - =AK=(02.09.2019 13:33)
        
        Есть такой нюанс. Если использовать разные имена для этой штуки, при переносе кода легко забыть исправить, и будут феерические глюки (из опыта говорю). Поэтому разумно всегда передавать в поток pt первым аргументом, на манер this. - SciFi(02.09.2019 13:37)
        
        а как с задержками в функциях, которые вызываются в задачах? - Vit(02.09.2019 13:12)
        
        Задержки можно только в задачах, это ограничение coos. Нет в мире совершенства. =AK=(298 знак., 02.09.2019 13:16 - 13:18)
- Есть разные реализации RTOS. Но если делать период 50микросекунд, то это может вызвать пробуксовку OS. Основное время будет тратится на переключение задач. misyachniy(195 знак., 14.08.2019 17:35)
- 50 мкс - это обращайтесь к прерываниям (по таймеру, например). RTOS это не запрещает. - SciFi(14.08.2019 17:32)
  - 50 мкс это как пример. А если 15 мкс (сейчас такая задача)? Это периодический процесс, фактически аналог задачи RTOS. А в прерываниях это получается ниже уровня RTOS? Это нормальная ситуация, дозволено так делать или такая подковёрная активность Peter_M(34 знак., 14.08.2019 17:44)

Микроконтроллеры