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