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

[Golikov A.]

Всем привет!

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

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

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

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

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

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

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

[SM]

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

[Golikov A.]

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

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

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

[aaarrr]

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

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

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

[adnega]

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

Наверное, это я тот человек, которые рассуждал об архитектуре cortex в соседней ветке...
Сейчас пишу прошивку для контроллера с функционалом подключения SD-карты через SPI.
Самый простой случай: делать линейный код т.е. команда за командой стремиться к результату.
Но в этом случае пока не будет процесс пройден до конца (а проходить он может долго,
т.к. карточка местами "тупит") весь остальной код не будет работать.
Работа с картой естественно организовано в mainloop.

Я же попытался и переписал работу с SD картой через асинхронные вызовы.
Т.е. ставлю задачу и указываю callback-функцию для сообщения результата.
Вся обработка в прерываниях от таймера и/или DMA, ожидание карты не тормозит код.
Но в этом случае конечные автоматы и callback-функции жутко раздувают код и отъедают производительность.
Настолько сильно, что задумываешься, а не легче ли было сделать ОС, выделить одну задачу
и вернуться к простому линейному коду в ней. Да, придется использовать элементы синхронизации.
Но после монстрообразных конечных автоматов это уже не такой пугающий аспект.
Сейчас у меня нет гарантий, что mainloop будет выполняться, т.к. cpu может практически не выходить из прерываний (выходить и тут же попадать вновь).
С ОС я могу стремиться к тому, что задачи будут выполняться.

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

[SM]

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

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

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

[ViKo]

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

[Golikov A.]

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

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

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

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

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

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

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

[SM]

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

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

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

[Golikov A.]

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

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

[AHTOXA]

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

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

[SM]

Если 1 % и менее

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

[Golikov A.]

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

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

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

[ViKo]

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

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

[adnega]

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

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

[AlexandrY]

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

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

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

На две задачи ставить 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, а сервисов больше.

[Golikov A.]

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

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

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

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

[den_po]

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

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

Так же за счет кучи параллельных процессов по идее должна усложняться отладка.

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

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

[aaarrr]

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

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

[AlexandrY]

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

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

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

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

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

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

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

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

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

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

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

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

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

[Golikov A.]

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

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

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

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

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

[den_po]

Я сторонник тщательной архитектуры

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

[SM]

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

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

[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 секунд выигрыша времени накопиться в часы...

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

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

[SM]

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

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

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

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

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

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

[AlexandrY]

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

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

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

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

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

[A. Fig Lee]

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

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

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

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

[den_po]

1) чем больше кода, тем больше багов - я в CoOS выловил уже 3.

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

2) Вылавливать баги бывает очень нетривиально. На 1 баг, например, у меня ушло 2 недели: полдня кодировал ловушку, потом 2-3 дня ждал,
пока попадется. Баг сильно зависел от "направления и силы ветра в четверг".

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

[SM]

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

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

[den_po]

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

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

[SM]

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

Я, думаю, что не то слово, что велика, а что стремится к 100%. Если брать тот же линукс, то я лично уже в нем выковырял их с десяток минимум... А windows - так еще и не выковыряешь, из-за закрытости, только обходить.

[den_po]

Я, думаю, что не то слово, что велика, а что стремится к 100%. Если брать тот же линукс, то я лично уже в нем выковырял их с десяток минимум... А windows - так еще и не выковыряешь, из-за закрытости, только обходить.

Сравнили, конечно, кодовую базу линукса с коос...

[SM]

Сравнили, конечно, кодовую базу линукса с коос...

Так о том и речь, "чем больше, кода, тем..."

[den_po]

Так о том и речь, "чем больше, кода, тем..."

Я-то в своём вопросе акцент на другом делал. Ну да фиг с ним.

[A. Fig Lee]

Я, думаю, что не то слово, что велика, а что стремится к 100%. Если брать тот же линукс, то я лично уже в нем выковырял их с десяток минимум... А windows - так еще и не выковыряешь, из-за закрытости, только обходить.

