Механизмы реального времени

Параметры

· Время реакции системы

Почти все производители систем реального времени приводят такой параметр, как время реакции системы на прерывание (interrupt latency).

В самом деле, если главным для системы реального времени является ее способнось вовремя отреагировать на внешние события, то такой параметр, как время реакции системы является ключевым. Однако, что это за время и как к нему относиться?

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

Как быть в этой ситуации?

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

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

Интервал времени - от события на объекте и до выполнения первой инструкции в программе обработки этого события и является временем реакции системы на события, и, проектируя систему реального времени, разработчики должны уметь вычислять этот интервал. Из чего от складывается?

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

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

· Время переключения контекста

В операционные системы реального времени заложен параллелизм, возможность одновременной обработки нескольких событий, поэтому все операционные системы реального времени являются многозадачными (многопроцессными, многонитиевыми). Для того, чтобы уметь оценивать накладные расходы системы при обработке параллельных событий, необходимо знать время, которое система затрачивает на передачу управления от процесса к процессу (от задачи к задаче, от нити к нити), то есть время переключения контекста (Рис.2).

· Размеры системы

Для систем реального времени важным параметром является размер системы исполнения, а именно суммарный размер минимально необходимого для работы приложения системного набора (ядро, системные модули, драйверы и т. д.). Хотя, надо признать, что с течением времени значение этого параметра уменьшается, тем не менее он остается важным и производители систем реального времени стремятся к тому, чтобы размеры ядра и обслуживающих модулей системы были невелики.

Примеры: размер ядра операционной системы реального времени OS-9 на микропроцессорах МС68xxx - 22 KB, VxWorks - 16 KB.

· Возможность исполнения системы из ПЗУ (ROM)

Это свойство операционных систем реального времени - одно из базовых. Оно позволяет создавать компактные встроенные СРВ повышенной надёжности, с ограниченным энергопотреблением, без внешних накопителей.

Важным параметром при оценке операционных систем реального времени является набор инструментов, механизмов реального времени, предоставяемых системой. Об этом - следующая глава.

 

Механизмы реального времени

Процесс проектирования конкретной системы реального времени начинается с тщательного изучения объекта. Разработчики проекта исследуют объект, изучают возможные события на нем, определяют критические сроки реакции системы на каждое событие и разрабатывают алгоритмы обработки этих событий. Затем следует процесс проектирования и разработки программных приложений.

Мечтой каждого разработчика является идеальная операционная система реального времени, в которой приложения реального времени разрабатываются на языке событий объекта. Такая система имеет свое название, хотя и существует только в теории. Называется она: "система, управляемая критическими сроками". Разработка приложений реального времени в этой системе сводится к описанию возможных событий на объекте. В каждом описателе события указыватся два параметра: временной интервал - критическое время обслуживания данного события и адрес подпрограммы его обработки. Всю дальнейшую заботу о том, чтобы подпрограмма обработки события стартовала до истечения критического интервала времени берет на себя операционная система.

Но это - мечта. В реальности же разработчик должен перевести язык событий объекта в сценарий многозадачной работы приложений операционных систем реального времени, стараясь оптимательно использовать предоставленные ему специальные механизмы и оценить времена реакций системы на внешние события при этом сценарии.

Какие же механизмы в операционных системах реального времени делают систему реального времени (СРВ) предсказуемой?

· Система приоритетов и алгоритмы диспетчеризации

Базовыми инструментами разработки сценария работы системы являются система приоритетов процессов (задач) и алгоритмы планирования (диспетчеризации) операционных системах реального времени.

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

Алгоритмы круговой диспетчеризации неприменимы в чистом виде в операционных системах реального времени. Основной недостаток - непрерывный квант времени, в течение которого процессором владеет только один процесс. Планировщики же операционных систем реального времени имеют возможность сменить процесс до истечения "time slice", если в этом возникла необходимость. Один из возможных алгоритмов планирования при этом "приоритетный с вытеснением". Мир операционных систем реального времени отличается богатством различных алгоритмов планирования: динамические, приоритетные, монотонные, адаптивные и пр., цель же всегда преследуется одна - предоставить инструмент, позволяющий в нужный момент времени исполнять именно тот процесс, который необходим.

· Механизмы межзадачного взаимодействия

Другой набор механизмов реального времени относится к средствам синхронизации процессов и передачи данных между ними. Для операционных систем реального времени характерна развитость этих механизмов. К таким механизмам относятся: семафоры, мьютексы, события, сигналы, средства для работы с разделяемой памятью, каналы данных (pipes), очереди сообщений. Многие из подобных механизмов используются и в ОС общего назначения, но их реализация в операционных системах реального времени имеет свои особенности - время исполнения системных вызовов почти не зависит от состояния системы, и в каждой операционной системе реального времени есть по крайней мере один быстрый механизм передачи данных от процесса к процессу.

· Средства для работы с таймерами

Такие инструменты, как средства работы с таймерами, необходимы для систем с жестким временным регламентом, поэтому развитость средств работы с таймерами - необходимый атрибут операционных систем реального времени. Эти средства, как правило, позволяют:

- измерять и задавать различные промежутки времени (от 1 мкс и выше),

- генерировать прерывания по истечении временных интервалов,

- создавать разовые и циклические будильники

 

 

2. Базовые концепции построения операционных систем реального времени

При описании операционной системы часто указываются особенности ее структурной организации и основные концепции, положенные в ее осно­ву.

К базовым концепциям относятся:

Способы построения ядра системы - монолитное ядро или микро­ядерный подход. Большинство ОС использует монолитное ядро, которое компонуется как одна программа, работающая в привилегированном режиме и использующая быстрые переходы с одной процедуры на другую, не тре­бующие переключения из привилегированного режима в пользовательский, и наоборот. Альтернативой является построение ОС на базе микроядра, ра­ботающего также в привилегированном режиме и выполняющего только минимум функций по управлению аппаратурой, в то время как функции ОС бо­лее высокого уровня выполняют специализированные компоненты ОС - сер­веры, работающие в пользовательском режиме. При таком построении ОС работает более медленно, так как часто выполняются переходы между при­вилегированным режимом и пользовательским, но система получается более гибкой - ее функции можно наращивать, модифицировать или сужать, до­бавляя, модифицируя или исключая серверы пользовательского режима. Кроме того, серверы хорошо защищены друг от друга, как и любые пользо­вательские процессы.

Построение ОС на базе объектно-ориентированного подхода дает воз­можность использовать все его достоинства, хорошо зарекомендовавшие се­бя на уровне приложений, внутри операционной системы. Ее основными достоинствами являются: аккумуляция удачных решений в форме стандарт­ных объектов; возможность создания новых объектов на базе имеющихся, с помощью механизма наследования; хорошая защита данных за счет их ин­капсуляции во внутренние структуры объекта, что делает данные недоступ­ными для несанкционированного использования извне; структурированность системы, состоящей из набора хорошо определенных объектов.

Наличие нескольких прикладных сред дает возможность в рамках од­ной ОС одновременно выполнять приложения, разработанные для несколь­ких ОС. Многие современные операционные системы поддерживают одно­временно прикладные среды MS-DOS, Windows, UNIX (POSIX), OS/2 или хотя бы некоторого подмножества из этого популярного набора. Концепция множественных прикладных сред наиболее просто реализуется в ОС на базе микроядра, над которым работают различные серверы, часть которых реали­зуют прикладную среду той или иной операционной системы.

Распределенная организация операционной системы позволяет упро­стить работу пользователей и программистов в сетевых средах. В распределенной ОС реализованы механизмы, которые дают возможность пользовате­лю представлять и воспринимать сеть в виде традиционного однопроцессор­ного компьютера. Характерными признаками распределенной организации ОС являются:

наличие единой справочной службы разделяемых ресурсов;

единой службы времени;

использование механизма вызова удаленных процедур (RPC) для про­зрачного распределения программных процедур по машинам;

многонитевой обработки, позволяющей распараллеливать вычисления в рамках одной задачи и выполнять эту задачу сразу на нескольких компью­терах сети;

наличие других распределенных служб.

 

3. Монолитная архитектура

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

Для построения монолитной системы необходимо скомпилировать все отдельные процедуры, а затем связать их в единый объектный файл с помо­щью компоновщика. Здесь, по существу, полностью отсутствует сокрытие деталей реализации - каждая процедура видит любую другую процедуру (в отличие от структуры, содержащей модули, в которой большая часть ин­формации является локальной для модуля и процедуры модуля можно вы­звать только через специально определенные точки входа).

