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

[Golikov A.]

Всем привет!

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

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

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

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

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

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

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

[Golikov A.]

Спасибо откликнувшимся%)

SM - у вас экстрим по жизни Вы совсем не помогаете)) советы звучат типа "а все равно вы человек пропащий, ресурсов не жалеете, прибыль не имеет, вам что с ОС что без все одно..."
adnega - возможно вы, но и не только. Я читал статейки разные, ведь даже спец прерывание есть у кортексов. Почему сейчас не используете ОС, тем более если все время думаете?
ViKo - спасибо за отзыв. Меня тоже немного пугает что не пойми что внутри ОС, все же объем кода что за неделю не прочтешь не разберешься, по любому придется доверять в слепую...

Чуть подробнее о том что есть:

У меня процик 100 МГц организует обмен ПЛИС и РС, то есть все критичное к синхрону делается в ПЛИС, а процик считай данные перебрасывает, докидывает контроль целосности данных и протокол.
Потому по флешке у меня запас огромный, я 2 блока съел из десятка. А вот по тактам запаса нет. Вернее не то что нет, просто чем быстрее проц будет все прокручивать тем быстрее будет отклик.
При этом работоспособность сохраниться даже если запустить его на 8 МГц, просто будет все вяло и не красиво.

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

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

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

[SM]

SM - у вас экстрим по жизни Вы совсем не помогаете)) советы звучат типа "а все равно вы человек пропащий, ресурсов не жалеете, прибыль не имеет, вам что с ОС что без все одно..."

Нет никакого экстрима. Совершенно тупо вопрос денег, и ничего больше. Если Вам удобнее, быстрее и/или проще сделать с ОС, и на Ваш карман это никак не повлияет, то делайте, естественно, с ОС. Время и силы - тоже деньги И я бы так же бы сделал, как и Вам советую. Если же от решения без ОС (или с ОС) каким либо образом карман пополнится, то, конечно, надо делать без ОС (или с ОС). Все остальное - это просто риторика. То есть, треп.

Еще раз повторю - не придушите Вы его ОСкой, если памяти достаточно. Ну 1% может, потеряется, вряд ли более, скорее, менее. Если не переусердствовать с принудительным переключением задач через излишние перебросы управления между тредами через объекты синхронизации. Экономить на ОС есть смысл тогда, когда за счет отсутствия ОС можно применить более дешевый процессор, за счет чего получить какую-то вменяемую прибыль. Если этого нет - то решение ТОЛЬКО на уровне Вашего личного удобства, как Вам удобнее, проще, быстрее.

[AHTOXA]

Выскажусь тоже.
С тех пор, как я попробовал использовать RTOS (scmRTOS) в микроконтроллерах, я делаю все проекты только с RTOS.
Ось очень маленькая и быстрая. Накладных расходов - мало, удобств - много
Что нравится:
- Удобное распараллеливание задач;
- Лёгкость организации фоновых процессов;
- Удобно ждать события/прерывания;
- Очереди, события, флаги, мьютексы. Оч. удобные штуки;
- Значительно более понятный и сопровождаемый код.

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

[MiklPolikov]

Выскажусь тоже.
С тех пор, как я попробовал использовать RTOS (scmRTOS) в микроконтроллерах, я делаю все проекты только с RTOS.
Сейчас, когда приходится возвращаться к старым безосевым проектам для сопровождения, ужасаюсь этой мешанине коллбэков, машин состояний, конечных автоматов и вызовов их обработчиков из суперлупа

У меня такое же впечатление о FreeRTOS.
Разработку очень сильно упростилась. На столько, что взял за правило делать автоматическую генерацию отчёта об ошибках.
Из минусов - расход операционной памяти больше в разы. Но я успокаиваю себя тем, что делать то же самое без ОС на процессоре послабее это в наше время резьба по калу.

Недавно до конца освоил спящие режимы процессора. Теперь в задаче бездействия процессор уходит в разные режимы сна в зависимости от необходимой на данный момент мин.частоты. Прерывание по таймеру RTC "заводится" на время, когда должна быть пробуждена ближайшая ждущая чего-то задача. После пробуждения системное время модифицируется, что бы задачи, в которых были таймеры, не заметили засыпания.