В виндоус помнится выловил гдето в 2000 м году. Там у них обычно в тех местах, где меньше народу ходит, больше багов.
Не помню деталей, функция по извлечению ресурсов из dll. Там диалогов, стрингов и т.д. Чето она заедала у них, то ли 2й диалог не извлекала..
Факт тот, что чтоб сабмитнуть баг, майкрософту надо заплатить.
Потом он расследует, и если решит что это баг, то может даже вернуть деньги.

Я-то в своём вопросе акцент на другом делал. Ну да фиг с ним.

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


ПыСы. Если у вас "нет багов", это значит их просто пока не нашли или их количество четное и они взаимно компенсируются.

[den_po]

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


ПыСы. Если у вас "нет багов", это значит их просто пока не нашли или их количество четное и они взаимно компенсируются.

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

[SM]

этих вещей со страхом багов

Нет у программистов нашего уровня (в смысле низкого, на уровне работы с регистрами периферии и инструкциями процессора) никакого страха багов. Есть аксиома - если есть программа, то в ней есть хотя бы один баг. Если его найдут - его следует устранить, но аксиома все равно верна - там наверняка будет еще баг
А где он, в линуксе, в коосе, в другом хреносе, были бы исходники, а остальное дело небольшой лишней возни. Что за страхи то? О чем Вы вообще?

[Golikov A.]

Ну понеслась... линукс ставить данных из протокола в протокол пихать.

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

Правильно я понимаю что в РТОС задачи переключаются либо по тику системы (это что-то порядка 1-10 мСек) либо по тому как задача отпускает ресурсы. А задрать частоту повыше - это грузить проц переключениями контекста?

[den_po]

Нет у программистов нашего уровня (в смысле низкого, на уровне работы с регистрами периферии и инструкциями процессора) никакого страха багов. Есть аксиома - если есть программа, то в ней есть хотя бы один баг. Если его найдут - его следует устранить, но аксиома все равно верна - там наверняка будет еще баг
А где он, в линуксе, в коосе, в другом хреносе, были бы исходники, а остальное дело небольшой лишней возни. Что за страхи то? О чем Вы вообще?

http://electronix.ru/forum/index.php?showt...t&p=1327928

[SM]

все же линукс сильно избыточен, без приложений пользователей он явно не нужен,только ради стека?...

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

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

Правильно я понимаю что в РТОС задачи переключаются либо по тику системы (это что-то порядка 1-10 мСек) либо по тому как задача отпускает ресурсы. А задрать частоту повыше - это грузить проц переключениями контекста?

Если очень грубо, то правильно.

PS
А vi - отличная вещь. Через практически любой, самый тормозной терминал, типа ком-порта на 2400, позволяет редактировать любой текст! Попробуйте в виндовс так сделать встроенными средствами...

http://electronix.ru/forum/index.php?showt...t&p=1327928

Я не вижу ни одного страха. Обычная рабочая ситуация.

[den_po]

Я не вижу ни одного страха. Обычная рабочая ситуация.

Предпоследняя строчка. По-русски вроде написано.

[Golikov A.]

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

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

Опять же уровень абстракции, драйверы, среда запуска... не линукс перебор, сто пудово. а VI - говноредактор

Предпоследняя строчка. По-русски вроде написано.

сдается мне у вас личные счеты и вы хотите уесть китайского чертика...

[AlexandrY]

Правильно я понимаю что в РТОС задачи переключаются либо по тику системы (это что-то порядка 1-10 мСек) либо по тому как задача отпускает ресурсы. А задрать частоту повыше - это грузить проц переключениями контекста?

10 мс и не меньше. Если тик 2 мс или меньше на Cortex-M, то значит хотите нагрузить RTOS чем-то ей несвойственным.

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

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

[SM]

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

Это да, без файловой системы оно работать не будет, если не лезть в исходники. Как и без MMU, оно кастрированное. Но - ведь речь о простоте и быстроте реализации, наплевав на ресурсы памяти и стоимость проца! А вот тут линукс, скорее всего, окажется сильно впереди, в том числе, и из-за наличия (хотя бы) простой файловой системы, и из-за кучи готовых протоколов, драйверов, средств отладки, логирования, и вообще огромного объема готовых программ. И в части расширения на будущее - к примеру, почти любой Cortex-A содержит в себе сразу сильный видеоконтроллер, вдруг захочется поднять некое видео - и за день работы можно "поднять" любое разрешение, от мелкого QVGA до Full HD. Ну и т.п.

