Мой коллега утверждает, что ОС - это совершенно ненужная вещь впринципе (будь то FreeRTOS или Embedded Linux).
Говорит что старый добрый суперлуп и прерывания - вот это вещь!

Недавно услышал ещё одно утверждение, уже от другого человека: ОС в мире микроконтроллеров (в том числе и с MMU как SAM9) - это зло!

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

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

Практики - они разные бывают. В каких-то задачах ОС нужна, в каких-то нет...

а в чём вопрос/проблема/задача?

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


как раз наоборот. C ucLinux не приходилось встречаться?

Каких-то лет 10 назад я недоумевал, как можно что-то путное написать на си для контроллера.
А теперь уже и плюсы - вполне обыденность.

Каждому овощу - свое время (и место).

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

Верить нельзя никому. Надо пробовать, тогда появится понимание.
Или аргументированно ссылаться хотя бы на документацию, а не на "авторитетное мнение"

Оси-это зло.
Но тот, кто их юзает, - тому повезло.

Аж стихами )). ОС -- это методология.

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

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

Меня в этом вопросе "смущает" одно
Какая "обобщённая" разница, если она есть, между понятиями Операционная среда и Операционная система.
т.к., по моему, Операционная среда - это от 90% функционала Операционной системы

P.S. А зло или добро это понятия относительные.

Извините за

Мне нравится ложить варенье одновременно в чай, и на печенье) А Вам?
А вот мой знакомый это терпеть не может: зачем ложить варенье и на печенье и в чай, когда можно только сюди или сюда. А мне по бубену. Мне нравится, и все! Я еще и пельмени недоваренные люблю. А еще омуль с душком (чуть проквашенный) ))).

Мораль такая. Пробуйте с осью, пробуйте без оси) Делайте вывод. Работать Вам.

Если бы ОСи было плохо, их бы никто не использовал. Если бы ОСи было хорошо, то все бы только их и использовали.

Надо обзавестись критериями, выражающими соотношение время разработки/ресурсы камня. И смело посылать подальше мнения, которые советуют что-либо вопреки этим критериям.
А подходов действительно масса. Вон, даже stdlibc сколько вариаций?

Среда(Enviroment) -- она подразумевает наличие служебных и прикладных программ и настроек хотя бы в виде переменных ибо среда -- то что можно изменять и настраивать и то в чём что-то содержится.
Поэтому среда -- как минимум необходимы переменные среды и интерпретатор.

А система-- предпологает наличие единиц исполнения -- по этому тута просто хватит чего-то такого что предоставляет многозадачность она же многопоточность.

Я бы вас или ваших коллег поправил:
Ваш коллега утверждает, что ему ОС - это совершенно ненужная вещь впринципе (будь то FreeRTOS или Embedded Linux).
от другого человека: для него ОС в мире микроконтроллеров (в том числе и с MMU как SAM9) - это зло!
Кто бы спорил? На вкус и цвет товарищей нет. Но, если было бы ОС злом - пользовал ли его тогда кто-нибудь? Например наса пользует µC/OS, пусть Ваши коллеги им скажут, что это совершенно ненужная вещь и это зло, а то они наверно даже не догадываться.

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

Ваши коллеги/знакомые либо не сумели "приготовить" ос, либо они старые консерваторы тяжелые на перемены. Действительно, есть люди, которые за 30-40 лет стажу так освоили суперлуп, что разбираться с осью им дольше, чем написать готовую программу со своим планировщиком. Но задачи разные бывают. Например задача: мк + экран + тачскрин + tcp/ethernet + usb + ftdi = девайс. Был поставлен Embedded Linux, Х11, Qt4. Писать в суперлупе на прерываниях свой GUI, свой оконный менеджер, обработку мышки (тачскрин), програмный tcp стек, обслуживание usb, ftdi..... Ну наверно теоретически эта задача подъемная. А практически?

+1

ps меня воротит от тыквы. Если в каком блюде есть хоть чуть-чуть тыквы - меня аш выворачивает. Но это не значит что тыква плохой продукт.

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

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

Не ребята, это мы разленились.
А есть серьезные проекты которые по прежнему развиваются без осей.
Например в решениях от Microchip нигде не применяют ось. А там функциональность покруче чем "мк + экран + тачскрин + tcp/ethernet + usb + ftdi"
Или вот, может кто видел, навороченные часы от Google из проекта ADK 2012, которые через BlueTooth и USB общаются с Android платформами, тоже без оси.
Или решения на базе .NET micro framework...

Вообщем вопрос не во вкусе и не в тупости разработчиков, а в чем то другом.
Короче тема похоже не раскрыта...

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

