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

[Dubov]

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

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

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

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

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

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

[Непомнящий Евген...]

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

[Idle]

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

[andron86]

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

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

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

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

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

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

[MrYuran]

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

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

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

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

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

[_Pasha]

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

[SyncLair]

Оси-это зло....

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

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

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


Сообщение отредактировал SyncLair - Nov 15 2012, 16:01

[Kopa]

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

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

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

Сообщение отредактировал Kopa - Nov 15 2012, 19:16

[haker_fox]

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

Извините за

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

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

[kurtis]

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

[_Pasha]

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

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

[SyncLair]

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

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

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

[juvf]

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

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

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

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

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

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

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

+1

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

[yes]

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

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

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

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

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

[AlexandrY]

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

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

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

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

[Enthusiast]

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

[_Pasha]

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

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

Сообщение отредактировал _Pasha - Dec 5 2012, 20:04

[haker_fox]

Короче тема похоже не раскрыта...

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

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

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

[Enthusiast]

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

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

[_Pasha]

Да нет, не мода, исключительно собственный опыт.

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

Кроме того, применяя ось, следует иметь в виду вероятность сбоя в ячейках динамического ОЗУ при работе в режиме 24 часа в сутки и 365 дней в году

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

[SyncLair]

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

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

[haker_fox]

Кроме того, применяя ось, следует иметь в виду вероятность сбоя в ячейках динамического ОЗУ при работе в режиме 24 часа в сутки и 365 дней в году, если ось будет исполняться оттуда.

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

[SyncLair]

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

Внутри МК в SRAM.

[polyname]

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

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

Сообщение отредактировал polyname - Dec 7 2012, 16:11

[Enthusiast]

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

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

[juvf]

На мой взгляд, поручать осям задачи управления в режиме 24/7/365 недопустимо из-за неизбежных сбоев в работе динамического ОЗУ. Увы, оси здесь проигрывают изначально, как и везде.

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

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

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

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

[haker_fox]

Внутри МК в SRAM.

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

в передаче голосовых данных оси не применяются

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

[Enthusiast]

Смишно...

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

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


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

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

[juvf]

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

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

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

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

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

[AlexandrY]

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

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

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

[haker_fox]

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

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

. Никто не мешает воспользоваться поисковиком.

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

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

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

[juvf]

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

УЖ0С!!!

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

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

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

Писать надежно под RTOS очень тяжело.

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

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

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

Поинтересуйтесь как в NASA смотрят на проблему глючности.

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

pps

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

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

[a9d]

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

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

[juvf]

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

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

[_Pasha]

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

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

[Enthusiast]

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

"Гугл".

Сообщение отредактировал Enthusiast - Dec 9 2012, 17:57

[AlexandrY]

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

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

[mvm54]

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

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

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

[haker_fox]

Он мне сказал "Запишы в записную книжку: scmRTOS ни когда не пользовать".

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

"Гугл".

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

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

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

Так от куда там могут быть глюки если сейчас там их нет?

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

[juvf]

Прям логический парадокс: "здесь глюков нет, но они тут могут быть"

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

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

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

[AlexandrY]

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

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

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

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

[Enthusiast]

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

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

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

[IgorKossak]

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

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

[ViKo]

Ну что, остается стоять и "считать" что глюков нет, и всех окружающих в этом уверять ))

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

[sasamy]

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

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

[VslavX]

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

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

[juvf]

На каком основании он "считает", что ошибок нет если допускает, что они могут быть?

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

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

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

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

[Enthusiast]

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

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

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

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

[juvf]

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

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

[sasamy]

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

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

[haker_fox]

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

Вы схемотехник или руководитель, я угадал?

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

[Enthusiast]

Вы схемотехник или руководитель, я угадал?

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

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

[MrYuran]

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

Большинство ембеддед-осей исполняется не только не из динамического, но и вообще не из ОЗУ.

[juvf]

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

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

Чем не нравится связка ос+диманическоеОЗУ? Что, ос както по другому будет работать в динамическом озу нежели в статическом? А связка ос+статическоеОЗУ надёжнее? Или связка суперлуп+диманическоеОЗУ надёжнее? ОС вообще не знает, что озу может быть динамическим или статическим, и что исполняемый код находится в озу или в пзу.

