Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Вс авг 20, 2017 3:20 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 25 сообщений ]  На страницу 1 2 След.
Автор Сообщение
СообщениеДобавлено: Пт сен 14, 2007 12:03 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Всем кому интересно + стимуляция собственного анализа своих ядер и разбор их недостатков под этим углом зрения, рекомендую на "нейтральной" территории свою темку-статейку в виде собственных анализов, рассуждений и проектирования

http://www.xlevel.ru/forum/YaBB.cgi?board=is;action=display;num=1189758782;start=0 писал(а):
Гм, Гм... Всем кому не страшны такие матюки - привет!
Для начала пара-тройка вводных определений.
Итак, здесь, рубрика концепций ОС, значит ноу хау, как впрочем и хау ноу :mrgreen: обязаны быть здесь.
Тем, кому "ОСЖРВ", даже после расшифровки как Операционная Система Жёсткого Реального Времени ничего не говорит по существу - можно не тужиться и дальше не читать, кликать далее по просторам инета. Мне интересны/нужны собеседники "чувствующие на собственном опыте" необходимость и суть ЖРВ.
Итак, введение, так сазать :wink:.
КПСВВ... хе-х! Напоминает былое КПСС!? :mrgreen: - но это пожалуй только для тех, кто это знал, поэтому особо меня не умущает. Расшифровочка: Командный Процессор Синхронного Ввода-Вывода.
Долго "мутил" название и всеже остановочка на этом. Думаю меня поймут, конечно после ознакомления с сутью.
1. Я не отталкивался ни в теории ни в концепции ни тем более в практике от чего либо постулированного, стандартизованного, изученного мною или даже знакомого, поэтому ОСБОЗНАЮЩИХ в ОСРВ прошу сразу "макнуть носом" в доки и проинформировать меня об "изобретании велосипеда", если это так!
2. Хотелось бы слышать не повальную критику, а понимание сути и я бы сказал НЕОБХОДИМОСТИ этого КПСВВ, с точки зрения автора, как я её понимаю.
3. Наличие дельных вопросов и предложений.
Для начала скажу вещь буквально выстраданную. Железячные LowLevel проблемы и собственно программирование (об этом и речь далее) гораздо лучше знают люди хотябы частично знакомые с: радиоэлектроникой, циклограммами, осциллограммами, тактами, стробированием, защёлкиванием данных, затягиванием фронтов и их дребезгом... Все непонимающие эти тонкости обычно являются программистами высокого уровня (в плане архитектурных слоёв ПО и взвимодействия) и соответственно "летают" где-то высоко и, как правило, сразу скажут - а нафига, зачем?
Истоки проблем.
Не берусь сказать про ВСЕ ОСи на свете, глобально, но, как правило "железячникам" составляет массу хлопот состыковать многозадачную ОСь плохо ориентированную на СИНХРОННОЕ взаимодействие с периферийными устройствами и самое важное ДОСТИЧЬ ТРЕБУЕМОГО РЕЗУЛЬТАТА в виде четкой и НАДЁЖНОЙ работы этого стыка! Поясню на бытовом примере с бытовой ОС очень массового применения, которой сегодня де-факто является винда. Да и не только она, а и все ей подобные, по архитектурно-концептуальному построению попадают сюда, они ведь друг на друга смотрят и изучают. Соответственно и копируют недостатки друг друга :mrgreen: наследование однако! :roll:
Задачка для наглядности следующая.
Исходные условия: есть РС, винда, есть прога управления периферийным устройством, пусть через самый быстрый ВНЕШНИЙ порт РС - LPT, который прямым выходным кодом может осуществлять воздействие и осуществлять ответное чтение состояние железки. Ну и сама железка....., пусть это будет некий шаговый двигатель, как исполнительный механизм...э-э-э-э... Оооо! пусть это стабилизатора центра тяжести самодельного робота! Классно! Между прочим, масса энтуЗаЗистов во всём мире мается подобными творениями, устраивают соревнования, состязания... :shock:
А что? "Оглянитесь", да почитайте про тех, кто хотел подняться в небо! Сколько попыток, сколько заблуждений и неудач! А МЫ ТЕПЕРЬ вполне сносно летаем ведь! Вполне возможно и серьёзное роботостроение в недалеком будущем... Но ОС ЖРВ ему очччччень необходима! Уверен, УБЕЖДЁН! :wink:
Ага, дальше значит. Состояние железки. Пусть это некий позиционерный код. Типа угломер перемещения реального положения центра тяжести влево-вправо от идеальной стабилизационной точки "нашего" робота :). Итак, считаем, что постановка задачи есть и железка у нас чудесная, т.к. она при правильном, дозированном компенсационном воздействии шагового двигателя способна обеспечить равновесие агрегата, т.е. робота по существу. :wink: Обратная связь, как фактический замер отклонения(!) КОДОМ в "+" или "-" от устойчивого положения обеспечивается угломером, значения которого КАК МОЖНО БЫСТРЕЕ ДОЛЖНЫ попасть через порт LPT в нашу виндовую программу-стабилизатор. Да, вот еще что. Для полноты красок, сказу, что промедление компенсирующего воздействия свыше 1 мс - НЕДОПУСТИМО, т.к. грозит аварией, взрывом, техногенной катастрофой... :x :cry: что угодно себе для нагнеталова ответственности РЕШЕНИЯ этой комплексной задачи придумайте :mrgreen:
На мой взгляд, такой абсурдный пример вполне даже реален как по существу требований, так и по существу того или иного результата. Ну что, интересно что дальше? Продолжение следует, как говорится. Или будет следовать. :mrgreen:

Буду рад вашим веским аргументам и умным вопросам! Спасибо за внимание!


Последний раз редактировалось mike.dld Пт сен 14, 2007 12:47 pm, всего редактировалось 1 раз.
Перенёс мысли на этот форум - экономим трафик трудящимся ;)


Вернуться к началу
СообщениеДобавлено: Пт сен 14, 2007 1:00 pm 
По теории практически 100 % надежность (99,99999.... % ) обеспечивает 3-х контурная дублирующая система. Где 1 контур является работчим, 2 альтернативным, а 3 проверяет работу 1. Если произошел сбой 1, то перераспределяются. 2 включается, 3 альтернативным, 1 перезапуск и контроль 2. И так далее.
Вроде так если не запутался.
Соответсвенно должна быть трехпроцессорная модель, с тремя ядрами (главными циклами), для полной надежности.


Вернуться к началу
   
СообщениеДобавлено: Сб сен 15, 2007 5:23 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн мар 20, 2006 10:44 am
Сообщения: 557
VaStaNi
RTS (СРВ) делятся на HRT (жёстк. реальное время) и SRT (мягк. реальное время). Первая гарантирует появления результата в заданный интервал времени с вероятностью 1, вторая с заданной вероятностью (P<=1). Вот и всё!

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


Вернуться к началу
СообщениеДобавлено: Вс сен 16, 2007 10:49 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
Термины "жёсткое" и "мягкое" реальное время придумали в MS когда пытались пропихнуть NT в качестве RTOS. Разница в том, что в настоящей RTOS время отклика системы на событие можно рассчитать точно а в "мягкой" нет.


Вернуться к началу
СообщениеДобавлено: Вс сен 16, 2007 4:10 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн мар 20, 2006 10:44 am
Сообщения: 557
По поводу MS с NT не соглашусь, а остальное как я и говорил.


Вернуться к началу
СообщениеДобавлено: Пн сен 17, 2007 12:10 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Ну раз модеры считают, что тут излагать полные объемы статей на нескольких листах, норма, то бомблю
тут ЧАСТЬ 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:


Вернуться к началу
СообщениеДобавлено: Пн сен 17, 2007 12:28 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Спасибо, за посты, но впечатление, что все из нас думают несколько разно и о своем... Это нормально. Каждый человек располагает и пользуется в общении своими заниями, опытом, лекциями преподавателей, авторитетным окружением... Надеюсь представления некоторых изменятся или УТОЧНЯТСЯ после 2 части, дабы далее можно было говорить на одну тему. Возможно и то, что только 3я часть расставит точки над "i". Во всяком случае мне интересно какова аудитория у меня и насколько доходчив материал... Известно, что VaStaNi пытаясь донести все слишком подробно и исключить лишние вопросы этим добывается подчас обратного :( Может есть положительные впечатления? Весьма любопытно.


Вернуться к началу
СообщениеДобавлено: Пн сен 17, 2007 12:47 pm 
VaStaNi
Цитата:
Получается так, что если простой/ожидание часами, сутками, то расход максимален, а если, скажем, чуть чуть тормознула ОС... ну винда «морозится», скажем когда пустой CD вставляешь или вообще он "битый", ну тогда неприятно, но потерпеть дескать можно, ну отвернуться можно и переключить внимание на что либо,
чтобы не тошнило в очередной раз от этого...

Не надо сливать кривую реализацию одной операционной системы на все остальные.
В Колибри такого нет, и надеюсь, не будет. Я, например, написал опрос события нажатия кнопки выдвигания диска лишь при наличии блокировки привода и то 1 раз в секунду. Аппаратной реализации сообщения о событии в виде прерывания у ATAPI как выяснилось, нет. Но код абсолютно не нагружает систему, потому что написан настолько грамотно, насколько я смог разобраться. А Винда она и есть Винда...


Вернуться к началу
   
СообщениеДобавлено: Пн сен 17, 2007 4:23 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
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 в этом не виноваты. Есть спортивные автомобили и есть карьерные самосвалы.


Вернуться к началу
СообщениеДобавлено: Пн сен 17, 2007 6:42 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Mario79 писал(а):
Не надо сливать кривую реализацию одной операционной системы на все остальные.

Я не сваливаю (такое впечатление, что я на кого то наехал и обидел) я ПРИВОЖУ НАГЛЯДНЫЙ ПРИМЕР.
Без примера, без рисунка, без... вообще можно ничего не понять, моё мнение. Разве что телепатические способности...
Mario79 писал(а):
В Колибри такого нет, и надеюсь, не будет.

То что я хочу изложить, как существенный недостаток синхронных обращений к портам, в Колибри есть и давно еще с менуета. Если надо далее могу приводить недостатки API INT 0x40 при работе по опросу портов. Но я считаю ЭТИ недостатки уже давно все знают и поэтому архитектурные предложения или хотябы мысли в эту сторону заинтересуют тех, кто чувствовал в системе(ах) эти моменты.
Mario79 писал(а):
Я, например, написал опрос события нажатия кнопки выдвигания диска лишь при наличии блокировки привода и то 1 раз в секунду. Аппаратной реализации сообщения о событии в виде прерывания у ATAPI как выяснилось, нет. Но код абсолютно не нагружает систему, потому что написан настолько грамотно, насколько я смог разобраться. А Винда она и есть Винда...

Опрос кнопки - слишком медленные события. Работа с датчиками, как SMBUS девайсы под Колибри - уже веселее будет, хотя скорости все равно не очень. Но глючики конкретные может и удастся подлавливать.
Споры я разводить не буду и не хочу, т.к. моя КОНЕЧНАЯ ЦЕЛЬ конструктив.


Вернуться к началу
СообщениеДобавлено: Пн сен 17, 2007 7:07 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Serge писал(а):
Блин! Опять ты городишь из мухи слона.

Ну зачем же так наотмашь и категорично и не разобравшись? Может попытаемся понять друг друга?
Serge писал(а):
1. Роботами не управляют через LPT.

Это аксиома для всего мира? А если надо и именно так. И чего люди придираются вместо того, чтобы "прочувствовать"?
Не нравится тебе роботы... хорошо, пусть будет 8 дискретно управляемых дозаторов химической смеси.
На каждый из 8 бит LPT порта 8 эл.ключиков, а они на клапан-дозатор. Управление количеством вешества
широтно-импульсное пропорциональное, т.е. скважность битовой последовательности пропорциональна количеству вещества. Так легче стало? Думаю суть таже остаётся, равно как и проблемные таймеро-временные вещи ОС...
Serge писал(а):
Для промышленных задач есть своё промышленное оборудование и системы. Ищи специализированные контроллеры.

А еще лучше сразу все купить, готовое, промышленное, Канадское производство милитари исполнение... Денег где искать то?
Serge писал(а):
2. Почему ты решил что QNX и другие настоящие RTOS обеспечивают только десятки миллисекунд ? Надо читать документацию.

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

А причём ТУТ аппаратного прерывания? Я разве ОБ ЭТОМ писал? Тогда см.выше еще раз сначала.

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

КПСВВ родился не вчера, спасибо конечно, я еще раз посмотрю, может чего и проглядел, но то, что я читывал ранее
меня неустраивало (я не специалист по ВСЕМ ОСРВ и не стремлюсь им быть), т.к. повторюсь "время отклика" в рассмотрении архитектур попадало на пути прохождения данных для синхронных процедур ввода-вывода.
И потом, мой путь ОТ ИДЕИ, а потом рассмотрение, анализ, обобщение... Идеей нужно делиться с массами, с целью быть услышанным :? , что и ПЫТАЮСЬ изложить.
Serge писал(а):
Ты с самого начала выбрал неправильное решение для своей задачи и пришёл к выводу что все ОС никуда не годятся. LPT, COM и USB мало подходят для подключения всяких внешних датчиков и ни MS ни создатели IBM PC в этом не виноваты. Есть спортивные автомобили и есть карьерные самосвалы.

Я с самого начала выбрал задачу, как пример, для того чтобы последовательно (опять же на примерах узких мест, эффектов...) придти к предложению механизма КПСВВ в ядре ОС, что позволит решать эти вещи на уровне или даже свыше возможностей существующих ОСРВ.


Вернуться к началу
СообщениеДобавлено: Пн сен 17, 2007 7:30 pm 
VaStaNi
Ты привел пример с CD, вот я и ответил за реализацию поддерки ATAPI. Про все остальное я не утверждал.


Вернуться к началу
   
СообщениеДобавлено: Пн сен 17, 2007 8:30 pm 
Не в сети

Зарегистрирован: Ср фев 21, 2007 3:03 pm
Сообщения: 188
VaStaNi
Ты из букв Ж, О, П и А пытаешься составить слово ВЕЧНОСТЬ. По-моему Serge правильно сказал, что для каждой задачи есть свое оборудование и свои системы. А ты же себе поставил изначально противоречивое задание, ты пытаешься на архитектуре PC решить задачу, для которой она (архитектура) не проектировалась. Сколько велосипед не мучай - он не взлетит, он не для этого создавался.
Да, необходимое для этого оборудование дорогостоящее, а что ты хотел? Это ж не спроста. Как в мире программирвания бытует мнение: мы можем ВСЕ!, но вот какие для этого необходимы ресурсы - это другой вопрос.


Вернуться к началу
СообщениеДобавлено: Вт сен 18, 2007 1:16 pm 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
VaStaNi

Цитата:
Не нравится тебе роботы...
...а еще лучше сразу все купить, готовое, промышленное,
Канадское производство милитари исполнение... Денег где искать то?
Шагающие роботы типа "Азимо" тоже вещь не дешёвая. Сенсоры, микроприводы... Против роботов я ничего не имею и пример хороший. Только не годится LPT для управления такой периферией. Этот древний Centronics вообще работал только на передачу данных пока не появились расширения ECP/EPP. Кстати второй пример с химическим дозатором очень напоминает струйный принтер, а с таким оборудованием у ОС проблем нет. Тем более что соплами-дозаторами управляет микроконтроллер принтера а CPU только раздаёт руководящие указания :)
Вообще обычная персоналка расчитана на то, что к ней подключают в основном офисную периферию. А нестандартное оборудование часто подключается через свои карты расширения и управляется своими микропроцессорами.