А под конфигурацией я имел в виду именно конфигурацию (.config)

[A. Fig Lee]

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

Правильно я понимаю что в РТОС задачи переключаются либо по тику системы (это что-то порядка 1-10 мСек) либо по тому как задача отпускает ресурсы. А задрать частоту повыше - это грузить проц переключениями контекста?

Если вам чтото кажется глупым, скорее всего не автор глупец, а вы чтото не понимаете.

I remember when first using vi, many years ago, a senior colleague advising me "Make sure you learn to use the h, j, k, and l keys because one day you'll end up on machine at a client site where the arrow keys don't work, and you'll look like a complete d***head if you can't even work vi."

2. Угу

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

Ну точнее было бы наверное сказать не "боюсь", а опасаюсь.
Кто ж знал что тут такие придиры будут. Вроде все понятно.
Баги, как дождь, или смерть, опасайся не опасайся но они есть.
Другой вопрос, что ты уже знаешь, "когда идет дождь" со своей операционкой.
А опасения связаны в первую очередь с тем что будет как всегда - тестировать никто не тестирует,
всем некогда. Погоняли немножко и в продакшн. А там условия разные и понеслась..
"Бессоные ночи в городе Сочи".. Надо срочно, еще вчера, бросай все.
Если чисто ковырятся, то ладно, ну баг и баг.

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

[Golikov A.]

А почему в один день он не мог попасть на машину клиента где оторвало одну из кнопок hjkl. Это не аргумент, это все отмазы. Если бы это была крутая фишка резервирования, то эти бы клавиши дублировали стрелки, а не были бы независимыми...

Но - ведь речь о простоте и быстроте реализации, наплевав на ресурсы памяти и стоимость проца!

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

[AlexandrY]

И в части расширения на будущее - к примеру, почти любой Cortex-A содержит в себе сразу сильный видеоконтроллер, вдруг захочется поднять некое видео - и за день работы можно "поднять" любое разрешение, от мелкого QVGA до Full HD. Ну и т.п.

Нынче делают не так.
Делают свою лабуду на Arduino. А если нужна наикрутейшая графика, то сверху ставят шилд, даже не думая что там внутри шилда.
А шилд этот может быть Intel Edison или Raspberry Pi или FTDI EVE, никого не интересует.
Так что расширения никуда не убегут. Главное RTOS!

[SM]

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

Э... Поясните, пожалуйста. Ничто и никогда не будет запущено, если Вы не указали в каких либо конфигах, что ЭТО следует запускать тогда то. Линукс сам по себе, после старта ядра, запускает /sbin/init, и всё. Никакой самодеятельности. А дальше - Вы можете сами себе написать этот init, и получите свое единственное приложение. А можете поконфигурировать далее, добавив того или этого.

Главное RTOS!

И зачем? Если все RT у товарища, судя по всему, в FPGA сделано.

[Golikov A.]

10 мс и не меньше. Если тик 2 мс или меньше на Cortex-M, то значит хотите нагрузить RTOS чем-то ей несвойственным.
Под планировщиком должны находится длительные задачи, где хотите одним дать производительности и реалтайма, а другими занимаете все оставшееся время.
Задачи успевающие за тик исполнится два и больше раз планировщиком трогаться не должны, они не в контексте RTOS должны работать. Ну по крайней мере так стараться.

То есть моя задача должна выглядеть так.

Прием езернет трафика Прерывание + ДМА и укладка в буфер
Отправка также по ДМА и прерываниям

Операционная система крутить ТСР стэк вяло разбирает пришедшие данные и формирует из них очередь команд.

Как только появляются данные для FPGA просыпается процесс отправки их в FPGA, который их перепихивает в SPI и засыпает, возвращая опять ресурсы задаче что крутит стэк.

По прерыванию от FPGA просыпается другая быстрая задача которая собирает данные и кладет их в буфер на отправку.

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

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

Как вообще правильно такое делается в ОС?

[SM]

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

[den_po]

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