[_Pasha]

Кстати, в станции EWSD от Siemens тоже используется Unix в качестве базовой системы.

Помню эту конкуренцию, всё-таки, хорошо, что сиэстел попыталися сделать своё. Жаль, что энтузиазм также по экспоненте.. А нынче от завода Шевченко - тут промолчу.

[AlexandrY]

Большинство ембеддед-осей исполняется не только не из динамического, но и вообще не из ОЗУ.

Нынче не разберешь из чего они выполняются. Понаставили всяких акселераторов, промежуточных FIFO, кэшей.
Хуже того, теперь даже шинные матрицы могут сбоить и объявлять о своих ошибках причем разных.
И что с такими ошибками делать?
Еще не видел RTOS которые бы что-то с этим делали. В лучшем случае когда все пойдет в разнос удалят задачу.
В рамках RTOS реально сложно бороться с проблемами сырости аппаратуры и туманности спецификаций.
Проще использовать линейный код без переключений контекстов, динамических ссылок и HAL уровня и статический анализаторы кода с трассером и все тотально прошерстить. Проще в плане достижения реальной надежности.

[VslavX]

Нынче не разберешь из чего они выполняются. Понаставили всяких акселераторов, промежуточных FIFO, кэшей.
Хуже того, теперь даже шинные матрицы могут сбоить и объявлять о своих ошибках причем разных.
И что с такими ошибками делать?
Еще не видел RTOS которые бы что-то с этим делали. В лучшем случае когда все пойдет в разнос удалят задачу.

По возможности записать лог и выполнить рестарт - что тут сделаешь кроме BSOD? И такие ошибки - они ведь не от типа софта зависят, линейный монопоточный код с ними тоже что-то был бы вынужден делать?

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

Проще-то оно проще. И такой простой подход получается применять пока программы несильно сложнее уровня "Hello, world" пишутся. А потом, по мере усложнения программы начинаешь понимать, что HAL-уровень не просто так появился, и таки суперлуп себя изживает.

Вот у нас софт для основной линейки продуктов развивался так:
- 1992.. - линейный код, чистый ассемблер x86, примерно 16к кода
- 1995.. - линейный код, некоторые протоколы в фоне на прерываниях, все еще ассемблер x86, 32-64К кода
- 1996.. - ассемблер частично помирает, фоновые прерывания, 50+ процентов C
- 1997.. - первое портирование на другой контроллер (первые Мега103), доля C неудержимо растет
- 2000.. - уже есть опыт с Win32, хочется и на встраиваемой платформе такое поиметь, но ресурсов нету, суперлуп становится очень сложным и достаточно глючным, протоколы в фоне на прерываниях тоже плодятся, поддерживать с адекватным качеством становится не совсем просто
- 2006.. - появились 32-битники с ресурсами, с ценой которую уже можно иногда позволить, изучается вопрос RTOS, начинается разработка своей вытесняющей платформы.
- 2009.. - окончательный перевод всего кода аппаратной поддержки на RTOS. Ассемблер почти умер - десятые доли процента, исключая криптографию, разнообразные успешные порты на различные аппаратные платформы
- 2013..?? - перевод основного приложения на платформу RTOS. Ага, суперлуп до сих пор жив в основном коде приложения, но он на сегодня глючит и создает больше проблем чем RTOS-платформа. Это я называю - "загибается". Ну не получается весь этот разросшийся за два десятилетия функционал простым циклом нормально обработать. Сейчас изделие обрабатывает и обращения по разным протоколам, и различную периферию с кучкой протоколов, и оператор бывает с ним работает, и сетевые обращения, и веб-сервер, и по USB-MSD иногда могут данные забирать. И всем этим все еще пытается рулить суперлуп. Не, оно-то все крутится в "фоне", в своих задачах, но суперлуп с трудом уже может хотя бы просто адекватно рулить всем этим через свои убогие монопоточные интерфейсы.

