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

[Dubov]

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

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

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

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

[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 сек она перезапускалась. в таком режиме не будет ни каких утечек, ни каких сбоев, и ни каких зависанию. Тоже смишно, не правда ли.

[Enthusiast]

Смишно...

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

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


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

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

[juvf]

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

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

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

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

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

[haker_fox]

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

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

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

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

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

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

[mvm54]

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

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

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

[Enthusiast]

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

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

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

[IgorKossak]

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

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

[Enthusiast]

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

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

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

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

[haker_fox]

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

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

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

[Enthusiast]

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

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

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

[MrYuran]

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

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

[AlexandrY]

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

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

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

[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

[VslavX]

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

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

[AlexandrY]

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

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

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