Именно что причём

[Golikov A.]

Э... Поясните, пожалуйста. Ничто и никогда не будет запущено, если Вы не указали в каких либо конфигах, что ЭТО следует запускать тогда то. Линукс сам по себе, после старта ядра, запускает /sbin/init, и всё. Никакой самодеятельности. А дальше - Вы можете сами себе написать этот init, и получите свое единственное приложение. А можете поконфигурировать далее, добавив того или этого.

1. Ну и так много что само запущено изначально, самое голое ядро линукса все же несет в себе кучу всего. Если мы говорим не о переписи линукса.
2. Потом если есть линукс то всегда найдется придурок который обновит какой-нибудь драйвер или запустит какую-то службу, чтобы сделать устройство лучше, и даже вам не скажет. А вы потом будете смотреть на устройство которое вдруг стало себя вести как-то не так...
3. У меня кончились отмазки почему линукс 100% зло Но линукс это не то что я бы сейчас хотел ставить на проц, тем более у меня все же кортексы м3, мне он просто не интересен.

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

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

[SM]

1. Ну и так много что само запущено изначально, самое голое ядро линукса все же несет в себе кучу всего. Если мы говорим не о переписи линукса.

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

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

КАК? Если Вы в свой дистрибутив включили, допустим, только ядро, свое приложение, и, допустим, ssh-демон для того, чтобы посмотреть логи. И ничего более? Крайне странное у Вас представление о линуксе во встраиваемом устройстве.

Критические секции и семафоры?

Критическая секция или mutex для долгих кусков кода, spinlock для коротких.

[Golikov A.]

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

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

КАК? Если Вы в свой дистрибутив включили, допустим, только ядро, свое приложение, и, допустим, ssh-демон для того, чтобы посмотреть логи. И ничего более? Крайне странное у Вас представление о линуксе во встраиваемом устройстве.

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


Если время от времени внешнее устройство присылает N байт по UART, например, и надо на это среагировать как можно быстрее. В начале пакета стоит заголовок с длинной данных. Как такое делают в РТОСах?
Настраивается ДМА на прерывание по длине заголовка, потом по прерыванию определяется сколько еще допринять, опять настраивается ДМА. А потом по прерыванию выставляется какой-то семафор на запуск задачи - обработки принятого сообщения?

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

[SM]

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

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

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


Что касается уарта, то это же медленный интерфейс, как правило все можно решить в прерывании от наличия в его FIFO данных, или в DPC (workitem, и т.п.), запущенной из этого прерывания.

[A. Fig Lee]

А почему в один день он не мог попасть на машину клиента где оторвало одну из кнопок hjkl. Это не аргумент, это все отмазы. Если бы это была крутая фишка резервирования, то эти бы клавиши дублировали стрелки, а не были бы независимыми...

Компы то разные. На ИБМ вон карактеры были 36 бит, например.
Терминалы разные, ну и так далее.

Именно что причём

Понятно. В игнор.

[Golikov A.]

А скажите, если все же не линукс, то что надо чтобы операционку на проц запихать?

FreeRTOS она вроде как пишут под кортексы заточена (в том числе)
а Freescale MQX все же под колдфаеры, и просто АРМ.

Как я понимаю основное что там от проца зависит это таймер и переключение контекста. То есть надо это либо писать ручками под свой проц, либо искать портированную систему под конкретный проц. И как я понимаю в силу того что FreeRTOS в том числе по кортексы М3 заточена, есть шансы что она заработает из коробки, правильно? А большой ли это шанс?

[SM]

Как я понимаю основное что там от проца зависит это таймер и переключение контекста. То есть надо это либо писать ручками под свой проц, либо искать портированную систему под конкретный проц. И как я понимаю в силу того что FreeRTOS в том числе по кортексы М3 заточена, есть шансы что она заработает из коробки, правильно? А большой ли это шанс?

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

Кроме озвученного, от проца зависят еще все драйверы всего его железа... Ну там SPI, UART, USB, и т.д., а также атомарные операции.

[AlexandrY]

А скажите, если все же не линукс, то что надо чтобы операционку на проц запихать?