В-общем, на сегодня я рассматриваю RTOS просто как не самый плохой способ модульной организации проекта. Не то чтобы очень уж хотелось ее применять, но жизнь (разрастание и повышающаяся сложность проектов) заставляет как-то организовываться. ИМХО, единственный относительно серьезный минус вытесняющей RTOS - она просит некоторые ресурсы - и память кода для размещения, и оперативную память для стеков. Все остальное вполне решаемо. Ну да, квалификация от системного/встраиваемого программиста требуется немного повыше чем для линейного "Hello, world", но не запредельная, да и расти профессионально всегда приятно. Проблема надежности у меня решается жестко - 10-15 процентов кода это ASSERT-ы. И надо сказать последние года три сработки ASSERT-ов меня вообще не беспокоят.

Ну и байка напоследок - благодаря RTOS я познакомился со своей будущей женой
Была некоторая физическая лаборатория, где сидела милая девочка-аспирантка и снимала параметры с экспериментальной установки. Лаборатория имела кое-какое финансирование, и прикупила одну из первых в университете IBM AT/286. Сначала девочка просто щелкала тумблерами на установке и вносила параметры в файл. Потом лаборатория прикупила нановольтметр с интерфейсом КОП (ака IEEE-488/GP-IB), и еще кое- какие КОП-онизированные приборы, ну и тут нарисовался я - молодой и красивый , с опытом разработки контроллера КОП для шины МПИ. Контроллер успешно был переработан для шины ISA, и написалась программа, которая сама щелкала тумблерами, снимала все параметры и писала в файл. Девочка была симпатичной, а тут еще и первая увиданная АТ-ишка с VGA-мониторчиком, и Wolf3D как раз появился. Ну глупо же было на целый рабочий день запускать экспериментальную программу (ну да, MS-DOS, и экспериментальный цикл непрерывный, с заливкой гелия и азота) и терять внимание девочки, и еще тратить время диковинного компьютера с цветным монитором.
Поэтому был написан такой себе резидентный вытесняющий двухзадачный планировщик. Програмка вставала резидентно, и меряла себе там в фоне по-необходимости. Написана она была достаточно просто на Паскале, писалась моей будущей женой и ее коллегами, грузить их всякими системными тонкостями было неприлично, пришлось "брать удар на себя" - все хитрости делал именно планировшик, помнится он даже контекст FPU переключал. Ну и AT/286 освобождалась для запуска Wolf3D - это был отличный повод наведываться в ту лабораторию. В-общем, первый опыт применения RTOS у меня достаточно успешный - девочка вышла за меня замуж и защитила диссертацию. Так что RTOS-ы не столь уж опасны (хотя.. как посмотреть ).

[haker_fox]

Оба раза мимо: сейчас я просто студент

Гм... это вариант я не учел
Но он многое объясняет. Это Вас в Университете так учат, или Вы сами к таким выводам пришли?
Если перое - не бросайте Университет, но читайте больше самостоятельно, анализируйте как делают другие. Реально делают, а не для лекции.
Если второе - ну нормально, у каждого должно быть свое мнение. Правда, как показывает практика, практика (извините за тавтологию) немного иная

[vshemm]

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

Нынче не разберешь из чего они выполняются. Понаставили всяких акселераторов, промежуточных FIFO, кэшей.
Хуже того, теперь даже шинные матрицы могут сбоить и объявлять о своих ошибках причем разных.
И что с такими ошибками делать?
Еще не видел RTOS которые бы что-то с этим делали. В лучшем случае когда все пойдет в разнос удалят задачу.
В рамках RTOS реально сложно бороться с проблемами сырости аппаратуры и туманности спецификаций.
Проще использовать линейный код без переключений контекстов, динамических ссылок и HAL уровня и статический анализаторы кода с трассером и все тотально прошерстить. Проще в плане достижения реальной надежности.

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

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

Теперь рассмотрим вопрос о количестве ошибок в программе. Чтобы убедиться, что их там нет, необходимо:
1. Формально верифицировать математическую модель программы.
2. Формально верифицировать исходный код программы на соответствие этой модели.
3. Формально верифицировать компилятор на правильную кодогенерацию под определенную железную архитектуру.
4. Верифицировать железо на соответствие архитектурной модели под которую компилятор производит кодогенерацию.
До тех пор, пока этого не сделано, ошибки в программе есть.
Очевидно, в случае использования ОС пункты 1 и 2 значительно облегчаются, т.к. ОС верифицируется один раз,
а пользовательского кода становится меньше и матмодель проще.

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

В уже упоминавшейся NASA есть интересный документ [1], в котором хоть и тезисно, но рассматриваются подобные
вопросы проектирования. В частности, вопрос выбора "без ОС" vs "одна из существующих ОС" vs "разработка своей ОС".
Настоятельно рекомендую к прочтению. Более глубоко вопросы дизайна эмеддед систем рассматриваются в [2] - тоже
must read, имхо.

------
[1] http://www.hq.nasa.gov/office/codeq/doctree/871913.pdf
[2] http://www.ee.ui.ac.id/muis/course_file/Re...nd_Analysis.pdf

P.S. Я специально не касался ошибок при эксплуатации (а-ля сбои из-за случайных частиц и прочего), т.к. это
отдельная тема. Но и там ОС выигрывают у суперлупа из-за уже существующих моделей при fault/failure кейсах.
А если AlexandrY не видел такие ОС, которые бы "что-то с этим делали", то это не значит, что их нет.
Даже если сравнивать программно-аппаратное решение с чисто аппаратным, однозначно сказать что последнее
надежнее - нельзя (опять же, смотрим [1] и [2]).

[Enthusiast]

Гм... это вариант я не учел
Но он многое объясняет. Это Вас в Университете так учат, или Вы сами к таким выводам пришли?
Если перое - не бросайте Университет, но читайте больше самостоятельно, анализируйте как делают другие. Реально делают, а не для лекции.
Если второе - ну нормально, у каждого должно быть свое мнение. Правда, как показывает практика, практика (извините за тавтологию) немного иная

Спасибо за совет, а в университете я изучаю маркетинг

[AlexandrY]

В уже упоминавшейся NASA есть интересный документ [1], в котором хоть и тезисно, но рассматриваются подобные
вопросы проектирования. В частности, вопрос выбора "без ОС" vs "одна из существующих ОС" vs "разработка своей ОС".
Настоятельно рекомендую к прочтению. Более глубоко вопросы дизайна эмеддед систем рассматриваются в [2] - тоже
must read, имхо.

Спасибо, интересные ссылки.
Но спецы из NASA в книге из 400 страниц, собственно выбору RTOS vs No RTOS посвятили всего 3-и параграфа.
А потом и вообще отправили курить суперлуп для малых встраиваемых систем - Get by Without an RTOS

В книге "REAL-TIME SYSTEMS DESIGN AND ANALYSIS" подход менее бюрократичный и более серьезный.
И там сразу предупреждают(вольный перевод), что для RTOS нет единых обобщенных методик верификации.

Хотя да, никто не связывает надежность и вопрос применения RTOS. Но скажем NASA проговаривается в таком смысле, что RTOS дает только экономию времени и денег (здесь важно слово "только").

[vshemm]

Спасибо, интересные ссылки.
Но спецы из NASA в книге из 400 страниц, собственно выбору RTOS vs No RTOS посвятили всего 3-и параграфа.
А потом и вообще отправили курить суперлуп для малых встраиваемых систем - Get by Without an RTOS

Да не за что
Учтите, что там рассматривается огромный пласт проблем, и чтобы умудриться засунуть его в 400 страниц (это всего
ничего), пришлось излагать материал поверхностно, тезисно. Т.е. этот документ типа памятки инженеру, не более.
Но я хотел подчеркнуть, что в NASA при проектировании рассматривают вопрос применять ли ОС, а если да, то какую,
может, RTOS, может, самим написать, и т.д. Имхо, это единственный грамотный подход.

В книге "REAL-TIME SYSTEMS DESIGN AND ANALYSIS" подход менее бюрократичный и более серьезный.
И там сразу предупреждают(вольный перевод), что для RTOS нет единых обобщенных методик верификации.