А чего в абсолютных попугаях? Мода такая? 10 мкс на 210MIPS... 2100 тактов, почти команд ... слона можно схавать

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


А ведь сейчас есть и двухядерные МК. Применить на одном ядре ОСь, а на другом ничего не применять. Это зло?

Да нет, не мода, исключительно собственный опыт. А насчет "слонов" скажу, что в ядре "Линукса", к примеру, уже более 12 млн. строк исходного кода.
Кроме того, применяя ось, следует иметь в виду вероятность сбоя в ячейках динамического ОЗУ при работе в режиме 24 часа в сутки и 365 дней в году, если ось будет исполняться оттуда. Я приводил ссылку об исследовании этого вопроса сотрудниками "Гугла" на их серверах когда-то раньше.

Мне более нравятся относительные показатели, в тактах.

Целостность и регенерация объектов - большая тема. Но на ошибки ECC реагировать не сложно, это не уязвимости, - тут мороки-то и нету.

Ну дак кто мешает применять более строгие ОСи чем Линукс и потом в динамическом ОЗУ храните какие-нибудь картинки а вот критический важный код который на 10 мксек храните внутри чипа

А данные (не константы) где хранить?

Внутри МК в SRAM.

используют прерывания и DMA

Согласен, только если требуется как-то обработать входные данные перед выдачей выходных сигналов, то в работу вступает программный планировщик задач операционной системы. А уж как он распределит очередность исполнения обработчика прерывания известно лишь разработчикам ОС. Тут все зависит от временного допуска обработки входных данных.
Если же рассуждать шире, то удел операционных систем - это всего лишь удобное средство отображения данных. На мой взгляд, поручать осям задачи управления в режиме 24/7/365 недопустимо из-за неизбежных сбоев в работе динамического ОЗУ. А для примера можно просто сравнить надежность работы сетей связи в телефонных сетях с АТС где, насколько мне известно, в передаче голосовых данных оси не применяются и IP-сети, где оси применяются изначально. Качество связи в расчет не берем, учитываем только разрывы связи. Увы, оси здесь проигрывают изначально, как и везде.

Смишно. Бред какой-то.

какая взаимосвяь между ос и динамическим озу? что под динамическим озу вы понимаете? если под динамическим озу вы понимаете динамическое выделение памяти, но так используйте ос без димамического выделения памяти. Если вы понимаете DRAM, и вы недоверяете апаратному динамическому ОЗУ, то используйье статическое ОЗУ. При чем тут ос? если озу имеет неизбежные сбои, то прога и без ос ляжет.

и насчет "24/7/365"..... прекрасно работают серьёзные проекты на осях. и на ртос, и на нертос, и без ос. годами и без перезапусков и выключений.

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

Вероятность сбоя SRAM тоже ненулевая Насколько я помню вышмат, нет единичных и нулевых вероятностей. Но где же посмотреть количественные соотношения надежности внутренней SRAM и внешней DRAM?


Это Вы о декадно-шаговых АТС?

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


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

Нет, не приведу. Я не утверждаю, что с ос устройство будет работать надежнее. Я утверждаю, использование ос - это не значит что надежность будет хуже.

Хотя опять же.... взять программу состоящую из 20-ти простых задач (опрос клавиатуры, вывод на экран, уарт, мигать диодом, контроль аккум. и т.п.). каждая задача сама по себе несложная. Школьник напишет. Но распределить между всеми процессор - это писать что-то типа своего планировщика, на прерываниях и флажках. Прожженый 15-ти летнем стажем прогер раскидает такую программу, используя уже написанные куски кода в своих ранних проектах и обойдет все грабли по которым он ходил по молодости. Но какойнить не опытный прогер, или прогер пересел на новую платформу, написав такой код - во первых у него уйдет много времени на написание и отладку своего планировщика, во вторых его планировщик не будет более надёжен, а скорее менее надёжен. И если взять надёжную ос и написать 20 элементарных задачь по опросу клавиатуры и т.п. - такой код будет написан быстрее и с осью будет гораздо надёжнее, ибо планировщик в осе и сама ос - это тот же самописный планировщик, только он вылизан и протестин многими людьми и в него вложен труд сотен, а то и тысяч людей.

ps есть конечно оси кривые, с дырами. например scmRTOS. Конечно такая ось принесёт только проблемы и не только в режиме 24/7/365. Но есть вылизанные оси. Почему бы их не использовать, если она разработчику приносит ++?

pps я вообще не вижу разницы между программой на "час" и "24/7/365". я пишу все программы так, чтобы они работали "24/7/365".
А что, кто то пишет по другому? у кого-то есть такое ТЗ: "Нужно написать программу, которая должна проработать минимум час." По такому ТЗ кто-то, например для ускорения написания кода, пишет с утечкой памяти, главное чтобы за час вся память не вытекла?

Все пишут уже давно по другому

Зачем скажем писать беспроводной коммуникационный стек протоколов супер надежно если он все равно ляжет по причине ненадежности физического уровня?
Или зачем писать супернадежный софт для персонального компьютера где сбои де-факто уже норма.
Или зачем писать надежный софт для нано-спутника который через пару суток все равно сгорит в атмосфере?
Писать надежно под RTOS очень тяжело.
И даже не из-за утечек памяти. Утечки как раз легко отслеживаются (хотя борьба с фрагментацией очень сложна).
А из-за неправильного выбора способов межзадачного взаимодействия и синхронизации.
Не те размеры стеков и буфферов, не те размеры очередей, не учтенная интенсивность сообщений, неправильное распределение приоритетов и т.д. рисков куча.
Все модели планировщиков в RTOS основываются на том, что разработчик точно знает время выполнения своих задач.
В жизни это невозможно.
Т.е. по сути оптимизировать планировщик можно только для очень примитивных частных приложений.
В реальных приложениях планировщик скорее всего будет давать сбои. Это будет приводить к потере данных, к потере сообщений, рассинхронизации действий и т.д.
Т.е. не то что бы приведет к отказу, но приведет к потере качества функционирования, глючности.
Так вот, если уровень глючности достаточно невысок, то продукт вполне можно сдавать в эксплуатацию и это повсеместная практика.
Поинтересуйтесь как в NASA смотрят на проблему глючности.

Извините, но что Вам не нравится в scmRTOS? Какие дыры Вы в ней нашли, и когда?
Пара девайсов работают под этой осью. Один почти полтора года, другой - полгода.


Да я не задавал конкретного вопроса

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

УЖ0С!!!

Я не понимаю отличие "писать супернадежный софт" и "писать софт". В чём разница? я не пишу супернадежный софт, я пишу софт. Хочешь пользуй 1 час, хочешь круглые сутки, хоть на микроконтроллере, хоть для ПК.

УЖОС!!! Гнать таких разработчиков. Ни на одном предприятии, на которых я работал, ни на одном предприятии, на которых работают мои знакомые такой практики нет. Бывает выпуск глючной продукции, но эти глюки выявляются после выпуска продукции. Т.е. в момент выпуска продукции разраб считает что ошибок нет, он допускает что там могут быть ошибки, но все известные ошибки устранены. А выпуск глючной продукции - это как правило результат плохово тестирования.

Ну за всех говорить не нужно. наверно Вам Писать надежно под RTOS очень тяжело.


Ну мне вот сложнее сделать межзадачное взаимодействие в суперпуле, а в ртос легче.
Можно и в С/С++ себе в ногу стрельнуть - неправельное обращение к памяти, обрашение по неправильному указателю.... и прога легла. Это не значит что с/с++ ненадёжные языки инужно писать на асме.

а чото заставка крутилсь недавно на micrium - нас выбрала НАСА для Марса.
ps Есть док. фильм про то, как наса внедрила бортовой комп на апалоне. Там был супер надёжный комп и по было супероттестированние.

pps

Да в полне возможно. Порты разные, задачи разные. В одном "соусе" она годами работает, в другом киснет на глазах.
Не работал с ней. Работал коллега. На АРМе каком-то поднял. примерно год назад релиз, по мойму ещё 3.ххх была. Там проблемы была.... вроде при просыпании процессора. Точно не скажу. Так что-то там улетало и девайс ложился. Коллега продебажил и нашол багу в самой оси. На этом форуме выяснил что бага эта есть и что она не фиксица... ну по крайней мере на тот момент не было патча для ос с заплаткой. Он мне сказал "Запишы в записную книжку: scmRTOS ни когда не пользовать". Он много негатива про неё мне наговорил. Потом портировал проект в TNKernel - проблем не стало. С тех пор только на ней и пишет.

Если честно, но объяснение глючности scmRTOS прозвучало как "где-то бабка сказала".
Переловатил всю ветку по scmRTOS и не нашел подобной темы.

В некоторых камнях действительно есть "особенности" выхода из сна. Например в SoC CCxxxx некоторые регистры и области памяти обнуляются. Но это не имеет какого либо отношения к самой ОС.

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

1. Серьёзно, лучше Вас такое еще никто не высказал.
2. *уле там мудрить: создается глобальная структура данных и все обращения типо offsetof() даже с динам.типами, но это уже к плюсам. Плюсы плюсов, тсз

"Гугл".

Прям логический парадокс: "здесь глюков нет, но они тут могут быть"
Речь то об одном и том же софте. Софт то не деградирует со временем, как железо.
Так от куда там могут быть глюки если сейчас там их нет?
Или это позиция "страуса"?