FreeRTOS она вроде как пишут под кортексы заточена (в том числе)
а Freescale MQX все же под колдфаеры, и просто АРМ.

Как я понимаю основное что там от проца зависит это таймер и переключение контекста. То есть надо это либо писать ручками под свой проц, либо искать портированную систему под конкретный проц. И как я понимаю в силу того что FreeRTOS в том числе по кортексы М3 заточена, есть шансы что она заработает из коробки, правильно? А большой ли это шанс?

А что такое "из коробки"?
Интересно в каком месте эта FreeRTOS по кортексы заточена.

[Golikov A.]

да кто ее знает в каком.
Из коробки имеется ввиду взял файлики, воткнул и поехали...
У FreeRTOS есть релизы под кортекс м3, это позволяет надеяться что ассемблерный код переключения задач будет уже готов, а так же будет использован системный таймер и так далее что ей нужно для жизни... То есть я надеюсь что это позволит брать файлы, включать в проект кортекса м3 (любого) и запускаться.

Или это очень наивно? И для порта на конкретный проц надо будет много чего полопатить?

С вашим опытом чтобы запустить MQX на произвольном проце, что надо сделать?

[AlexandrY]

да кто ее знает в каком.
Из коробки имеется ввиду взял файлики, воткнул и поехали...
У FreeRTOS есть релизы под кортекс м3, это позволяет надеяться что ассемблерный код переключения задач будет уже готов, а так же будет использован системный таймер и так далее что ей нужно для жизни... То есть я надеюсь что это позволит брать файлы, включать в проект кортекса м3 (любого) и запускаться.

Или это очень наивно? И для порта на конкретный проц надо будет много чего полопатить?

С вашим опытом чтобы запустить MQX на произвольном проце, что надо сделать?

О, сегодня за час удалось портировать FreeRTOS на свою платформу на Kinetis K70.
Немного удивился сколько же задач создает сразу эта FreeRTOS - сразу 37. Правда с uIP стеком.


Ну и убожество эта FreeRTOS.
Хотя поддержка FreeRTOS есть в IAR, но выглядит очень бедно. Вот что на скриншоте это практически и все. Ну еще листинг очередей есть.
Стек эта RTOS ест не то слово.

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

Кстати лицензия у FreeRTOS довольно суровая. Суровей чем у MQX в плане обязательного раскрытия и обязательного упоминания.

Характерно, что под Kinetis есть порт FreeRTOS только для одной единственной платформы.
Т.е. тот кто использует Freescale не нуждаются во FreeRTOS поскольку имеют лучшую альтернативу.

[den_po]

Немного удивился сколько же задач создает сразу эта FreeRTOS - сразу 37. Правда с uIP стеком.

Значит, это freertos эти задачи создаёт, а не пользователь?

Ну и убожество эта FreeRTOS.
Хотя поддержка FreeRTOS есть в IAR, но выглядит очень бедно.

А поддержка линукса например в иаре есть?

Стек эта RTOS ест не то слово.

А это где посмотреть и с чем сравнить?

Периферийные дела пишутся в таких портах какими-то студентами на скверном уровне. Сплошная лапша и баги.

Что значит "в таких портах"? И где посмотреть на примеры сплошных багов в официальном репозитории?

По сути эта ось идет без периферийного уровня , даже без HAL.

Попробуйте chibios, там, говорят, с hal всё хорошо. Только вот кроме операционки придётся портировать и драйверы.

[AlexandrY]

Значит, это freertos эти задачи создаёт, а не пользователь?

Метко замечено.
Действительно, эт я на такую демку нарвался.
На самом деле создаются автоматом только две задачи: таймера и IDLE.
uIP стеку не надо было столько задач.

Но скажем в MQX все задачи создаются юзером только явно.

А официальный репозиторй знаете ли содержит все кроме точной версии IDE в которой проект создавался и точной схемы и спецификации платы на которой запускался.
Так что баги там 100%. У меня ни инициализация MAC не пошла ни инициализация портов.


Если б в IAR была бы поддержка линукса, я бы только о линуксе и писал бы.

[alexunder]

Но скажем в MQX все задачи создаются юзером только явно.

