Оси, как таковые Опции

[Dubov]

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

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

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

Сообщение отредактировал Dubov - Nov 14 2012, 13:33

[juvf]

Поэтому оси и применяют даже в ущерб надежности.

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

[Enthusiast]

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

На чём основано данное умозаключение?

[haker_fox]

На чём основано данное умозаключение?

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

[Enthusiast]

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

Мои доводы:
1. Если в устройстве используется динамическое ОЗУ для исполнения программы, то снижается надёжность работы устройства в целом. Причину я озвучивал ранее.
2. Чем больше строк исходного кода используется в программе, тем выше вероятность появления ошибки в ней, а следовательно, ниже надёжность работы устройства в целом.
С этим кто-то не согласен?

[juvf]

Мои доводы:
1. Если в устройстве используется динамическое ОЗУ для исполнения программы, то снижается надёжность работы устройства в целом. Причину я озвучивал ранее.
2. Чем больше строк исходного кода используется в программе, тем выше вероятность появления ошибки в ней, а следовательно, ниже надёжность работы устройства в целом.
С этим кто-то не согласен?

Я не согласен. Я не вижу логики в ваших аргументах.
1) Какую причину вы озвучивали ранее? Какие сбои в динамическом озу? Какая взаимосвязь между озу и ос? какие сбои ячейках в динамическом озу?

Ну допустим, есть DRAM, в котором, как вы говорите "следует иметь в виду вероятность сбоя в ячейках динамического ОЗУ". Вынесем надежность DRAM за рамки этой ветки и возьмём за априори: DRAM = вероятность сбоя в ячейках, т.е. ненадежна. Загрузив в неё ос получаем глючный продукт. Кто бы спорил. Но так это не проблема ос. А теперь грузим в это DRAM прогу без ОС - и что в результате? Более надёжный продукт? Не будет сбоев или они будут реже? Тоже глючный продукт получится. И если у вас глючная память - хоть винда, хоть линукс, хоть без ос....даже хеловорд или QNX - упадут и не встанут.

2)опятьже нету тут логики. Что надежнее - 1000 строк кода без ошибок или 10 строк кода с ошибками? код ос выверенный и оттестенный код многими людьми. А ваш свежий суперлуп нужно тестить и тестить. Если вы не доверяете коду ос, потому как не доверяеете чужому коду, то тогда также не следует использовать стандартные библиотеки, нестандартные библиотеки которые кто-то писал. А компилятор - это программа, которую писали теже индусы люди, и там таже могут быть ошибки. Тогда вообще лучше писать самому на асме и самому асм переводить в машинный код, а то вдруг компилятор асма подведёт.
И более того - программа без ос не всегда меньше программы с ос.

ps а на мой вопрос вы так и не ответили: Какая взаимосвязь между динамическим ОЗУ и ос? Почему эта связка ненадёжна?

[AlexandrY]

Я не согласен. Я не вижу логики в ваших аргументах.
1) Какую причину вы озвучивали ранее? Какие сбои в динамическом озу? Какая взаимосвязь между озу и ос? какие сбои ячейках в динамическом озу?

2)опятьже нету тут логики. Что надежнее - 1000 строк кода без ошибок или 10 строк кода с ошибками? Какая взаимосвязь между динамическим ОЗУ и ос? Почему эта связка ненадёжна?

Логику искать не надо здесь. Все чисто на опыте и наблюдениях.

Вот TI выпускает серию микроконтроллеров TMS570 , сверх надежные на Cortex с двойным синхронным выполнением на двух ядрах и сверкой результатов, с ЕЕС на каждый тип памяти.
Так во первых у них нет интерфейса к DDR, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.
Буквально сегодня мне пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!
Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?
Ответ ясен, они его собирались использовать без RTOS в обычном понимании.
Т.е. в критически надежных системах RTOS не используют. Вот и вся связь

[juvf]

Вот и вся связь

Я не вижу связи. Какая связь между DDR и ОС? В их чипе нет ддр и какаято невнятная связь между какой-то фичей lockstep и ртос. Что из этого следует? что ддр с ртос не дружит?

Вот чипs TMS570LS: Так во первых у них нет DAC, а во вторых у них нет портов RTOS с поддержкой фичи lockstep.
Буквально сегодня вам пришел анонс их новой RTOS - TI-RTOS. Там опять же нет поддержки lockstep!
Они что с дуба упали? Зачем в таком сложном чипе делать lockstep если его не поддерживают RTOS?

Согласно вашей логики наблюдениям, использование ос в чипах с DAC - снижает надёжность.

ps в тойже TMS570LS есть Real-Time Interrupt (RTI) OS Timer.

[AlexandrY]

Я не вижу связи. Какая связь между DDR и ОС?

Таймер в TMS570 пришел от ядра Cortex. Это не вина TI.
DAC хотя и нет, но можно подключить внешний.
А DDR не подключить никаа...ак
С DDR не дружит надежность. Большим RTOS которые действительно экономят время и деньги своим мощным middleware (VxWorks, QNX, Symbian, ....) нужна DDR, тоже каждый знает.
Вывод - большие RTOS проектируются не для повышения надежности как минимум.
И можно сказать снижают надежность своим размером и требованием к объему памяти.