"Архитектура программного обеспечения
Программное обеспечение станции 5ESS-2000 имеет модульную архитектуру, что обеспечивает высокую надежность станции, простоту введения новых услуг, поддержки и обслуживания. Для управления используются две операционные системы. ОС UNIX-RTR реализует административные функции процессора AM. ОС распределенной коммутации OSDS распределена по коммутационным модулям и обеспечивает следующие интерфейсы:
- с ОС UNIX-RTR для обеспечения услуг ввода/вывода и связи между процессами для других программных подсистем в AM;
- с программным обеспечением технического обслуживания для поддержки процессов обслуживания станции в CM и в коммутационных модулях;
- интерфейс передачи сообщений в коммутационных модулях для связи с другими коммутационными модулями и с AM;
- интерфейс коммутации пакетов в коммутационных модулях для связи с блоками пакетной коммутации.
OSDS обеспечивает среду распределенной обработки вызовов и позволяет разным программным процессам совместно эффективно использовать системные ресурсы."

Неубиваемое изделие.

Суровый у вас коллега! Интересно, когда он порекомендует Вам не использовать Windows


Обычно такое дают, когда ответить нечего...


Ну вот, Enthusiast, есть там ОСи, и все работает. Не волнуйтесь


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

Это вы себе надумали этот парадокс. Я такого не говорил: "здесь глюков нет, но они тут могут быть"



Что тут не понятного и где тут парадодкс?

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

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

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

Ну это совсем смешно! Гляньте сюда.
Кстати, в станции EWSD от Siemens тоже используется Unix в качестве базовой системы. Вы и о разработчиках из Siemens скажете, что они "поступились надежностью работы устройства ради простоты, удобства и времени его разработки"?

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

Широта рассуждений поражает Гугл на который вы ссылаетесь уже перевел свои серверы работающие " 24/7/365" на микроконтроллеры с bare metal прошивками ?

В реальной ситуации испытания, конечно, продолжатся (если разработчик не хочет потерять работу). Но, как появиться время/силы/возможности со сбоем надо будет разбираться.
Мало-мальски сложный софт - он модульный. Причины модульности вполне прозаические:
- снижается общая сложность проекта, до O*N, вместо O в степени. Отдельную часть проще разработать и поддерживать.
- повторное использование кода в разных проектах. Модули надо разрабатывать по возможности универсальными, с четко прописанными интерфейсами, тогда их можно повторно использовать.
Поэтому - если в проекте подозревается глюк, то его надо искать. С большой вероятностью глюк в универсальном модуле, если его не локализовать, то он будет расползаться по другим проектам.
В-общем, проекты становятся все сложнее и сложнее, функций и кода становится на порядок-другой больше, все это надо структурировать тем или иным образом. ИМХО, структурные части желательно делать максимально независимыми, и поскольку при своем выполнении все эти модули требуют банально процессорного времени, то нужен механизм его распределения и тут (RT)OS-и неплохо себя показывают.

А как иначе? Написал программу, протестил. Все ошибки вычестил. Но нет гарантии что их там нет. Для этого существуют тестеры. Тестеры тестируют, находят ошибки возврящяют продукт. Ошибки иправляются, тестеры опять проверяют. После нормального тщятельного тестирования в принцепе можно со 99,99% увереностью сказать что ошибок нет. Но тестеры тоже люди и тоже могут допустить ошибки. От этого ни кто не застрахован. Если продукт "серьёзный", то нужно сделать несколько цыклов тестирования.
Вот поэтому разработчик допускает, что ошибки могут быть (не есть, а могут быть). А если разраб отдает тестерам продукт, зная что там есть бага - смысыл его отдавать на тестирование/выпускать. Все равно вернут или будут рекламации.

Канечно ДА! И ни в коем случае не выпущю продукт зная что он сбоит. И ошибки обычно выявляются в более короткие сроки. И 10000 цыклов рабочего хода целый месяц - это уже скорее тест на износ.
Если этот агрегат есть управление ядерным реактором? Или бортовой компьютер авиалайнера? Наверно в суперджет100 и в фобасгрунт также писали прогу - за месяц 2 сбоя - можно считать изделие пригодным. )))

Ну а если это телефон, телевизор или медиаплеер? Если какой нить Sony будет выпускать сотки с 2-мя сбоями в месяц - это на руку конкурентам. Ни разу не видел чтобы телевизор где-то(у кого-то) завис. Зато дома медиаплеер время от времени глючит. Верну по гарантии и больше эту марку ни когда не куплю.

Да, я считаю точно также. А Вы считаете, что программные решения надежнее аппаратных?


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

ос != "ущерб надёжности"