Вы хвалите процессоры от Freescale и MQX. А с какими конкретно процессорами Вы используете эту ОС? Спасибо

[Golikov A.]

И все же, подскажите пожалуйста.

1. Вот я хочу на LPC1768 запустить MQX
2. Вот я хочу на LPC1768 запустить FreeRTOS

какие действия (схемотично) меня ждут в первом и втором случае?

[alexunder]

1. Вот я хочу на LPC1768 запустить MQX

разве MQX портирована под этот мк?

[ViKo]

1. Вот я хочу на LPC1768 запустить MQX
2. Вот я хочу на LPC1768 запустить FreeRTOS

Если в Keil работаете, то лучше
3. Захотите и запустите на LPC1768 CMSIS RTOS RTX - она маленькая, простая, красивая, если хотите, и уже в комплекте. Документация тоже уже на вашем компе.

[Golikov A.]

разве MQX портирована под этот мк?

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

Если в Keil работаете, то лучше

Лучше, но очень хочется остаться в провавом поле с LwIP и какими то фри ос. Мне очень нравятся продукты кейла вида ТСР стека, но все же за него надо платить....

А АРМ кейловую ОС выбрал как флагмана, да?

[ViKo]

Лучше, но очень хочется остаться в провавом поле с LwIP и какими то фри ос. Мне очень нравятся продукты кейла вида ТСР стека, но все же за него надо платить....

А АРМ кейловую ОС выбрал как флагмана, да?

В нагрузку. :-)
Есть бесплатная ограниченная Keil IDE. Есть совсем бесплатная для STM32F0.
Пусть докажут, что пользовался не ими.

[Golikov A.]

А вы уверены что их библиотеке нельзя послать сообщение на которое она ответит свою версию и платность? Исходники то закрыты, сделать такое пять минут работы....
Да и бесплатно ограниченные сильно ограничены, в них вроде РТЛ вообще никакой не входит...

[AlexandrY]

И все же, подскажите пожалуйста.

1. Вот я хочу на LPC1768 запустить MQX
2. Вот я хочу на LPC1768 запустить FreeRTOS

какие действия (схемотично) меня ждут в первом и втором случае?

Поскольку NXP и Freescale слились (в смысле объединились), то наверно нет ничего криминального портировать MQX на LPC.


Во первых сразу надо определится какую IDE с компилятором вы будете использовать. Ибо дальше образ действий расходится.
Скажем берем IAR.

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

Портировать вы будете с демок. Шаг влево, шаг вправо от референсных по отношению к демкам платформ и ваши демки не запустятся.
В этом смысле хоть во FreeRRTOS вы и найдете демку как раз под LPC1768 для IAR, она у вас на вашей самодельной плате не запустится.

И вот тут вы в равных условиях что с FreeRTOS, что с MQX.

Во FreeRTOS начинаете долго рыть исходники в попытках очистить их от флуда и найти где чё инициализируется. Кстати в демке FreeRTOS нет даже инициализации UART-а, о CAN-е и не мечтайте.

В MQX таже работа, но не надо чистить демку от какого-то там вебсервера поскольку есть примитивные демки хеловорды на консоль.
Знакомых драйверов периферии LPC в MQX не найдете. Но никто не мешает в конфиге поотключать вообще всю инициализацию периферии (user_config.h ), что и должны будете сделать.
Далее в __low_level_init вставляете инициализацию тактирования, портов и UART-а с которым будете работать на консоль.
Далее еще правите файл линкера .icf под ваш чип.
ВСЕ! Портирование MQX как ядра на этом закончено.

[Golikov A.]

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

Неужели чтобы поставить ядро FreeRTOS я не могу его взять голое для кортекса М3 и поставить на свой проц, просто включив в проект... Должна же быть где то голая система, потому что иначе откуда взялась первая демка которую разодрали на все остальные демки?

Кортексов М и АРМ7 например по разному сделаны прерывания, и это может отличать операционку для АРМ просто от операционки для кортекса.

Операционка от кейла входит в лайт комплект, и вроде как там надо просто ее пожелать, и она добавиться в пустой проект, и не надо демку дербанить. Неужели FreeRTOS ставиться не также?

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