Сегодня уже процессорные ядра специально оптимизируют под конкретные операционные системы а вы все какие-то наблюдения из космоса приводите
http://www.imgtec.com/meta/meta-technology.asp

Этот пример только подтверждает, что RTOS-ам не доверяют и делают аппаратные реализации многозадачности.
Я еще помню эту технологию со времен Scenix когда они конкурировали с PIC-ами.
Не пошло. Ограниченная аппаратная многозадачность удобна только для ограниченного круга задач.

[vshemm]

Мои доводы:
1. Если в устройстве используется динамическое ОЗУ для исполнения программы, то снижается надёжность работы устройства в целом. Причину я озвучивал ранее.
2. Чем больше строк исходного кода используется в программе, тем выше вероятность появления ошибки в ней, а следовательно, ниже надёжность работы устройства в целом.
С этим кто-то не согласен?

Я, как вы понимаете, тоже не согласен. К предыдущим ораторам хотелось бы добавить следующее:
1. Чтобы так утверждать, нужно сначала определиться с методикой измерения надежности и то, по сравнению
с чем надежность ниже. Конечно, введение ненадежного элемента в систему при прочих равных снижает общую
надежность, но тут ключевые слова - при прочих равных. Понятно, что мигать светодиодом можно из-под
Windows, а можно и простенькой схемой на 155 серии, но ведь некоторые задачи без ОЗУ решить невозможно
(при разумных сроках и стоимости). Опять же, вопрос применения ОС по сравнению с не-ОС абсолютно
ортогонален надежности DRAM.
2. Логика правильная, но посылка ложная. Начиная с некоторой сложности задачи, при использовании ОС
количество кода уменьшается (при условии, что задача корректно решается).

Вообще, если уже кто-то представил себе ОС как библиотеку с неким функциональным набором, уже может сделать
вывод, что как только человек в суперлупе применяет такие понятия как многозадачность, синхронизация,
память,... - он уже реализует ОС, которая, правда, размазана по пользовательскому коду. И тогда спор
суперлуп вс ОС отпадет сам собой. Действительно, нет принципиальной разницы между решением применять
libc для printf(), например, или rtos.lib для schedule() - просто функционал разный. И физическое отделение
данных сущностей в отдельный слой выглядит весьма логичным.

Другой аспект - физическая ненадежность электроники. Это тоже решается применением всяких SOI, сапфировых
подложек для исключения тиристорного защелкивания, triple-well технологией для того же, ЕСС на всех уровнях,
мажоритарной логикой, дублированием, троированием и прочими архитектурными радостями. И это все работает.
Пример - curiosity. Там стоят два RAD750, один из которых в резерве, абсолютно не подверженных тиристорному
защелкиванию (latchup-immune), выдерживающих миллион рад суммарной дозы, с надежностью 1.6Е-10 ошибок
(single-event upset) в день. Плюс 256Kib EEPROM, 256Mib DRAM (sic!) и куча флеш памяти. Плюс физическая защита,
разумеется. В результате, расчетная надежность данного комплекса примерно 1 failure в 15 лет. Хз, много это
или мало, но точно что достаточно. А крутится там сами знаете какая ось, и это неспроста. Так что если сильно
захотеть, можно и с ненадежной DRAM в космос полететь

Логику искать не надо здесь. Все чисто на опыте и наблюдениях.

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

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

...
Этот пример только подтверждает, что RTOS-ам не доверяют и делают аппаратные реализации многозадачности.

Данные выражения ложны. Чтобы их опровергнуть, достаточно привести один контрпример - см. выше. Если куриосити
не работает в сложных условиях и там нет критически важных задач, приведу другой пример. Есть известные стандарты
авионики, применяемые Federal Aviation Administration (я хз как это перевести), в частности, ARINC-653 и DO-178B.
И есть оси, им удовлетворяющие (тот же LynxOS-178B), задача которых не кинофильмы показывать пассажирам в салоне,
а входить в состав СДУ, т.е. помогать рулить. Да что там авиация, если даже в наших современных ракетах, которые
все еще объективно одни их лучших в мире перешли от жесткой логики к вычислителю с памятью + ос - о чем-то это
говорит (только тсс, это гостайна .

Так что RTOS применяются и им доверяют.

Как-то так.

[Enthusiast]

Данные выражения ложны. Чтобы их опровергнуть, достаточно привести один контрпример - см. выше. Если куриосити
не работает в сложных условиях и там нет критически важных задач, приведу другой пример. Есть известные стандарты
авионики, применяемые Federal Aviation Administration (я хз как это перевести), в частности, ARINC-653 и DO-178B.
И есть оси, им удовлетворяющие (тот же LynxOS-178B), задача которых не кинофильмы показывать пассажирам в салоне,
а входить в состав СДУ, т.е. помогать рулить. Да что там авиация, если даже в наших современных ракетах, которые
все еще объективно одни их лучших в мире перешли от жесткой логики к вычислителю с памятью + ос - о чем-то это
говорит (только тсс, это гостайна .

Так что RTOS применяются и им доверяют.

Как-то так.

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