Board.KolibriOS.org

VaStaNi

Задача, как пример наглядности, вернее её условие, говорит, что имеется СИНХРОННОЕ внешние событие, т.е. еще проще пример - это строго периодичесие импульсы ТИПА МЕАНДР, которые надо считывать. Далее, у нас на "них" прерывания нет! Т.е. фронты импульсов и каковы они положительные или отрицательные мы не знаем и реагировать на них АППАРАТНО(!) не можем... Что делает программист в таком случае? Делает циклический опрос порта (или запись если это требуется как выходное периодическое), затем DELAY(xx) и так в кольце

Значит в данном случае делаешь поток с высоким приоритетом и тупо опрашиваешь порт в цикле без всякого DELAY(xx). Да это грузит систему, но если не хочешь или не можешь использовать прерывания, единственное надёжное решение. Кстати таким образом работает delay_ms в Колибри. Миллисекунды отсчитваются опросом порта 0х61. Собственно всё это только подтверждает мой первый пост. Аппаратные средства должны соответствовать задаче. Не любишь прерывания - грей процессор.

VaStaNi
Советую внимательно перечиать написаное тобой, задачу ставиш не реальную, не стоит ожидать от домашнего ПК каких то чудес. А QNX умеет крутится не только на x86.

VaStaNi

В последнем примере лучше подключить генератор импульсов к управляющим линиям СОМ-порта. Тот выдаёт прерывание когда их состояние меняется. Это решит большинство проблем.

Ghost wrote: Советую внимательно перечиать написаное тобой, задачу ставиш не реальную, не стоит ожидать от домашнего ПК каких то чудес. А QNX умеет крутится не только на x86.

Это никакие не чудеса. Домашний ПК способен эту задачу и с аппаратной стороны и с со стороны ПО - возми ДОС и реши. Все реально. А причем тут "крутится не только на x86"? По моему меня не понимают или любое высказывание воспринивается под неким своим углом зрения и шаблонированно. Повторюсь, я иду от идеи, опираясь на реальные вещи...

Serge wrote: Значит в данном случае делаешь поток с высоким приоритетом и тупо опрашиваешь порт в цикле без всякого DELAY(xx).
Да это грузит систему, но если не хочешь или не можешь использовать прерывания, единственное надёжное решение. Кстати таким образом работает delay_ms в Колибри. Миллисекунды отсчитваются опросом порта 0х61. Собственно всё это только подтверждает мой первый пост. Аппаратные средства должны соответствовать задаче. Не любишь прерывания - грей процессор.

DELAY то останется! Вернее не сам DELAY как оператор, а фактическое время между IN AL,DX обращениями к порту, например, "от лица системы" по отношению к внешнему девайсу, сигналу, событиям... которые в реальном времени происходят. Поток, особенно в архитектурах НЕ ОСРВ(!) НЕ ЖИВЁТ "равномерной жизнью", т.к. приоритеты и их ротация, вытеснение, сам планировщик и т.д. и т.п.... А вот аппаратные средства тут ни причем DOS позволяет это решить НА ЭТИХ АППАРАТНЫХ СРЕДСТВАХ и опять же я об этом выше писал.
Вот мы и подходим, я надеюсь, к самому главному можно ли изменить/разработать/улучшить архитектуру ОС, ядра создаваемой или другой самописной ОС, чтобы данные вещи были на уровне ОСРВ? Как это возможно и где узкое место архитектуры? Сколько плюсов и минусы какие будут? Ну скажем так, далее я подумаю, как излагать часть 3, а то впечатление, что альтернативы и революции никому не интересны ДАЖЕ на уровне расуждений и двустороннего понимания Вообще, хоть одному человеку ЭТО ТУТ НАДО? Может я зря сюда забрёл недавно, зря тут трачу время и своё и другим голову морочу + мараю форум своим бредом?
Хоть один заинтересованный в продолжении ТУТ имеется?

VaStaNi

Вообще, хоть одному человеку ЭТО ТУТ НАДО? Может я зря сюда забрёл недавно, зря тут трачу время и своё и другим голову морочу + мараю форум своим бредом?
Хоть один заинтересованный в продолжении ТУТ имеется?

При всем моем уважении к тебе (а количество уважаемых мной челов имеет весьма не большое и конечное значение), но твое сумбурное изложение идей путает большую часть людей.
Изложи четко: задача, проблемы, методы решения и лишь тогда будет виден реальный интерес.
На том форуме, на котором ты запостил свой пост изначально вообще только один человек ответил по теме, а здесь сам видишь - делай выводы.

VaStaNi
Да какие проблемы ?
Берёшь двухядерную конфигурацию. На одном ядре в режиме опроса пашет один поток с максимально возможным приоритетом. Он никогда не вытесняется. На другом ядре работают остальные потоки ОС. Всё это достигается соответствующей установкой алгоритмов планирования. Мало двух ядер - берём четыре. Интел уже экспериментирует с восьмидесятиядерными чипами.

Ты с самого начала ничтоже сумняшеси заявил что большинство RTOS с твоей проблемой не справятся. Я совершенно не понимаю на основании каких фактов ты делаешь такие выводы. Есть десятки RTOS для самых различных архитектур и задач. Если не подходит одна можно найти другую.

Mario79 wrote:но твое сумбурное изложение идей путает большую часть людей.

Пугает.

Ну что тут сказать, перефирия PC, архи тормозная. Один in/out в LPT, убьет несколько тысяч тактов, относительно не дохлово проца, типа пня3/4.

Так что мультизадачность, да и оповещение ring3 прог всеми микросекундными тиками, будет довольно глюкавым занятием, если прога сама как не ОС под темже DOS, или дровина/kernel dll в винде, обрабатывающая все поступающие сигналы самостоятельно. И здесь тож на одном LPT свет клином не сошелся, можно, снимать синхроимпульсы с NMI входа CPU, чутли не под под мегагерц и вместо LPT юзать IDE (доводилось да и доводиться иной раз это юзать, в радиотехнических разборках), так что при желании PC-юк можно пользовать не тока как "карьерный белаз", а как синтезатор частот, цифровой анализатор, DSP процессор (по обработки SDR или там синтезе гитарных примочек без задержек), то бишь в тех применениях где обычные контроллеры, сильно сливают "упакованым по полной" х86.

Фигли роботы какието, нехватало еще ИИ им мутить, имхо этой тяжкой и неблагодарной рутиной, заняты разве что 3D гейм девелоперы...

По поводу IDE, на самом деле спектрометр самодельный в нашей лаборатории как раз через него работает. Поскольку LPT/COM слишком тормозной, а в usb долго разбираться.

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