Однако даже такие монолитные системы могут иметь некоторую структуру. При обращении к системным вызовам, поддерживаемым операци­онной системой, параметры помещаются в строго определенные места - ре­гистры или стек, после чего выполняется специальная команда прерыва­ния, известная как вызов ядра или вызов супервизора. Эта команда пере­ключает машину из режима пользователя в режим ядра и передает управле­ние операционной системе. Затем операционная система проверяет пара­метры вызова, чтобы определить, какой системный вызов должен быть вы­полнен. После этого операционная система обращается к таблице как к мас­сиву с номером системного вызова в качестве индекса. В k-м элементе таб­лицы содержится ссылка на процедуру обработки системного вызова. Такая организация операционной системы предполагает следующую структуру:

1. Главная программа, которая вызывает требуемую служебную проце­дуру.

2. Набор служебных процедур, выполняющих системные вызовы.

3. Набор утилит, обслуживающих служебные процедуры. В этой модели для каждого системного вызова имеется одна служебная процедура. Утилиты выполняют функции, которые нужны нескольким слу­жебным процедурам. Деление процедур на три уровня показано на рис. 1.

Рисунок 1. – Модель монолитной системы

 

В силу преимуществ объектно-ориентированного подхода приложения создаются на его основе, используя один из языков программирования, наилучшим образом поддерживающий этот подход. Архитектуры же классиче­ских операционных систем реального времени основаны на архитектурах UNIX систем и используют традиционный процедурный подход к програм­мированию. Сочетание объектно-ориентированных приложений и проце­дурных операционных систем имеет ряд недостатков:

1. Происходит разрыв парадигмы программирования: в едином рабо­тающем комплексе (приложение + ОСРВ) разные компоненты используют разные подходы к разработке программного обеспечения.

2. Не используются все возможности объектно-ориентированного под­хода.

3. Возникают некоторые потери производительности из-за разного ти­па интерфейсов в ОСРВ и приложении.

Естественно, возникает идея строить саму СРВ, используя объектно-ориентированный подход. При этом:

- как приложение, так и операционная система полностью объектно-ориентированны и используют все преимущества этого подхода;

- приложение и ОСРВ могут быть полностью интегрированы, посколь­ку используют один объектно-ориентированный язык программирования;

- обеспечивается согласование интерфейсов ОСРВ и приложения;

- приложение может «моделировать» ОСРВ для своих потребностей, заказывая нужные ему объекты;

- единый комплекс (приложение + ОСРВ) является модульным и легко модернизируемым. Идея реализована в ОСРВ SoftKernel, целиком написан­ной на C++. ОСРВ с монолитной архитектурой можно представить в виде:

- прикладного уровня: состоящего из работающих прикладных процес­сов;

- системного уровня: состоящего из монолитного ядра операционной системы, в котором можно выделить следующие части:

а) интерфейс между приложениями и ядром (API);

б) собственно ядро системы;

в) интерфейс между ядром и оборудованием (драйверы устройств). API в таких системах играет двойную роль:

1) управляет взаимодействием прикладных процессов и системы;

2) обеспечивает непрерывность выполнения кода системы (отсутствие переключения задач во время исполнения кода системы).

Основным преимуществом монолитной архитектуры является ее отно­сительная быстрота работы по сравнению с другими архитектурами. Однако, достигается это, в основном, за счет написания значительных частей систе­мы на ассемблере.

Недостатки монолитной архитектуры:

1. Системные вызовы, требующие переключения уровней привилегий (от пользовательской задачи к ядру), должны быть реализованы как преры­вания или ловушки (специальный тип исключений). Это значительно увеличивает время их работы.

2. Ядро не может быть прервано пользовательской задачей. Это может приводить к тому, что высокоприоритетная задача может не получить управ­ления из-за работы низкоприоритетной задачи. Например, низкоприоритет­ная задача запросила выделение памяти, сделала системный вызов, до окон­чания которого сигнал активизации высокоприоритетной задачи не сможет ее активизировать.

3. Сложность переноса на новые архитектуры процессора из-за значи­тельных ассемблерных вставок.

4. Негибкость и сложность развития: изменение части ядра системы требует его полной перекомпиляции.

 

4. Модульная архитектура на основе микроядра

Модульная архитектура появилась, как попытка убрать узкое место API и облегчить модернизацию системы и перенос ее на новые процессоры.

API в модульной архитектуре играет только одну роль: обеспечивает связь прикладных процессов и специального модуля менеджера процессов. Однако теперь микроядро играет двойную роль:

1) управление взаимодействием частей системы (например, менедже­ров процессов и файлов);

2) обеспечение непрерывности выполнения кода системы (отсутствие переключения задач во время исполнения микроядра).

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

 

5. Объектная архитектура на основе объектов-микроядер

В этой архитектуре (используемой в ОСРВ SoftKernel) API отсутствует вообще. Взаимодействие между компонентами системы (микроядрами) и пользовательскими процессами осуществляется посредством обычного вы­зова функций, поскольку и система, и приложения написаны на одном языке (C++). Это обеспечивает максимальную скорость системных вызовов.

Фактическое равноправие всех компонент системы обеспечивает воз­можность переключения задач в любое время, то есть система полностью управляема.

Объектно-ориентированный подход обеспечивает модульность, безо­пасность, легкость модернизации и повторного использования кода.

Роль API играет компилятор и динамический редактор объектных свя­зей (linker). При старте приложения динамический linker загружает нужные ему микроядра (в отличие от предыдущих систем, не все компоненты самой операционной системы должны быть загружены в оперативную память). Ес­ли микроядро уже загружено для другого приложения, то оно повторно не загружается, а используется код и данные уже имеющегося микроядра. Это позволяет сократить объем требуемой памяти.

Поскольку разные приложения разделяют одни микроядра, то они должны работать в одном адресном пространстве. Следовательно, система не может использовать виртуальную память и тем самым работает быстрее (так как исключаются задержки на трансляцию виртуального адреса в физиче­ский).

Поскольку все приложения и сами микроядра работают в одном адрес­ном пространстве, то они загружаются в память, начиная с неизвестного на момент компиляции адреса. Следовательно, приложения и микроядра не должны зависеть от начального адреса (как по коду, так и по данным). Это свойство автоматически обеспечивает возможность записи приложений и модулей в ПЗУ, с последующим их исполнением, как в самом ПЗУ, так и в оперативной памяти.

Микроядра по своим характеристикам напоминают структуры, исполь­зуемые в других операционных системах, однако есть и свои различия.

Микроядра и модули. Многие ОС поддерживают динамическую за­грузку компонент системы, называемых модулями. Однако модули не под­держивают объектно-ориентированный подход ввиду того, что микроядро является фактически представителем некоторого класса. Далее, обмен ин­формацией с модулями происходит посредством системных вызовов, что достаточно дорого.

Микроядра и драйверы. Многие ОС поддерживают возможность сво­его расширения посредством драйверов (специальных модулей, обычно слу­жащих для поддержки оборудования). Однако драйверы часто должны быть статически связаны с ядром (образовывать с ним связанный загрузочный об­раз еще до загрузки) и должны работать в привилегированном режиме. Как и модули, они не поддерживают объектно-ориентированный подход и доступ­ны приложениям только посредством системных вызовов.

Микроядра и DLL (Dynamically Linked Libraries, динамически связы­ваемые библиотеки). Многие системы оформляют библиотеки, из которых берутся функции при динамическом связывании, в виде специальных моду­лей, называемых DLL. DLL обеспечивает разделение своего кода и данных для всех работающих приложений, в то время, как для микроядер можно управлять доступом для каждого конкретного приложения. DLL не поддер­живает объектно-ориентированный подход, код DLL не является позиционно-независимым, и потому не может быть записан в ПЗУ.

 

6. Интерфейсы вс

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

выдача и прием информации;

управление передачей данных;

согласование источника и приемника информации.

 

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

 

Для интерфейсов, обеспечивающих соединение "точка-точка" (в отличие от шинных интерфейсов), возможны следующие реализации режимов обмена: дуплексный, полудуплексный и симплексный. К дуплексным относят интерфейсы, обеспечивающие возможность одновременной передачи данных между двумя устройствами в обоих направлениях. В случае, когда канал связи между устройствами поддерживает двунаправленный обмен, но в каждый момент времени передача информации может производиться только в одном направлении, режим обмена называется полудуплексным. Важной характеристикой полудуплексного соединения является время реверсирования режима - то время, за которое производится переход от передачи сообщения к приему и наоборот. Если же интерфейс реализует передачу данных только в одном направлении и движение потока данных в противоположном направлении невозможно, такой интерфейс называют симплексным.

 

Важное значение имеют также следующие технические характеристики интерфейсов:

вместимость (максимально возможное количество абонентов, одновременно подключаемых к контроллеру интерфейса без расширителей);

пропускная способность или скорость передачи (длительность выполнения операций установления и разъединения связи и степень совмещения процессов передачи данных);

максимальная длина линии связи;

разрядность;

топология соединения.

 

7. Принципы функционирования интерфейса

Существует несколько методов реализации интерфейса АЦП – процес­сор ПК.

Схема “самых последних данных”. В этом методе реализации интер­фейса АЦП работает непрерывно. В конце каждого цикла преобразования он обновляет данные в выходном буферном регистре и затем автоматически на­чинает новый цикл преобразования. Микропроцессор просто считывает со­держимое этого буфера, когда ему нужны самые последние данные. Этот ме­тод подходит для тех применений, где необходимость в обновлении данных возникает лишь от случая к случаю.

Схема “запуска-ожидания”. Микропроцессор инициирует выполнение преобразования каждый раз, когда ему нужны новые данные, и затем непре-

рывно тестирует состояние АЦП, чтобы узнать, закончилось ли преобразова­ние. Зафиксировав конец преобразования, он считывает выходное слово пре­образователя. В возможной модификации этого метода микропроцессор на­ходится в состоянии ожидания в течение интервала времени, превышающего предполагаемое время преобразования, и затем считывает выходные данные. Этот метод несколько проще в реализации, но при этом микропроцессор от­влекается от выполнения всех других программ на время преобразования.

Использование прерывания микропроцессора. Этот метод основан на возможности использования системы прерываний микропроцессора. Как и в предыдущей схеме, процессор или таймер запускают преобразователь, но за­тем микропроцессор может продолжать выполнение других заданий. Когда преобразование завершено, АЦП вызывает прерывание микропроцессора. Микропроцессор прекращает выполнение текущей программы и сохраняет всю необходимую информацию для последующего восстановления этой про­граммы. Затем он осуществляет поиск и использование ряда команд (обслу­живающая программа – обработчик прерывания), предназначенных для вы­борки данных от АЦП. После того как обслуживающая программа выполне­на, микропроцессор возвращается к выполнению исходной программы.

Задача поиска обслуживающей программы иногда решается путем вы­полнения другой программы (программы или процедуры последовательного опроса – поллинга), которая определяет источник прерывания путем после­довательной проверки всех возможных источников. Гораздо эффективнее подход, связанный с использованием векторных прерываний. Этот подход основан на хранении адресов отдельных обслуживающих программ в заранее определенной области памяти, называемой векторной таблицей. В ответ на сигнал прерывания микропроцессор теперь обращается к определенной ячейке памяти, в которую пользователем занесен адрес соответствующей об­служивающей программы. Реальная эффективность этого метода проявляет­ся в системах с большим числом источников прерываний, как в случае IBM PC. В таких системах, как правило, используется специальное устройство, называемое контроллером прерываний. Контроллер прерываний, например Intel 8259А (другие семейства микропроцессоров имеют эквивалентные уст­ройства), организует различные приходящие сигналы прерываний в приори­тетные очереди (выстраивает в порядке их значимости), посылает сигнал прерывания в микропроцессор и указывает ему на нужную ячейку в вектор­ной таблице.

 

8. Программное обеспечение интерфейса

Передача данных между АЦП и микропроцессором на программном уровне может быть организована тремя способами.

Передача через пространство основной памяти. При распределении па­мяти АЦП присваивается некоторый адрес в пространстве основной памяти, не используемый для фактического хранения данных и программ. Передача данных между АЦП и микропроцессором осуществляется путем обращения к АЦП просто как к ячейке памяти с данным адресом. Однако помимо умень­шения полезного пространства памяти такой подход может привести к ус­ложнению управления памятью и, как правило, требует использования до­полнительных аппаратных средств дешифрации адреса, поскольку при ми­нимуме этих средств, слишком расточительно используется память.

Передача через пространство подсистемы ввода – вывода (ВВ). В неко­торых системах создается отдельный набор адресов для подсистемы ВВ (пространство ВВ), которые могут совпадать по численным значениям с ад­ресами ячеек основной памяти, но отличаются от них с помощью использо­вания специальных управляющих сигналов (IOR и IOW), выдаваемых на сис­темную шину PC. Отделение пространства памяти от пространства ВВ улуч­шает характеристики системы. Как правило, это позволяет довольно просто осуществлять дешифрацию адреса с использованием минимального количе­ства аппаратных средств, поскольку “приносится в жертву” пространство ВВ, а не очень ценное пространство основной памяти.

