Проектирование КПСВВ ядра ОСЖРВ и зачем оно такое чудо...

Using Kolibri in embedded systems
  • По теории практически 100 % надежность (99,99999.... % ) обеспечивает 3-х контурная дублирующая система. Где 1 контур является работчим, 2 альтернативным, а 3 проверяет работу 1. Если произошел сбой 1, то перераспределяются. 2 включается, 3 альтернативным, 1 перезапуск и контроль 2. И так далее.
    Вроде так если не запутался.
    Соответсвенно должна быть трехпроцессорная модель, с тремя ядрами (главными циклами), для полной надежности.
  • VaStaNi
    RTS (СРВ) делятся на HRT (жёстк. реальное время) и SRT (мягк. реальное время). Первая гарантирует появления результата в заданный интервал времени с вероятностью 1, вторая с заданной вероятностью (P<=1). Вот и всё!

    Причём "заданный интервал времени" вполне может быть и большим, по этому поводу наш преподаватель привёл хороший пример: печь для обжига цемента. Она представляет из себя горизонтальный вращающийся цилиндр, цемент обжигается горелками, которыми управляет СРВ. Так вот, снятие параметров происходит один раз в час, по этим параметрам корректируется работа горелок. И это HRTS! Т.к. раз в час мы получаем результат, в виде анализа полученных данных и управления горелками. Это я к тому что многие восхищаются системами реального времени как очень быстрыми (реакции порядка неск. мкс. а то и нс, etc.... ), но это не всегда так. И ещё для примера: управлене инжекторными двигателями в автомобилях как правило поручают системам мягкого реального времени, т.к. некоторая задержка там не особо критична. По поводу винды : есть WinCE - вполне себе СРВ.
  • Термины "жёсткое" и "мягкое" реальное время придумали в MS когда пытались пропихнуть NT в качестве RTOS. Разница в том, что в настоящей RTOS время отклика системы на событие можно рассчитать точно а в "мягкой" нет.
  • По поводу MS с NT не соглашусь, а остальное как я и говорил.
  • Ну раз модеры считают, что тут излагать полные объемы статей на нескольких листах, норма, то бомблю
    тут ЧАСТЬ 2.
    -----------------------------------
    Продолжаем.

    Забегая вперёд сразу скажу, что "наш робот" обречён постоянно падать на землю,
    даже если его несколько раз пытаться "ставить на ноги"..., так как система
    в целом НЕ будет функционировать! И это при всём при том, что железо и прикладное ПО выполнены у нас изумительно!
    Да, да, да я собираюсь больно ударить по самому святому для некоторых - незыблемости ОС, правильности её организации и функционирования,
    свойствах и способности обеспечить стабильные таймерные воздействия на девайс,
    посредством портов ввода-вывода! Очевидно, что как "прослойка" между ПО прикладного уровня и девайсом стоит - ОС. В первую очередь это драйвера и стратегия работы драйверного уровня, базовые механизмы ядра.
    Естественно, что обеспечить нам стробированные 1 мс интервалы
    это весьма круто, для современных известных ОС и "планка требований" - это явный перебор... типа нереальность это, но если "заказать" даже 10 мс жёсткого периода БЕЗ «дрожания фронтов»(!), то для многих ОС это все равно будет проблемно.
    Почему? Куда я клоню, в конце концов? Хорошо, я не буду перебирать все ОСи/архитектуры их достоинства и недостатки, это можете сделать Вы или более знающий меня, да и в данном конкретном случае это мне (нам) и не нужно, будем отталкиваться от исходных данных и в их жёстких рамках пытаться предложить решение, или хотябы метод, направление, куда идти в таком случае, особенно в области ОСестроения, чтобы ОС могла позволить решать такие комплексные задачи.
    Чем, какой ОС можно решить данную задачу или что из существующего можно улучшить?
    1) ДОС. ДОС даёт почти полную широту и размах творений, но это будет ОДНОЗАДАЧНЫЙ аппарат, который "угробит" все прелести современных PC машин, тут придется распрощаться и со многими современными девайсами и гибкостью и т.д.
    Но! Но, как замечательно просто тут обеспечить 1 мс! Берем и пишем обработчик IRQ0, который в силу архитектуры железа имеет максимальный приоритет, в него "будем гарантированно попадать" каждый 1 мс тик таймера. Ну и таймер 8054, конечно "заведем", как периодический 1 мс. Этот обработчик выполняет критически
    важный участок по работе с портами (девайсной периферией). Остальная часть задачи, по сути, это прикладуха чистой воды, которая будет брать/посылать данные через некие буфера ввода-вывода. Тут, собственно ОС, вырождена, она не посредник!
    Но задача то выше объявлена, как многозадачка! Значит, отпадает этот вариант. Но узелок на память, о красоте решения проблемы узкого места, оставить надо ;)
    2) Винда или еще что то из серии... Главнейшая проблема архитектурно-принципиального плана: планировщики задач, менеджеры процессов, драйвер, как почти рядовая задача вне зависимости от того в каком кольце защиты он и с каким суперсистемным приоритетом он работает, а ещё есть IPC...
    Обобщим приговор. Данная архитектура, "плавающая" во времени, ввиду ряда причин, не может дать предсказуемых, программируемых, и уж тем более, жестких, гарантированных временных событий в виде обращений портов ввода-вывода.
    3) ОСРВ типа QNX и им подобные архитектуры имеют существенные изъяны по быстродействию, для подобных задач. Основной минус и потери на IPC, несмотря на то, это уже ОСРВ. Плюс сюда их "жёсткость", насколько мне известно, на такие временные вещи не распространяется, т.е. они обеспечивают десятки миллисекунд... "Нас" это в 21 веке не устраивает :) ну хорошо, пусть будет не наглое нас, МЕНЯ.:) Меня не устраивает это и еще то, что рядом с этим лежит, связано, видно... мне, и, быть может, далее и Вам. :)
    4) Нужно новое решение. Анализ недостатков, достоинств, обобщение и компромиссное решение.
    Если проанализировать ныне известные и широко-используемые архитектуры ОС, в первую очередь пожалуй ОСРВ, то создается впечатление, что либо в целях упрощения, либо упущения, про синхронные операции ввода-вывода забыли или пренебрегли, посчитав их архаизмом что ли. Как сегодня яростно изживают LPT порт! А ведь железячникам, прибористам, ничего адекватного по скорости и простого по доступу не предлагают.
    USB, FireWare... это все намученные, да накрученные, помимо того это последовательные данные(!), о стробировании и синхронном вводе-выводе не может быть и речи, сразу возникает проблема наличия/создания собственными силами ответного девайса, протокола работы самого порта и протокола "итогового" взаимодействия с девайсом и т.д.
    Далее. Возможно и то, что среди "архитекторов" ОС настоящих "железячников" и не было... либо их голос ничего "не весил".:) А что? Могу предположить и такое. Имею право.:)
    Результат, как говорится на лицо. Какой ценой, если отметать полную невозможность выдержать временные требования задачи, "приходится платить" если её все же РЕШАТЬ?
    Что приносится в жертву вне нашего желания ущербной ОС при попытках "вписаться" в существующие жёсткие правила "жизни железа", которые при фактической реализации и дают истинную интеллектуальную жизнь комплекса в целом? Пусть робот не умеет ходить, но равновесие он держать должОН!? Т.е. стоять, балансировать при качках вправо-влево... ;)
    Согласитесь, для очень большого количества людей ОС - это почти только то, что
    они видят на экране и слышат...
    А ведь ОС, нужна человеку и для некоторой конечной физической цели в конце концов, а не для того, чтобы сидеть на стуле и наслаждаться тем, что в ней, в ОС, "под её крылом", так сказать мирно живут 100, 1000 или 1000000
    весьма разумных, качественных приложений! Грубо говоря, просто перебирать, сортировать, мутировать терробайты цифр и этим ограничивать цель многозадачности ОС, дело скучное и огранниченное... по крайней мере для таких как я! :D Я верю, что есть думающие, как я, ведь мы, слава Богу не машины и не клоночеловеки!
    Лично я, хочу видеть решения по ОС, позволяющие ЭФФЕКТИВНО управлять чем либо внешним и чем более эффективно и масштабно, тем лучше.
    Получается, что даже имея xxxxx$ зеленых купив QNX задачу не решить. Так? Особенно, если о xxxxx$ и мечтать не приходится...
    Возможные писсимисты и противники моих доводов и примеров скажут, наверное,
    да что тебе еще надо? Возьми современный USB стык или несколько их, ну напиши драйвер под них и даже под свою ОС и "ворочай" свои железки. Но скажет это, думаю, как раз тот, кто не писал драйвера, не сталкивался с проблемой синхронного ввода-вывода ИМЕННО в драйвере, не видел множество
    мест этапов жизнефункционирования дайвера, его алгоритма!
    Да, скажу я вам по своему опыту, пишущий даже простой драйвер под многозадачную ОС, и который писал уже, умеет писать под ДОС, не раз в процессе создания, вспоминает прелести ДОСа и прямоты работы с портами!
    Прежде всего печально и удручающе действует то, как нарастает огромный снежный ком тактов..., нет отнюдь не снежный, пожалуй, а огромный ком ...ма
    на простые операции ввода-вывода, какой ужас охватывает сознание, когда цена расплаты возростает в тысячи раз, по сравнению с тем, если бы это было более оптимально решено в архитектуре ОС.
    Ну пусть не так прямо и не так непосредственно, как в ДОСе, понятно, что за многозадачность все равно платить надо, но можно наверное и более дешевле раз в 10 или 100, наверное, по тактам выигрыш получить, совокупно системой затраченные на «переброс» всего одного байта от уровня приложения до самого порта или в обратном направлении.
    Плюс, решить вопрос синхронизации этих обращений к портам, чтобы не плавали они
    в "+" и в "-", как "...но в проруби".
    А драйвера, скажут мне поверхностные люди, грамотно надо писать! Используй прерывания железки + системы!
    Использую, использую, спокуха! Только не всегда ЭТО удовлетворяет, не всегда ТОЛЬКО ЭТО нужно, не всегда и ВСЕ прерывания заложены во ВСЕ механизмы работы устройства! Я уточню, в данном месте, речь идет уже об устройстве внутри PC машины (контроллер периферии), а не том, что вне его цепляем. Ведь для ОС
    "по барабану" какой порт это. LPT на котором, что то подключено или это порт контроллера USB, FDC, SMBUS, аудиокодека... Итог, к сожалению, как приговор, один, чем меньше, казалось бы нужно данное обращение к порту, чем более оно «не важно», тем больше надо заплатить. Вот и получается, что для всех обращений к портам, требующие периодического, строго-периодического опроса или записи, к таковым относятся драйверные механизмы ожидания готовности, инициализаций или когда, действительно нужно строгое равенство промежутков времени
    между обращениями, приходится уделять внимания при программировании, под час гораздо больше, чем к тем участкам драйвера, где, собственно производится самая полезная работа драйвера устройства. Чаще всего полезная, это именно передача данных да еще скоростная, потоковая, да еще и дуплексная. Еще раз напомню, что тут разработчики и ОС и железячного контроллера, как бы старались и Вы имеете и прерывания и скорость, но вот о том, чтобы сообщить, генерировать прерывание по готовности, это не везде есть. Вернее сказать, чаще всего, почему то, его просто нет. Выводы делает каждый сам.
    Почему я из мухи делаю слона!? Давайте все же прикинем степень расплаты, хотя бы, а если у Вас есть возможность посчитать или ЗАМЕРИТЬ такты (RDTSC) в Вашей ОСи, в Вашем драйвере, то сделайте это.
    Итак, ожидание, ожидание готовности - это полезная работа ОС или холостой ход, простой, на который тратится процессорное время, ввиду ВЫНУЖДЕННОЙ необходимости? Явно, это не полезная работа - ЭТО ЖЕРТВА! Вынужденная жертва, это та самая цена.
    Получается так, что если простой/ожидание часами, сутками, то расход максимален, а если, скажем, чуть чуть тормознула ОС... ну винда «морозится», скажем когда пустой CD вставляешь или вообще он "битый", ну тогда неприятно, но потерпеть дескать можно, ну отвернуться можно и переключить внимание на что либо,
    чтобы не тошнило в очередной раз от этого... Нет, ну может быть кому то и все равно в офисе, а может, кто то привык, кто то смирился или смиряется с «ценой». Но мы то нет! :) Мы то не крестики-нолики на экране гонять хотим...
    Я лично, против, чтобы холостому ходу, в массе своей, "пустым" операциям тестинга портов устройств, уделялось так много времени. Подбираюсь к главному - контекст переключения задачи сжирает массу машинного времени при передаче считанного значения с тестируемого порта наверх, где собствено и производится оценка.
    А ведь очень много случаев, когда простой, ожидание гораздо длительнее передачи "полезных" данных или параметров! Причем, для передачи "полезных" данных, как правило, имеются порты у которых есть аппаратные механизмы разгрузки поцессора, такие, как аппаратные прерывания завершения, прямой доступ к памяти DMA,
    и тут сами обращения могут быть блочными, следовательно расход тут невелик.
    А если в ряде случаев, происходит нештатная ситуация и код ОС или драйвера "вылетает" на длительную, быть может глухую ветку анализа готовности, которой не будет никогда? Понятно, что «жертвецки» написанный участок неким высокоуровневым
    программистом будет ОБЫЧНО не виден при "штатном полете", а вот в случае если все же..., то имеем ситуацию "приморозки", даже если Вы обладатель 2х голового CPU, то это не спасает - горбатость архитектуры ОС делает своё дело!
    -----------------------------------
    Это еще не все. Планирую, в 3й части вплотную заняться описанием новаторства в ядерном решении проблемсов... :wink:
  • Спасибо, за посты, но впечатление, что все из нас думают несколько разно и о своем... Это нормально. Каждый человек располагает и пользуется в общении своими заниями, опытом, лекциями преподавателей, авторитетным окружением... Надеюсь представления некоторых изменятся или УТОЧНЯТСЯ после 2 части, дабы далее можно было говорить на одну тему. Возможно и то, что только 3я часть расставит точки над "i". Во всяком случае мне интересно какова аудитория у меня и насколько доходчив материал... Известно, что VaStaNi пытаясь донести все слишком подробно и исключить лишние вопросы этим добывается подчас обратного :( Может есть положительные впечатления? Весьма любопытно.
  • VaStaNi
    Получается так, что если простой/ожидание часами, сутками, то расход максимален, а если, скажем, чуть чуть тормознула ОС... ну винда «морозится», скажем когда пустой CD вставляешь или вообще он "битый", ну тогда неприятно, но потерпеть дескать можно, ну отвернуться можно и переключить внимание на что либо,
    чтобы не тошнило в очередной раз от этого...
    Не надо сливать кривую реализацию одной операционной системы на все остальные.
    В Колибри такого нет, и надеюсь, не будет. Я, например, написал опрос события нажатия кнопки выдвигания диска лишь при наличии блокировки привода и то 1 раз в секунду. Аппаратной реализации сообщения о событии в виде прерывания у ATAPI как выяснилось, нет. Но код абсолютно не нагружает систему, потому что написан настолько грамотно, насколько я смог разобраться. А Винда она и есть Винда...
  • VaStaNi

    Блин! Опять ты городишь из мухи слона.

    1. Роботами не управляют через LPT.
    Для промышленных задач есть своё промышленное оборудование и системы. Ищи специализированные контроллеры.

    2. Почему ты решил что QNX и другие настоящие RTOS обеспечивают только десятки миллисекунд ? Надо читать документацию.

    Interrupt latency (т.е. время от наступления аппаратного прерывания до выполнения первой инструкции пользовательского обработчика) по данным QNX Software Systems составляет:

    22.5 microsec 33 MHz 386EX
    5.6 microsec 100 MHz 486DX4
    4.4 microsec 100 MHz Pentium
    3.3 microsec 166 MHz Pentium (информация с http://www.qnx.com)

    Для современных процессоров оно (время) видимо меньше 1 мкс.
    Так что даже древнейший 80386 справится с задачей если его правильно запрограммировать.

    Если QNX не устраивает здесь список RTOS ( их несколько десятков !!!) и различная информация по теме.

    Ты с самого начала выбрал неправильное решение для своей задачи и пришёл к выводу что все ОС никуда не годятся. LPT, COM и USB мало подходят для подключения всяких внешних датчиков и ни MS ни создатели IBM PC в этом не виноваты. Есть спортивные автомобили и есть карьерные самосвалы.
  • Mario79 wrote: Не надо сливать кривую реализацию одной операционной системы на все остальные.
    Я не сваливаю (такое впечатление, что я на кого то наехал и обидел) я ПРИВОЖУ НАГЛЯДНЫЙ ПРИМЕР.
    Без примера, без рисунка, без... вообще можно ничего не понять, моё мнение. Разве что телепатические способности...
    Mario79 wrote: В Колибри такого нет, и надеюсь, не будет.
    То что я хочу изложить, как существенный недостаток синхронных обращений к портам, в Колибри есть и давно еще с менуета. Если надо далее могу приводить недостатки API INT 0x40 при работе по опросу портов. Но я считаю ЭТИ недостатки уже давно все знают и поэтому архитектурные предложения или хотябы мысли в эту сторону заинтересуют тех, кто чувствовал в системе(ах) эти моменты.
    Mario79 wrote: Я, например, написал опрос события нажатия кнопки выдвигания диска лишь при наличии блокировки привода и то 1 раз в секунду. Аппаратной реализации сообщения о событии в виде прерывания у ATAPI как выяснилось, нет. Но код абсолютно не нагружает систему, потому что написан настолько грамотно, насколько я смог разобраться. А Винда она и есть Винда...
    Опрос кнопки - слишком медленные события. Работа с датчиками, как SMBUS девайсы под Колибри - уже веселее будет, хотя скорости все равно не очень. Но глючики конкретные может и удастся подлавливать.
    Споры я разводить не буду и не хочу, т.к. моя КОНЕЧНАЯ ЦЕЛЬ конструктив.
  • Serge wrote: Блин! Опять ты городишь из мухи слона.
    Ну зачем же так наотмашь и категорично и не разобравшись? Может попытаемся понять друг друга?
    Serge wrote: 1. Роботами не управляют через LPT.
    Это аксиома для всего мира? А если надо и именно так. И чего люди придираются вместо того, чтобы "прочувствовать"?
    Не нравится тебе роботы... хорошо, пусть будет 8 дискретно управляемых дозаторов химической смеси.
    На каждый из 8 бит LPT порта 8 эл.ключиков, а они на клапан-дозатор. Управление количеством вешества
    широтно-импульсное пропорциональное, т.е. скважность битовой последовательности пропорциональна количеству вещества. Так легче стало? Думаю суть таже остаётся, равно как и проблемные таймеро-временные вещи ОС...
    Serge wrote: Для промышленных задач есть своё промышленное оборудование и системы. Ищи специализированные контроллеры.
    А еще лучше сразу все купить, готовое, промышленное, Канадское производство милитари исполнение... Денег где искать то?
    Serge wrote: 2. Почему ты решил что QNX и другие настоящие RTOS обеспечивают только десятки миллисекунд ? Надо читать документацию.
    Потому что эти вещи попадают в параметр (зависимость) которую обзывают как "время отклика".
    Serge wrote: Interrupt latency (т.е. время от наступления аппаратного прерывания до выполнения первой инструкции пользовательского обработчика) по данным QNX Software Systems составляет:
    А причём ТУТ аппаратного прерывания? Я разве ОБ ЭТОМ писал? Тогда см.выше еще раз сначала.
    Serge wrote: Если QNX не устраивает здесь список RTOS ( их несколько десятков !!!) и различная информация по теме.
    КПСВВ родился не вчера, спасибо конечно, я еще раз посмотрю, может чего и проглядел, но то, что я читывал ранее
    меня неустраивало (я не специалист по ВСЕМ ОСРВ и не стремлюсь им быть), т.к. повторюсь "время отклика" в рассмотрении архитектур попадало на пути прохождения данных для синхронных процедур ввода-вывода.
    И потом, мой путь ОТ ИДЕИ, а потом рассмотрение, анализ, обобщение... Идеей нужно делиться с массами, с целью быть услышанным :? , что и ПЫТАЮСЬ изложить.
    Serge wrote: Ты с самого начала выбрал неправильное решение для своей задачи и пришёл к выводу что все ОС никуда не годятся. LPT, COM и USB мало подходят для подключения всяких внешних датчиков и ни MS ни создатели IBM PC в этом не виноваты. Есть спортивные автомобили и есть карьерные самосвалы.
    Я с самого начала выбрал задачу, как пример, для того чтобы последовательно (опять же на примерах узких мест, эффектов...) придти к предложению механизма КПСВВ в ядре ОС, что позволит решать эти вещи на уровне или даже свыше возможностей существующих ОСРВ.
  • VaStaNi
    Ты привел пример с CD, вот я и ответил за реализацию поддерки ATAPI. Про все остальное я не утверждал.
  • VaStaNi
    Ты из букв Ж, О, П и А пытаешься составить слово ВЕЧНОСТЬ. По-моему Serge правильно сказал, что для каждой задачи есть свое оборудование и свои системы. А ты же себе поставил изначально противоречивое задание, ты пытаешься на архитектуре PC решить задачу, для которой она (архитектура) не проектировалась. Сколько велосипед не мучай - он не взлетит, он не для этого создавался.
    Да, необходимое для этого оборудование дорогостоящее, а что ты хотел? Это ж не спроста. Как в мире программирвания бытует мнение: мы можем ВСЕ!, но вот какие для этого необходимы ресурсы - это другой вопрос.
  • VaStaNi
    Не нравится тебе роботы...
    ...а еще лучше сразу все купить, готовое, промышленное,
    Канадское производство милитари исполнение... Денег где искать то?
    Шагающие роботы типа "Азимо" тоже вещь не дешёвая. Сенсоры, микроприводы... Против роботов я ничего не имею и пример хороший. Только не годится LPT для управления такой периферией. Этот древний Centronics вообще работал только на передачу данных пока не появились расширения ECP/EPP. Кстати второй пример с химическим дозатором очень напоминает струйный принтер, а с таким оборудованием у ОС проблем нет. Тем более что соплами-дозаторами управляет микроконтроллер принтера а CPU только раздаёт руководящие указания :)
    Вообще обычная персоналка расчитана на то, что к ней подключают в основном офисную периферию. А нестандартное оборудование часто подключается через свои карты расширения и управляется своими микропроцессорами.
    Потому что эти вещи попадают в параметр (зависимость) которую обзывают как "время отклика".
    Хорошо, для QNX и P166MHz максимальное время отклика составит 3.3мкс(interrupt latency) + 4.7мкс(sheduling latency если следовать рекомендациям QNX и разместить основной код вне обработчика прерывания) + время_исполнения_собственного_кода. В общем получаются десятки, может сотни микросекунд но не десятки миллисекунд. И это время всегда можно точно рассчитать почему системы и называются RTOS. Ну а если твой собственный код исполняется слишком медленно то в этом система не виновата.
  • Serge, считаю, что ты приводишь лишь часть СОВОКУПНОЙ задержки в данном случае QNX (хотя, позволю себе напомнить, разговор начинался совершенно не в планах её "обижать" или доказывать), упуская, при этом существенную лепту типа DELAY(xx) в системе. Задача, как пример наглядности, вернее её условие, говорит, что имеется СИНХРОННОЕ внешние событие, т.е. еще проще пример - это строго периодичесие импульсы ТИПА МЕАНДР, которые надо считывать. Далее, у нас на "них" прерывания нет! Т.е. фронты импульсов и каковы они положительные или отрицательные мы не знаем и реагировать на них АППАРАТНО(!) не можем... Что делает программист в таком случае? Делает циклический опрос порта (или запись если это требуется как выходное периодическое), затем DELAY(xx) и так в кольце. Ну я упускаю передачу и анализ значения, пусть оно будет просто "реактивно", т.к. узкое место не в нем.
    А вот DELAY(xx) в ОС - опирается, базируется, отсчитывается от элементарного кванта, тика системы и МЕНЬШЕ ЕГО (элементарного быть не может), стало быть если тик ОС, скажем 1 мс, то менее 1мс импульсы мы ПРОПУСКАЕМ, НЕ УЛАВЛИВАЕМ системой. Для QNX по DELAY(xx) и тикам и инфа по миллисекундным вещам читалась здесь
    http://qnx.org.ru/article11.html
    кто вообще интересуется РВ, рекомендую читануть.
    Так в чём моя "крамола"? :(
  • Who is online

    Users browsing this forum: No registered users and 5 guests