[aaarrr]

Неужели чтобы поставить ядро FreeRTOS я не могу его взять голое для кортекса М3 и поставить на свой проц, просто включив в проект... Должна же быть где то голая система, потому что иначе откуда взялась первая демка которую разодрали на все остальные демки?

Можете, конечно. Все необходимое есть в \Source, \Demo можно и не смотреть.

[AlexandrY]

что я не знаю и не понимаю от этого, что заставляет терпеть такие сложности с добавлением операционки в проект?

A вот этого я не знаю.


Я описал стандартный экспресс метод. Позволяющий запустить RTOS за пару дней.

Вам разве легче будет хелп в онлайне на FreeRTOS читать и по нему восстанавливать что и как?
Так авторы FreeRTOS не запариваются объяснениями как они поступают с компиляторами, линкерами и т.д.

Это в MQX есть три здоровых документа в pdf : юзер мануал, референс мануал и еще мануал отдельно по HAL уровню, не говоря уже что по TCP, USB, FS и проч. у них отдельные мануалы.
И то я не рискнул просто по ним взять и запустить с нуля.
Только через ихний фирменный BSP Cloning Wizard и демки.

Кортексов М и АРМ7 например по разному сделаны прерывания, и это может отличать операционку для АРМ просто от операционки для кортекса.

Да кстати, может вы не в курсе, но и в FreeRTOS и в MQX есть выбор ядра от ARM7 до Cortex-Ax

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

[Golikov A.]

ну так я надеялся что FreeRTOS собрана под разные ядра... как обещающая и особо заточенная... но видать нет...

[A. Fig Lee]

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

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

Вам может и так сойдет, у нас работает на 1 миллисекунд тик, хорошо загружена.

[den_po]

ну так я надеялся что FreeRTOS собрана под разные ядра... как обещающая и особо заточенная... но видать нет...

Ну дык ответили ж вам - всё необходимое есть в папке source.
От вас требуется настроить FreeRTOSConfig.h и вызвать vTaskStartScheduler(). Ну и стартап в некоторых случаях в демке подглядеть.
Если не нравится, на каких таймерах висит переключалка задач, тут уже надо будет лезть в папочку port.

[Golikov A.]

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

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

Ну дык ответили ж вам - всё необходимое есть в папке source.
От вас требуется настроить FreeRTOSConfig.h и вызвать vTaskStartScheduler(). Ну и стартап в некоторых случаях в демке подглядеть.
Если не нравится, на каких таймерах висит переключалка задач, тут уже надо будет лезть в папочку port.

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

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

[den_po]

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

http://electronix.ru/forum/index.php?s=&am...t&p=1328460

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

См. мой предыдущий ответ.

[Golikov A.]

блин я пропустил этот ответ.

То есть я беру из сорс голую систему, пихаю в проект, правлю конфиг, настраиваю свою периферию, запускаю vTaskStartScheduler() и поехали?
Дальше останется только добавлять таски?

Сколько занимает такой старт на голом проце? Ведь в целом так же можно описать и запуск линукса

[aaarrr]

То есть я беру из сорс голую систему, пихаю в проект, правлю конфиг, настраиваю свою периферию, запускаю vTaskStartScheduler() и поехали?
Дальше останется только добавлять таски?

Именно.

Сколько занимает такой старт на голом проце? Ведь в целом так же можно описать и запуск линукса

На Cortex-M пару часов в знакомой среде. Некоторой внимательности требует только настройка контроллера прерываний.

[LightElf]

ну так я надеялся что FreeRTOS собрана под разные ядра... как обещающая и особо заточенная... но видать нет...

Что значит "собрана под разные ядра"? FreeRTOS поставляется в исходниках. Заметная часть функционала выполнена на макросах, поэтому ее нельзя собрать в библиотеку.
Каталог FreeRTOS\Source содержит исходники кернела. По-минимуму это файлы list.c queue.c tasks.c. Есть еще croutine.c и timers.c - на любителя. Каталог FreeRTOS\Source\portable содержит кусочки, специфичные для конкретного компилятора и ядра. Например FreeRTOS\Source\portable\IAR\ARM_CM3 содержит специфичный код для Cortex-M3 с компилятором IAR. Каталог FreeRTOS\Source\portable\MemMang содержит 4 варианта менеджера памяти. Нужно выбрать один, в доке описаны отличия. Для первого запуска достаточно heap_1.c. Дальше берете FreeRTOSConfig.h из примерно похожей демки, правите под свои потребности - и вуаля.