Цитата:
Потому что эти вещи попадают в параметр (зависимость) которую обзывают как "время отклика".
Хорошо, для QNX и P166MHz максимальное время отклика составит 3.3мкс(interrupt latency) + 4.7мкс(sheduling latency если следовать рекомендациям QNX и разместить основной код вне обработчика прерывания) + время_исполнения_собственного_кода. В общем получаются десятки, может сотни микросекунд но не десятки миллисекунд. И это время всегда можно точно рассчитать почему системы и называются RTOS. Ну а если твой собственный код исполняется слишком медленно то в этом система не виновата.


Вернуться к началу
СообщениеДобавлено: Ср сен 19, 2007 6:13 pm 
Не в сети
Just Flooding
Аватара пользователя

Зарегистрирован: Ср май 18, 2005 10:27 am
Сообщения: 430
Serge, считаю, что ты приводишь лишь часть СОВОКУПНОЙ задержки в данном случае QNX (хотя, позволю себе напомнить, разговор начинался совершенно не в планах её "обижать" или доказывать), упуская, при этом существенную лепту типа DELAY(xx) в системе. Задача, как пример наглядности, вернее её условие, говорит, что имеется СИНХРОННОЕ внешние событие, т.е. еще проще пример - это строго периодичесие импульсы ТИПА МЕАНДР, которые надо считывать. Далее, у нас на "них" прерывания нет! Т.е. фронты импульсов и каковы они положительные или отрицательные мы не знаем и реагировать на них АППАРАТНО(!) не можем... Что делает программист в таком случае? Делает циклический опрос порта (или запись если это требуется как выходное периодическое), затем DELAY(xx) и так в кольце. Ну я упускаю передачу и анализ значения, пусть оно будет просто "реактивно", т.к. узкое место не в нем.
А вот DELAY(xx) в ОС - опирается, базируется, отсчитывается от элементарного кванта, тика системы и МЕНЬШЕ ЕГО (элементарного быть не может), стало быть если тик ОС, скажем 1 мс, то менее 1мс импульсы мы ПРОПУСКАЕМ, НЕ УЛАВЛИВАЕМ системой. Для QNX по DELAY(xx) и тикам и инфа по миллисекундным вещам читалась здесь
http://qnx.org.ru/article11.html
кто вообще интересуется РВ, рекомендую читануть.
Так в чём моя "крамола"? :(


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 25 сообщений ]  На страницу 1 2 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB