Периферийная подсистема

Cтраница 1

Периферийные подсистемы управляющих ЭВМ часто требуют особой компоновки. Например, подсистема аналогового входа и выхода предъявляет особые требования к сопротивлению изоляции, способности подавлять высокие напряжения продольной помехи, к равномерному распределению температуры и экранированию. Требование ввода через большое количество линий и обеспечения легкого доступа персонала к терминалам является общим для подсистем как цифрового, так и аналогового входа и выхода. Блоки, сконструированные для компактных логических устройств, часто не отвечают подобным условиям. Эти соображения рассматриваются также в гл. [1]

Для проверки каждой периферийной подсистемы по очереди пропускаются испытательные программы функционального типа. Выполняются измерения скорости передачи данных, других скоростей и емкостных характеристик; кроме того, проверяются рабочие режимы и форматы, а также схемы обнаружения и исправления ошибок; затем определяется исправность ламп сигнализации и переключателей каждого устройства и, наконец, проверяется возможность одновременного функционирования всех периферийных устройств. [2]

Как другой крайний случай, намного более простая периферийная подсистема может состоять лишь из одного процессора - АР и не иметь мультизадачной операционной системы. В этом случае тот процесс АР, который контролирует процессор IP, управляет также и работой всех устройств ввода-вывода в данной периферийной подсистеме. [3]

Вычислительная подсистема работает без прерываний от периферийной подсистемы. [4]

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

При обычных операциях вычислительная подсистема управляет периферийной подсистемой. Включение в список приказов IP операций межпроцессорной коммуникации служит для достижения целей управления системой. [6]

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

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

В данном абстрактном рассмотрении мы не ограничиваем структуру периферийной подсистемы. [9]

Похожий метод применяется при выделении и освобождении физических устройств в периферийной подсистеме. Реальное устройство доступно лишь процессу-драйверу устройства, который в свою очередь доступен другим процессам АР. Стало быть, физическое устройство становится доступным процессу 1432 только после создания соответствующего процесса-драйвера и после того, как в центральную системную таблицу, адресуемую АР, произведена запись об этом драйвере. Относящаяся к физическому устройству информация, которую требуется поместить в создаваемую абстракцию устройства, должна быть получена с помощью дополнительного обмена с процессом АР. Эти подробности мы оставляем воображению читателя. [10]

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

Следует сделать важное замечание: вне зависимости от структуры, использующейся при реализации периферийной подсистемы, ее интерфейс для задач системы i432 может оставаться в точности тем же самым. Стало быть, задача А может реализовать простой ( и неизменный) протокол выполнения операций ввода-вывода. Однако совершенно необязательно, чтобы задача системы i432 ждала такого ответа. В модели, предлагаемой на рис. 7.4, задача А может свободно игнорировать информацию о состоянии в сообщении-ответе. Даже если информация о состоянии не игнорируется, ее распознавание может быть выполнено не сразу же, а по прошествии некоторого заранее определенного числа запросов ввода-вывода. Читатели, знакомые страдицион-ной схемой ввода-вывода с буферизацией, увидят, что использование пула из т объектов типа сообщение имитирует буфер ввода-вывода, размер которого кратен т блокам ввода-вывода, и каждый блок содержит команду, данные и состояние одной операции ввода-вывода. [12]

Как было обещано, на рис. 7.5 показаны некоторые детали возможной структуры интерфейса с периферийной подсистемой. Все подпрограммы АР, непосредственно управляющие процессором IP или выполняющие передачи вида Read или Write через окна IP, собраны в одном модуле, называемом контроллером IP. Множество отдельных процессов АР, которые связываются со специфическими процессами драйверов устройств, также являются частью PSI. Эти процессы АР знают, как вызывать программы из модуля контроллера IP и, следовательно, знают об архитектуре IP. Однако они не знают деталей устройства ввода-вывода. [13]

Для того чтобы различать две подобные системы сообщений, используются различные обозначения при описании потока сообщений в периферийной подсистеме. [14]

Структура периферийной подсистемы. [15]

Страницы: 1 2 3