[Golikov A.]

Ну что же, всем спасибо за беседу, попробуем запустить FreeRTOS, а там видно будет.

Под собрана, я имел ввиду собраны исходники, ну собственно как и есть, это типа "FreeRTOS\Source\portable\IAR\ARM_CM3"....

[adnega]

Ну что же, всем спасибо за беседу, попробуем запустить FreeRTOS, а там видно будет.

Мне в свое время очень помогли статьи А. Курница о FreeRTOS. Советую.

[den_po]

То есть я беру из сорс голую систему, пихаю в проект, правлю конфиг, настраиваю свою периферию, запускаю vTaskStartScheduler() и поехали?
Дальше останется только добавлять таски?

vTaskStartScheduler() возвращает управление только при ошибках либо если какая-то задача принудительно останавливает планировщик, поэтому хотя бы одну свою задачу стоит создавать ДО её вызова

[MiklPolikov]

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

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

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

[alexunder]

Мне в свое время очень помогли статьи А. Курница о FreeRTOS. Советую.

Спасибо! Думаю надо с чего-то начинать, пусть будет FreeRTOS. На 51

[Сергей Борщ]

пусть будет FreeRTOS. На 51

Может стоит начать с замены 51 на что-то более современное и подходящее для ОС?

[SM]

Может стоит начать с замены 51 на что-то более современное и подходящее для ОС?

Вообще, переключение контекста на 51 чуть ли не самое быстрое из возможных, пока в пределах 4 банков

[AlexandrY]

Вообще, переключение контекста на 51 чуть ли не самое быстрое из возможных, пока в пределах 4 банков

Ага, как же
Во FreeRTOS из 51-х есть только Cygnal и сохранение контекста там выглядит так:

Код

/*
* Macro to push the current execution context onto the stack, before the stack
* is moved to XRAM.
*/
#define portSAVE_CONTEXT()                                                                        \
{                                                                                                \
    _asm                                                                                        \
        /* Push ACC first, as when restoring the context it must be restored                    \
        last (it is used to set the IE register). */                                            \
        push    ACC                                                                                \
        /* Store the IE register then disable interrupts. */                                    \
        push    IE                                                                                \
        clr        _EA                                                                                \
        push    DPL                                                                                \
        push    DPH                                                                                \
        push    b                                                                                \
        push    ar2                                                                                \
        push    ar3                                                                                \
        push    ar4                                                                                \
        push    ar5                                                                                \
        push    ar6                                                                                \
        push    ar7                                                                                \
        push    ar0                                                                                \
        push    ar1                                                                                \
        push    PSW                                                                                \
    _endasm;                                                                                    \
        PSW = 0;                                                                                \
    _asm                                                                                        \
        push    _bp                                                                                \
    _endasm;                                                                                    \
}

Создатели RTOS-в вообще не выносят всяких аппаратных особенностей.
В этом плане говорить что FreeRTOS под что-то заточена немного смешно.

[alexunder]

Может стоит начать с замены 51 на что-то более современное и подходящее для ОС?

Господа, спасибо за комментарии.
Ясно что 51 не самый лучший кандидат для ОС, мягко говоря. Но у меня оригинальная демоборда от Silabs F321 лежит без дела. Пусть там 25МГц вместо 100МГц, но попробовать стоит.

[SM]

Создатели RTOS-в вообще не выносят всяких аппаратных особенностей.

Именно поэтому, грамотное портирование - дело тонкое, долгое и муторное. Для того же 51, например, очень выгодно использовать 4 аппаратных контекста, и только, когда их не хватает, лить все валом в стек. Если авторам РТОС это не понятно - значит нафиг такую РТОС для такого ядра вместе с ее авторамию...

В этом плане говорить что FreeRTOS под что-то заточена немного смешно.

И я и не говорю про заточенность.