Скорее, более абстрактный. Опять же, это инженерная книга, да еще 2004 года, а наука идет вперед. Проблемами
верификации занимаются давно, и даже есть методики (тот же DO-178B). Так или иначе, формальная верификация,
сиречь - математическое доказательство, является конечной целью. Вот, осенний свежачок [1] и [2]

Хотя да, никто не связывает надежность и вопрос применения RTOS. Но скажем NASA проговаривается в таком смысле, что RTOS дает только экономию времени и денег (здесь важно слово "только").

Как не связывает, вон, Enthusiast связывает, ему прямо уже говорят, мол "ос != "ущерб надёжности"".
А NASA применение ОС подразумевает неявно, говоря, например, о RMA (Rate Monotonic Analysis, частотно монотонный
анализ) и вообще, там много "осевых" терминов по тексту.
Вообще, если представить ОС как тупо набор библиотечных функций реализующих определенные сущности, вопросов будет
меньше (а во многих глубоко эмбеддед ОС это и есть статически прилинковываемая библиотека).

[1] http://arxiv.org/ftp/arxiv/papers/1210/1210.2882.pdf
[2] http://arxiv.org/pdf/1211.6185.pdf

[AlexandrY]

[2] http://arxiv.org/pdf/1211.6185.pdf

Статья про активные драйвера, кстати, неоднозначно показывает решение проблемы сложности драйверов.
(А сложность косвенно ведет к ненадежности)
С одной стороны пассивные драйвера вызывают треть ошибок в осях. Чуть ли не главные убийцы надежного софта.
С другой стороны они предлагают такой уж мудреный путь создания и верификации активных драйверов,
что только одни вспомогательные действия вызовут новую кучу ошибок.
Эт не говоря уже от том что на каждый чих там нужен майлбокс.
Скажем для драйвера Ethernet-а нужно будет 36 майлбоксов.
У меня столько на вcе фирмваре уходит с полным TCP стеком вместе с VPN, WEB, GUI, FS и прочим.

[VslavX]

[2] http://arxiv.org/pdf/1211.6185.pdf

Спасибо за статью. Очень интересно почитать было, еще буду разбирать-обдумывать методику верификации (кажется там есть новые для меня идеи), потому что использую описанную технологию активных драйверов (думаю ее много кто использует - идея-то "на поверхности") - именно обработка всего доступа к аппаратуре в едином потоке, и единая точка разбора входящих событий, с перекрестной верификацией (при помощи встроенных ASSERT-ов) начального и конечного состояния внутреннего автомата. Это позволяет не парится вообще о синхронизации многопоточного доступа к ресурсам - из кода уходят все эти критические секции, и код становится более быстрым и читаемым. Мейлбоксы как-то не расплодились - использую очереди, часто нативные (встроенные в данные, например в поля буфера сетевых пакетов) и единый семафор/масочное событие для модуля. Причем такой подход отлично работает не только в драйверах. Жаль подобной статьи не попалось ранее - избавило бы от многих мук выбора драйверной модели. Данные про сравнительную производительность немного удивили - утилизация CPU выше (это понятно), но и пропускная способность выше (это странно немного - предполагал что производительность как раз страдает, готовлюсь к кое-какому рефакторингу)

[vshemm]

Это всего лишь статья

Edit: Вообще, шерстите arxiv.org и мониторьте, иногда там жемчужины попадаются.

Сообщение отредактировал vshemm - Dec 11 2012, 22:31

[haker_fox]

девочка вышла за меня замуж и защитила диссертацию.

Respect!!!

Спасибо за совет, а в университете я изучаю маркетинг

Каким же образом Вы связаны с программированием и схемотехникой? Заинтриговали!

[Enthusiast]

Каким же образом Вы связаны с программированием и схемотехникой? Заинтриговали!

Напиши в личку, пообщаемся

[AlexandrY]

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

Мне кажется вы превратно поняли.
Сделать процедуру драйвера в отдельной задаче при этом оставив switch-case структуру на входе не хитро.
В статье же речь идет о разработке протокола драйвера и верификации потом его реализации по формальной модели.
Потом там борются с таким явлением как stack ripping (я бы перевел как потеря стека).
Т.е. драйвер разрывается на отдельные операции по окончании которых вы не можете надеяться на сохранение информации о состоянии драйвера в стеке.
Вы должны создавать структуры состояний для каждой задачи использующей драйвер. Просто перенос процедур драйвера в отдельную задачу проблемы не решает.
И именно stack ripping мешает анализаторам верифицировать протокол по модели.

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

[Enthusiast]

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

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

[haker_fox]

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

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

[Enthusiast]

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

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

[demiurg_spb]

Интересный сайтик по теме: http://wiki.osdev.org/Main_Page

[juvf]

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

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

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

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

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

[haker_fox]

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

Я не согласен
Любая память может сбоить. И не обязательно гонять ОС на динамическом ОЗУ. Многие RTOS вполне поместятся во внутреннюю SRAM 64 кБ. У меня контроллер с SDRAM работает несколько месяцев без выключения. Сбоев не было.

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

[vetal]

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

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

[AlexandrY]

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

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

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

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

[sasamy]

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

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

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

[juvf]

Вывод - большие RTOS проектируются не для повышения надежности как минимум.

вывод за уши притянут.

[_Pasha]

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

Упрощенка, напр. пропеллер: там разделение аппаратных ресурсов за счет "бегущего 0 или 1", в итоге 160МГц - 8 ядрышек на 20МГц. Видимо, просто не дали им пойти дальше.

[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]

По просьбам трудящихся я приведу здесь ссылку на отчёт североамериканских сотрудников "Гугла" об отказах в работе динамической памяти на серверах: "DRAM Errors in the Wild: A Large-Scale Field Study".

[AlexandrY]

А крутится там сами знаете какая ось, и это неспроста. Так что если сильно
захотеть, можно и с ненадежной DRAM в космос полететь

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

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

Как-то так.

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

[Enthusiast]

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

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

Как-то так.

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

[a9d]

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

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

Это не совсем так. Почти весь софт (включая оф. сайт) разрабатывается и поддерживается индусами. Ti это никак не скрывает. Вот отсюда и растут все ихние проблемы.

После нового года поступят в продажу SoC CC2538(он же CC2580 Cortex+ZigBee). Первоначально они анонсировали поддержку FreeRTOS но вот совсем недавно они заявили, что FreeRTOS поддерживаться не будет. Они не смогли портировать Z-Stack на RTOS. И это не вызвано соображениями надежности. Они ответили, что Z-Stack для запуска на FreeRTOS нужно переписать а они это делать не будут. Хотя перед этим они пытались это сделать.

[vshemm]

Гугл отдельная тема. Данная статистика просто пища для размышлений. У МС тоже есть публичная статистика по фолтам
в винде Но тут другое. Гугл (я сейчас очень утрированно скажу) применяет ненадежное оборудование для построения
надежной системы. Т.е. он применяет дешевый шлак для построения надежной и робастной системы. Как им это удается?
Математика. Map reduce, сейчас вот spanner, причем это уже устаревшие технологии для гугла. Посмотрите на данную
статистику с другой стороны - гугл вопреки ошибкам в дешевой DRAM выдает на гора надежные решения.
Но и задача у гугла другая, не сравнимая с мелкосерийным производством межпланетных аппаратов (грубо говоря, у них
миллиарды микросхем памяти, в отличие от единичных аппаратов). Так что мимо.


Мой поинт в том, что люди, постоянно выдающие тезисы типа "винда говно", "линукс говно", "QNX - RTOS, остальное говно",
"суперлуп решает" и прочее (не обязательно прямым текстом, но косвенно... и это очень хорошо видно), - фанатики.
Адвентисты седьмого дня. Особенно "программисты QNX", почему то. И они сами себя зашоривают, не видя альтернатив.
Поэтому действительно серьезных задач они решать не могут. Вот я уже подчеркивал, что НАСА в своей памятке говорит
про выбор, выбор ОС, выбор без-ОС, выбор своя-ОС. Каждой задаче - свое решение. Чем бОльшим инструментарием владеет
исполнитель, тем эффективнее будет решена задача в среднем. Технико-экономическое обоснование должен писать не фанатик.
Но фанатики больше всех орут, и это печально

Если рассуждать в том же духе, то на международной космической станции у космонавтов ноутбуки вообще работают под "Виндой". Теперь "Винда" стала космически надёжной осью что-ли?

Будете смеяться, но и так было. Т.е. тупо подходит будущий космонавт (с начальством, разумеется) и говорит: "надо что бы
я на МКС засунул флешку в комп и винда восстановилась". И ничо, летит щас из перигея в апогей, и восстанавливает. И я руку
даю на отсечение, что восстановит.

[sasamy]

Упрощенка, напр. пропеллер: там разделение аппаратных ресурсов за счет "бегущего 0 или 1", в итоге 160МГц - 8 ядрышек на 20МГц. Видимо, просто не дали им пойти дальше.

Ну вы как и AlexandrY упростили настолько что исказили суть. Во первых аппаратные потоки там могут исполняться одновременно используя свободные ресурсы, а во вторых планировщик ресурсов там приоритетный благодаря чему например возможна работа RTOS совместно с GPOS без всякой виртуализации.
http://www.imgtec.com/factsheets/meta/Meta...re_Overview.pdf

Применять операционные системы с исполнением из динамического ОЗУ в задачах управления в электронных устройствах недопустимо.

Про какое управление вы говорите ? Я знаю массу примеров промышленных установок под управлением OS/2 например станки с ЧПУ, АСУТП и маркетологам типа вас ничего подобного не сделать.

Сообщение отредактировал sasamy - Dec 14 2012, 06:51

[juvf]

Применять операционные системы с исполнением из динамического ОЗУ в задачах управления в электронных устройствах недопустимо.

Это уже религия. ))

Ещё раз спрашу: Почему ос+DRAM менее надёжнее чем oc+SRAM или чем чем суперлуп+DRAM?

Вам уже др учасники форума объясняют, что ос или суперлуп - в конечном счете одно и тоже. что schedule или что организация многозадачности в суперпуле - это одно и тоже. И ни как не связанно с ОЗУ.

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

Я вас призываю опираться на здравый смысл и научиться думать своей головой. Какие факты? Если бы была бы такая машинная команда, например с мнемоникой "ramJamp a,b;". И всё ртос используют эту команду, но эта команда ненадёжно работает с DRAM, а в суперпуле ни кто эту команду не вызывает - вот это был бы факт. Есть подобные факты? Код ос, например FreeRTOS, присутствует впроекте в виде исходников на си. код задач также написан на си. компилятор собрал исполняемый код. почему он на DRAM будет работать хуже менее надёжно?

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

Сделайте эксперемент: запилите какойнить девайс.... напишите несколько задач и загрузите задачи вычислениями, пусть ПИ считают, да передают друг другу массивы большие. и запустите сие чудо на DRAM разных типов, например ddr, ddr2, ddr3, ... и при чем разных производителей..... каждых типов по 3-5 производителей. напишите программу с ос и без ос. и потестите. И причем для чистоты эксперемента пусть будет около 3 RTOS ну и 3 неRTOS. ну и потом всё тоже самое, только на статическом озу. - ну вот будет вам детальное исследование и факты.

ну из моей практики: около 12 лет крутится ос в системах, где ошибка=человеческая жизнь, круглые сутки на DRAM, в некоторых местах ещё на 386 компе - ни каких сбоев. Ща ртосы внедрил в проекты, тоже в такие системы, где связанно с жизнями - все работает и ни каких сбоев. Вот вам факт.

[murug]

Сугубо практический вопрос на обсуждаемую тему. Только выбор стоит не "без ОС или с ОС", а "с минимальной ОС а-ля FreeRTOS или с ОС побольше а-ля uClinux".
LPC2478 (ARM7-TDMI, 96 кБ ОЗУ, 512 кБ флеш) + дофига (десятки мегабайт) внешней памяти с возможностью выполнения оттуда кода, как ОЗУ так и флеша.
Прибор - контроллер АСУТП. Из стандартных вещей, для реализации которых хотелось бы использовать какие-то готовые программные модули - работа с графическим индикатором (текст, простейшая графика - диаграммы), USB Host и Slave, работа с файловой системой на флешке. Остальное - сбор дискретных, аналогвых и цифровых данных, расчеты и логика управления - пожалуй никак не связано с выбором ОС.
Требуемое время реакции на некоторые события жесткое и весьма малое, порядка сотен наносекунд. Обеспечит ли какой-нибудь из линуксов такое время?
Я сам раньше ни с какими ОС не работал. Главным образом поэтому и склоняюсь к чему-то совсем простому типа FreeRTOS, в чем легко будет разобраться. Кроме того предполагаю, что возможности линукса избыточны для моей задачи, а вот ресурсов он явно будет потреблять много.
Прав ли я? Или может быть линукс содержит какие-то вкусности, которые в рамках обрисованной задачи компенсируют время, потраченное на его освоение?

[demiurg_spb]

uClinux + LPC2478 + Требуемое время реакции на некоторые события жесткое и весьма малое, порядка сотен наносекунд.

Не реально. У нас на AM3517 600MHz + Linux + PreemptRT время переключения контекста 160мкс.
А у вас частота фактически в 10 раз ниже. Можете поэкстраполировать.

[juvf]

Не реально. У нас на AM3517 600MHz + Linux + PreemptRT время переключения контекста 160мкс.
А у вас частота фактически в 10 раз ниже. Можете поэкстраполировать.

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

[demiurg_spb]

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

Я не замерял таким образом. Так-что пока не могу вам ответить на вопрос.

[ReAl]

LPC2478
...
порядка сотен наносекунд

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

Тут неподалёку как-то обсуждалось время переключения задач в scmRTOS на Cortex-M3 (72 MHz STM32F1, 100 MHz LPC17). Ну так эти «сотни наносекунд» идут десятками.

[AlexandrY]

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

Сам микроконтроллер выбран неправильно. Нужно было брать на Cortex-M3 или M4. Там механизм прерываний оптимизирован для малых задержек.
И там легче сделать независимые от оси прерывания.
Вообще независимые от оси прерывания можно сделать практически на любом современном микроконтроллере и в любой оси включая линукс.
Надо только порт оси поправить и все драйвера. Чтобы не было глобальных запрещений прерываний.

Очень быстрый механизм прерываний с поддержкой сервисов оси сделан в свободной RTOS от Keil-а.
https://www.keil.com/demo/eval/rtx.htm

[TigerSHARC]

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

нет не успеет.
читайте http://www.at91.com/linux4sam/bin/view/Linux4SAM/RealTime

[murug]

Ок, вынесение самых критичных по времени действий в обработчики прерываний - снимает вопрос времени реакции.
А возвращаясь к вопросу о вкусностях - для работы с USB и FAT'ом - как обстоят дела с хорошими бесплатными библиотеками под линукс и под FreeRTOS?
И еще, вопрос объема используемой памяти оказался все-таки актуальным. Какого порядка объемы флеша и ОЗУ нужны под ядро линукса и под каждую задачу?

[TigerSHARC]

Ок, вынесение самых критичных по времени действий в обработчики прерываний - снимает вопрос времени реакции.

с чего вы это взяли? смотря с какой частотой прерывания поступают. Навскидку: прерывания до 1кГц только можно "ловить вовремя", быстрее - сложнее. А о частотах порядка мегагерц и речи нет. Всё зависит от задачи.

А возвращаясь к вопросу о вкусностях - для работы с USB и FAT'ом - как обстоят дела с хорошими бесплатными библиотеками под линукс и под FreeRTOS?

В Linux с этим, насколько я знаю, лучше чем у других.

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

тут не подскажу. Ведь ещё ucLinux бывает

P.S. реализация TCP/IP в Linux - одна из самых лучших. всякие Lwip и рядом не валялись. ИМХО

Сообщение отредактировал TigerSHARC - Dec 17 2012, 06:44

[demiurg_spb]

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

Всяко бывает. Всё от задачи зависит.