Потребления ресурсов пустой системой, Когда оправдано ставить операционку? Опции

[Golikov A.]

Всем привет!

В одной ветке кто-то упомянул что кортексы изначально созданы для операционных систем как птица для полета.

И вот тут я задумался. Где грань когда стоит ставить операционку, а когда нет?

1. Все говорят что если 1-2 задачи, то супер лупа хватит, но где гарантия что через полгода жизни проекта задач не станет больше, да и для 2 задач иногда крайне муторно руками балансировать нагрузку.
2. С другой стороны ставить ее всегда, наверное тоже не правильно, так как все же ресурсы она какие-то отъедает.

И вот тут возникли вопросы. А сколько ресурсов отъедает сама по себе операционная система. Имеется ввиду не флеша, а именно быстродействия.

Если взять допустим 2 задачи:
собирать данные по АЦП и отправлять их наружу по какому-то интерфейсу, допустим SPI. Можно ли утверждать что при правильной организации программы быстродействие системы с операционкой и без будет одинаково? Так как обе задачи поддержаны аппаратно и в целом не грузять проц на 100%.

И как бы обратная задача, при какой организации (что надо делать) чтобы операционка дала проигрыш?

Или же сейчас такие времена что пора ее пихать везде и всегда и не думать?

[Golikov A.]

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

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

Мой случай на самом деле такой. У меня намечается вялый проект на сроки гораздо большие чем надо для его реализации. Потому хочу попробовать что-то новое, в частности применить ОС.
Задача там примитивна сбор данных с нескольких каналов АЦП, минимальная первичная обработка, и выдача их по 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 раза без ошибок...

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

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

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

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

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

[AlexandrY]

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

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

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

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

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