Прямой доступ к памяти (ПДП). Если возникает необходимость только в простой передаче данных между памятью и каким-либо периферийным устройством, включение в интерфейс регистра - аккумулятора микропроцес­сора неоправданно уменьшает скорость передачи данных. Используя допол­нительные аппаратные средства, обычно в виде специального устройства, на­зываемого контроллером ПДП, можно осуществлять непосредственную пе­редачу данных с гораздо большей скоростью. Большинство микропроцессо­ров допускает реализацию ПДП путем передачи управления системной ши­ной на определенный промежуток времени контроллеру ПДП. Контроллер ПДП в течение этого промежутка времени управляет работой шины (захва­тывает шину) и обеспечивает передачу данных путем генерации соответст­вующих адресов и управляющих сигналов. Затем управление системной ши­ной передается обратно микропроцессору. Для передачи всех данных может потребоваться несколько таких ПДП-циклов. ПДП эффективен в тех приме­нениях, где нужно обеспечить высокую скорость передачи данных или нуж­но передавать большие объемы данных. Применение этого метода в системах сбора данных в принципе возможно, но характерно только для систем с вы­сокими рабочими параметрами. На системной плате PC имеется восьмика-нальный контроллер ПДП, который выполняет некоторые системные функ­ции, включая регенерацию памяти и обмен информацией с диском.

 

9. Аппаратные средства интерфейса

Характер использования аппаратных средств в сильной степени зави­сит от того, в какой форме представляются данные – в последовательной, или в параллельной.

Параллельная форма представления данных. Аппаратные средства па­раллельного интерфейса почти всегда включают буфер с тремя состояниями (тристабильный буфер), через который АЦП подключается к шине данных микропроцессора. Дешифрованный адрес и вырабатываемый микропроцес­сором управляющий сигнал (строб) чтения используются для отпирания это­го буфера и передачи данных от АЦП к микропроцессору. Тот же самый адрес и вырабатываемый микропроцессором управляющий сигнал записи ис­пользуются для запуска преобразователя. В общем случае, наличие отдель­ных управляющих сигналов чтения и записи необязательно, но такой подход позволяет использовать один и тот же адрес при передаче команд к АЦП и считывании данных с выхода АЦП.

В большинстве АЦП нового поколения тристабильные буферы вместе со своими управляющими схемами находятся на самом кристалле. Такие АЦП можно непосредственно подключать к шине данных микропроцессора. Для сопряжения этих устройств с процессором пользователь должен только обеспечить дешифрованный адрес и ввести несколько логических элементов для согласования управляющих сигналов.

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

Cопряжение 10- или 12-разрядного АЦП с 8-разрядной шиной данных довольно просто решается путем передачи данных порциями по 8 бит (1 байт) одна за другой. Этот способ пригоден как для параллельного, так и для последовательного интерфейсов.

10. Виды интерфейсов ос

Виды интерфейсов. Технологии реализации интерфейсов

Интерфейс может быть понятным и непонятным, дружественным или нет. Современные виды интерфейсов:

1) командный интерфейс – пользователь дает команды компьютеру, который их выполняет и выдает результат пользователю. Командный интерфейс реализован в виде пакетной технологии и технологии командной строки;

2) WIMP-интерфейс (WIMP от: Window – окно; Image – образ; Menu – меню; Pointer – указатель) – диалог пользователя с компьютером ведется при помощи графических образов: меню, окон и других элементов. Интерфейс реализован на двух уровнях технологий: простой графический интерфейс и WIMP-интерфейс;

3) SILK-интерфейс (SILK от: Speech – речь; Image – образ; Language – язык; Knowlege – знание) – разговор пользователя с компьютером. Интерфейс наиболее приближен к обычной, человеческой форме общения. При этом компьютер определяет команды, анализируя человеческую речь и находя в ней ключевые фразы. Результат выполнения команд компьютер преобразует в понятную человеку форму. Этот вид интерфейса наиболее требователен к аппаратным ресурсам компьютера, поэтому его применяют в основном для военных целей.

11. Технология командной строки. Информация пользователя для компьютера передается посредством клавиатуры. Компьютер выводит информацию на алфавитно-цифровой дисплей (монитор). Комбинацию «монитор + клавиатура» назвали терминалом или консолью. Команды набираются в командной строке, которая представляет собой символ приглашения и мигающий прямоугольник – курсор. При нажатии клавиши на месте курсора появляются символы, и курсор смещается вправо, неправильно набранный символ стирается нажатием клавиши Delete (del). Команда заканчивается нажатием клавиши Enter (Return), после чего осуществляется переход в начало следующей строки, в позиции которой компьютер выдает на монитор результаты своей работы. Затем процесс повторяется. Технология командной строки уже работала на монохромных алфавитно-цифровых дисп