[Enthusiast 0]

Гм... это вариант я не учел :rolleyes:

Но он многое объясняет. Это Вас в Университете так учат, или Вы сами к таким выводам пришли?

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

Если второе - ну нормально, у каждого должно быть свое мнение. Правда, как показывает практика, практика (извините за тавтологию) немного иная :rolleyes:

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

[AlexandrY 2]

В уже упоминавшейся 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 0]

Спасибо, интересные ссылки.

Но спецы из 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]

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

 

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

(А сложность косвенно ведет к ненадежности)

С одной стороны пассивные драйвера вызывают треть ошибок в осях. Чуть ли не главные убийцы надежного софта.

С другой стороны они предлагают такой уж мудреный путь создания и верификации активных драйверов,

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

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

Скажем для драйвера Ethernet-а нужно будет 36 майлбоксов.

У меня столько на вcе фирмваре уходит с полным TCP стеком вместе с VPN, WEB, GUI, FS и прочим.

[VslavX 0]

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

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

 

 

[vshemm 0]

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

 

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

Изменено 11 декабря, 2012 пользователем vshemm

[haker_fox 60]

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

:laughing: :laughing: :laughing: :laughing: Respect!!!

 

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

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

 

[Enthusiast 0]

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

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

[AlexandrY 2]

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

 

Мне кажется вы превратно поняли.

Сделать процедуру драйвера в отдельной задаче при этом оставив switch-case структуру на входе не хитро.

В статье же речь идет о разработке протокола драйвера и верификации потом его реализации по формальной модели.

Потом там борются с таким явлением как stack ripping (я бы перевел как потеря стека).

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

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

И именно stack ripping мешает анализаторам верифицировать протокол по модели.

 

Я скажем не разу не нашел возможность сделать активный драйвер.

А в принципе мог, создав модель в том же симулинке.

Пассивный реализовать гораздо проще.

[Enthusiast 0]

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

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

[haker_fox 60]

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

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

[Enthusiast 0]

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

Мои доводы:

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

2. Чем больше строк исходного кода используется в программе, тем выше вероятность появления ошибки в ней, а следовательно, ниже надёжность работы устройства в целом.

С этим кто-то не согласен?

[demiurg_spb 0]

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

[juvf 10]

Мои доводы:

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

2. Чем больше строк исходного кода используется в программе, тем выше вероятность появления ошибки в ней, а следовательно, ниже надёжность работы устройства в целом.

С этим кто-то не согласен?

Я не согласен. Я не вижу логики в ваших аргументах.

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

 

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

 

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

И более того - программа без ос не всегда меньше программы с ос.

 

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

[haker_fox 60]

Мои доводы:

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

2. Чем больше строк исходного кода используется в программе, тем выше вероятность появления ошибки в ней, а следовательно, ниже надёжность работы устройства в целом.

С этим кто-то не согласен?

Я не согласен :rolleyes:

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

 

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