Jump to content

    

Потребления ресурсов пустой системой

Всем привет!

 

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

 

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

 

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

2. С другой стороны ставить ее всегда, наверное тоже не правильно, так как все же ресурсы она какие-то отъедает.

 

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

 

Если взять допустим 2 задачи:

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

 

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

 

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

Share this post


Link to post
Share on other sites

По быстродействию, можно считать, грамотно настроенная ОС ресурсов не потребляет (по сравнению с решением без ОС - там те же задачи будут все равно как-то решаться). А вот по объемам ОЗУ и флеша - потребляет. Поэтому, оценка применять / не применять строится обычно на том, сколько денег будет сэкономлено за счет установки малоресурсного чипа, возможно, и совершенно другой архитектуры, на ОС в принципе не рассчитанной, при решении без ОС. При больших объемах недорогих изделий это бывает очень актуально, принося неплохие деньги. При средних и малых объемах с большой нормой прибыли - обычно пренебрежимо. Если же Вы в прибыли не участвуете никоим образом, то и заморачиваться этим вопросом Вам не стоит в принципе. С ОС будет все быстрее и проще лично для Вас, а на доходе не отразится.

Share this post


Link to post
Share on other sites

Экономить на чипах это не для нас...

 

Беспокоит что на переключение контекста все же время тратиться. Опять же лишний объем кода он же не просто так, он же что-то делает. Сложность отладки опять же возрастает, контроль над поведением падает...

 

Или это все мифы, о которых не стоит думать?

Share this post


Link to post
Share on other sites
Или это все мифы, о которых не стоит думать?

Мифы. Отлаживать, пожалуй, даже удобнее. "Контроль над поведением" - что-то из лексикона беззаветных любителей ассемблера.

 

Если использование ОС не вызывает повышения требований к аппаратной части (но это не случай FreeRTOS), то почему бы и не использовать.

Share this post


Link to post
Share on other sites
Беспокоит что на переключение контекста все же время тратиться. Опять же лишний объем кода он же не просто так, он же что-то делает. Сложность отладки опять же возрастает, контроль над поведением падает...

Или это все мифы, о которых не стоит думать?

Наверное, это я тот человек, которые рассуждал об архитектуре cortex в соседней ветке...

Сейчас пишу прошивку для контроллера с функционалом подключения SD-карты через SPI.

Самый простой случай: делать линейный код т.е. команда за командой стремиться к результату.

Но в этом случае пока не будет процесс пройден до конца (а проходить он может долго,

т.к. карточка местами "тупит") весь остальной код не будет работать.

Работа с картой естественно организовано в mainloop.

 

Я же попытался и переписал работу с SD картой через асинхронные вызовы.

Т.е. ставлю задачу и указываю callback-функцию для сообщения результата.

Вся обработка в прерываниях от таймера и/или DMA, ожидание карты не тормозит код.

Но в этом случае конечные автоматы и callback-функции жутко раздувают код и отъедают производительность.

Настолько сильно, что задумываешься, а не легче ли было сделать ОС, выделить одну задачу

и вернуться к простому линейному коду в ней. Да, придется использовать элементы синхронизации.

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

Сейчас у меня нет гарантий, что mainloop будет выполняться, т.к. cpu может практически не выходить из прерываний (выходить и тут же попадать вновь).

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

 

Насчет мифов: в некоторых задачах (пример я привел) применение ОС может сократить код и повысить быстродействие,

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

объектов синхронизации. Все остальное мифы)

Был опыт использования FreeRTOS на старой работе, сейчас для себя и по работе RTOS не использую. Но постоянно об этом подумываю)...

Хотелось бы сделать минимальную ОС для своих целей... может и на asm)...

Share this post


Link to post
Share on other sites
Экономить на чипах это не для нас...

Беспокоит что на переключение контекста все же время тратиться. Опять же лишний объем кода он же не просто так, он же что-то делает. Сложность отладки опять же возрастает, контроль над поведением падает...

Ну, сразу, если экономить - не для вас, то и ставьте чип с запасом, чтобы вдвойне не париться :)

 

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

Share this post


Link to post
Share on other sites

Использую Keil CMSIS-RTOS RTX, но не могу сказать, что мне проще отлаживаться. По своему коду понимаю, что делается. А в RTOS - один Keil знает.

Я предложил бы такой критерий выбора - можешь сделать программу без RTOS - так и делай, не можешь - используй ОС.

Share this post


Link to post
Share on other sites

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

 

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

adnega - возможно вы, но и не только. Я читал статейки разные, ведь даже спец прерывание есть у кортексов. Почему сейчас не используете ОС, тем более если все время думаете?

ViKo - спасибо за отзыв. Меня тоже немного пугает что не пойми что внутри ОС, все же объем кода что за неделю не прочтешь не разберешься, по любому придется доверять в слепую...

 

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

 

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

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

При этом работоспособность сохраниться даже если запустить его на 8 МГц, просто будет все вяло и не красиво.

 

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

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

 

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

 

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

 

 

 

 

 

Share this post


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

 

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

 

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

 

Share this post


Link to post
Share on other sites

Спасибо за оценку.

 

Если 1 % и менее, то попробую, а там видно будет...

Share this post


Link to post
Share on other sites

Выскажусь тоже.

С тех пор, как я попробовал использовать RTOS (scmRTOS) в микроконтроллерах, я делаю все проекты только с RTOS.

Ось очень маленькая и быстрая. Накладных расходов - мало, удобств - много:)

Что нравится:

- Удобное распараллеливание задач;

- Лёгкость организации фоновых процессов;

- Удобно ждать события/прерывания;

- Очереди, события, флаги, мьютексы. Оч. удобные штуки;

- Значительно более понятный и сопровождаемый код.

 

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

 

Share this post


Link to post
Share on other sites
Если 1 % и менее

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

Share this post


Link to post
Share on other sites

АНТОХА спасибо за отзыв.

 

SM - я не буду экономить на чипе:) пока есть возможность я буду жить на широкую ногу, и прожигать жизнь транжиря флеши и такты процессора:))) Вы меня не затяните в эту секту!

 

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

Share this post


Link to post
Share on other sites

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

 

Вместо (вместе с) народного осциллографа за 3 коп. можно сотворить народную RTOS. scmOS не пробовал, видимо, она и быстрая и малая, но изначально писалась для AVR... наверное, если начать с нуля для Cortex, можно что-то упростить-улучшить.

Share this post


Link to post
Share on other sites
Поэтому потери в скорости будут крайне низки при грамотном использовании ОС. В отличие от потерь в объемах памяти всех видов, за счет которых и можно добиться экономии, убрав ОС и перейдя на более дешевое ядро, не предназначенное для ОС, зато более предназначенное под конкретную задачу.

Со всем сказанным выше соглашусь, а конкретно на этой фразе задержу внимание.

Есть ведь как минимум два способа повысить соотношение "цена/качество". Вы предлагаете понижать цену при необходимом функционале.

Я напротив, пытаюсь увеличить функционал при необходимой цене. Видимо, не только я. Правда, я ОС не использую и (по вашей терминологии)

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

если для увеличения соотношения "цена/качество" выбран путь увеличения функционала? Думается, что будет, т.к. за счет экономии

доход не сможет превысить цену изделия, а за счет расширения функционала увеличение дохода ничем не ограничено (при нынешних тенденциях

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

Вопрос востребованности продукта открыт при любом подходе.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this