Jump to content

    
Sign in to follow this  
Dubov

Оси

Recommended Posts

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

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

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

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

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

Share this post


Link to post
Share on other sites
В уже упоминавшейся 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 дает только экономию времени и денег (здесь важно слово "только").

Share this post


Link to post
Share on other sites
Спасибо, интересные ссылки.

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

 

Share this post


Link to post
Share on other sites

 

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites
девочка вышла за меня замуж и защитила диссертацию.

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

 

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

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

 

Share this post


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

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

Share this post


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

 

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

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

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

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

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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites
На чём основано данное умозаключение?

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

Share this post


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

Мои доводы:

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

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

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

Share this post


Link to post
Share on other sites
Мои доводы:

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

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

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

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

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

 

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

 

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

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

 

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

Share this post


Link to post
Share on other sites
Мои доводы:

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this