Всем привет!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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



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



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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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



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


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

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

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

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

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

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

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

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

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



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

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


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

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

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

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


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

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

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

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

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

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

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



2. Угу




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

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

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




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

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

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


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

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

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

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

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

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

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

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

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

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