Ирпс интерфейс: Уроки Ардуино. Интерфейс ИРПС (цифровая токовая петля). Принцип действия, параметры, схемная реализация.

назначение, основные технические характеристики, принципы передачи данных.

ИРПС – это стандартный интерфейс для радиального подключения устройств с последовательной передачей данных. Он применялся в выпускавшихся в СССР до 90-х годов прошлого века компьютерах для подключения различных периферийных устройств (принтеров, телетайпов). В настоящее время ИРПС широко используется в промышленной автоматике для связи между контроллерами, передачи информации от различных счетчиков, например, тепловой и электрической энергии. Международное название этого интерфейса – токовая петля (Current Loop – CL).

О. Резистор служит для получения стандартной величины тока, обычно 20 мА. Датчиком тока может служить обмотка электромагнитного реле. Логической 1 соответствует протекание тока в линии связи, логическому 0 – отсутствие тока в линии. В современных устройствах интерфейса ключи передатчиков и датчики тока в приемниках выполняются на основе электронных компонентов.

Рис. 14.5. Схема «токовой петли»

ИРПС позволяет осуществить дуплексную передачу данных импульсами постоянного тока асинхронным способом по 4-проводной линии связи.

Устройства, подключаемые к интерфейсу ИРПС, должны иметь в своем составе универсальный асинхронный приемопередатчик UART. В передающем устройстве UART формирует из параллельных данных кадр для асинхронной последовательной передачи на выходе TxD, а передатчик ИРПС преобразует его в импульсы постоянного тока, поступающие в линию связи. В приемном устройстве приемник ИРПС принимает токовые импульсы и преобразует их в сигналы ТТЛ-уровней на выходе RxD, которые поступают в UART.

Формат передаваемой информации в ИРПС аналогичен интерфейсу RS-232. Сообщения передаются кадрами. Кадр начинается старт-битом, затем идут 5,7, или 8 бит данных (начиная с младшего разряда), потом необязательный бит паритета (контроль на четность или нечетность), и в заключение 1 или 2 стоп-бита. Старт-бит всегда имеет уровень логического 0 (отсутствие тока в линии), стоп-биты всегда имеют уровень логической 1. Скорости передачи данных выбираются из того же ряда, что и для стандарта RS-232: 110, 150, 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200 бит/с. Так как при отсутствии передачи в линии связи интерфейса должен протекать ток (логическая 1), то приемник может легко распознать обрыв линии: при этом принимаются одни нули. Также обрыв распознается приемником при передаче информации по отсутствию стоп-битв в кадре.

Стандарт ИРПС предполагает обязательное гальваническое разделение цепей передатчика и приемника. Это защищает оборудование, подключенное к интерфейсу, от электромагнитных помех, наводимых в проводах линии связи. По стандарту интерфейс ИРПС обеспечивает передачу информации со скоростью 9600 бит/с на расстоянии до 500 м. Возможно увеличить это расстояние до нескольких километров, но при этом пропорционально должна быть снижена скорость передачи. Поскольку интерфейс требует пары проводов для каждого сигнала, то обычно применяют две пары – принимаемые данные и передаваемые данные. В случае двунаправленного (дуплексного) обмена для управления потоком используется программный протокол XON/XOFF по аналогии с интерфейсом RS-232. Если применяется однонаправленный (симплексный) обмен, то используют одну линию данных, а для управления потоком обратная линия задействуется для передачи сигнала готовности приемника (аппаратный протокол, аналогичный RTS/CTS для RS-232) или для передачи кодов XON/XOFF от приемника (программный протокол).

Достоинствами интерфейса ИРПС являются: простота реализации; высокая помехоустойчивость; большая длина соединительного кабеля; в цепь передачи тока могут включаться несколько приемников и передатчиков.

Недостатками ИРПС являются: большая потребляемая мощность; недостаточная стандартизация применяемого оборудования; отсутствие готовых микросхем для реализации интерфейса.

Содержание

Интерфейс ирпс

Когда источник или приемник информации удален от ЭВМ на значительное расстояние, применяется последовательная передача. Прежде чем начать последовательную передачу, необходимо выполнить преобразование данных из параллельной формы в последовательную.

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

Рис. 3.2. Передача данных по линии последовательной передачи:

СД – сдвиговый регистр; СР – старший разряд; МР – младший разряд;

ГТИ – генератор тактовых импульсов

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

На рис. 3.3 изображено 8-битовое слово данных и показаны дополнительные биты. Стартовый бит всегда имеет значение логического «0», стоп-бит – логической «1».

Рис. 3.3. Слово данных с дополнительными битами

Скорость передачи данных принято измерять в бодах. Один бод равен одному биту в секунду. Например, скорость передачи 1200 бод означает, что за одну секунду будет передано 120 10-битовых символов: стартовый бит, 8 бит данных и стоп-бит.

Если при передаче данных применяется контроль на четность, то восьмому биту придается значение логического «0» или «1» так, чтобы в передаваемом 8-битовом слове данных было четное количество единиц. Иногда используется бит нечетности. В этом случае общее количество единиц в 8-битовом слове должно быть нечетным.

Сигналы в линии могут иметь различное представление. При передаче на небольшие расстояния в линии действуют уровни напряжения 3..5 В (RS-232).

При больших расстояниях (до 1,5 км) используют токовую петлю – импульсы постоянного тока 20 или 40 мА. В случае дуплексной связи (т. е. передачи информации как в прямом, так и в обратном направлении) используют четырехпроводную линию.

Асинхронная связь постоянным током (токовая петля) по четырехпроводной дуплексной линии носит название радиального последовательного интерфейса (ИРПС).

Упрощенная структурная схема УАПП приведена на рис. 3.4.

Рис. 3.4. Структура УАПП

Универсальный асинхронный приемопередатчик состоит из трех секций: передачи, управления и приема. Секция передачи служит для преобразования данных из параллельной формы в последовательную. Байт данных поступает из ЭВМ в параллельной форме в регистр данных РД передатчика. После завершения передачи в линию предыдущего байта и освобождения выходного регистра байт данных переносится (также параллельно) в выходной сдвиговый регистр.

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

Пока байт данных передается в линию, в РД передатчика может загружаться из ЭВМ следующий байт данных.

Секция приема работает аналогично. Биты, поступающие из линии, вдвигаются во входной сдвиговый регистр. После получения всего кадра из него убираются служебные биты, оставшаяся часть переносится параллельно в РД приемника, откуда по команде программы данные принимаются в ЭВМ.

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

Преобразования последовательных интерфейсов

Стандарт RS-232C описывает несимметричные передатчики и приемники. Интерфейс не обеспечивает гальванической развязки устройств. Логической единице соответствует напряжение на входе приемника в диапазоне –12…–3 В. Логическому нулю соответствует диапазон +3…+12 В.

На физическом уровне последовательный интерфейс имеет различные реализации, отличающиеся способом передачи электрических сигналов. Существует ряд международных стандартов, родственных RS-232C. На рис. 3.5 приведены схемы соединения их приемников и передатчиков, а также показаны ограничения на длину линии (L) и максимальную скорость передачи данных (V).

Несимметричные линии интерфейсов RS-232C и RS-423A имеют самую низкую защищенность от синфазной помехи, хотя дифференциальный вход приемника RS-423A несколько смягчает ситуацию. Лучшие параметры имеет двухточечный интерфейс RS-422A и его магистральный (шинный) аналог RS-485, работающие на симметричных линиях связи. В них для передачи каждого сигнала используются дифференциальные сигналы с отдельной (витой) парой проводов для каждой сигнальной цепи.

Рис. 3.5. Стандарты последовательных интерфейсов

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

Рис. 3.6. Интерфейс по току

Логической единице соответствует ток 20 мА, а логическому нулю – отсутствие тока. Такое представление сигналов позволяет обнаружить обрыв линии – приемник заметит отсутствие стоп-бита.

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

ИРПС Википедия

То́ковая петля́ (current loop) — способ передачи информации с помощью измеряемых значений силы электрического тока. В настоящее время такой способ более распространён^{[источник не указан 465 дней]} в инженерной практике, чем использование для этой цели напряжения. Для задания измеряемых значений тока используется, как правило, управляемый источник тока. По виду передаваемой информации различаются аналоговая токовая петля и цифровая токовая петля.

Цифровая токовая петля[ | ]

Преобразователь RS-232 / токовая петля

Применяется в телекоммуникационном оборудовании и компьютерах для последовательной передачи данных.

История[ | ]

Токовая петля использовалась задолго до появления стандартов RS-232 и V.24. В 1960-е годы телетайпы начали использовать стандарт токовой петли 60 миллиампер. Последующие модели (одна из первых — Teletype Model ASR-33) использовали стандарт 20 мА. Этот стандарт нашел широкое применение в мини-компьютерах, которые первоначально использовали телетайпы для диалога с оператором. Постепенно телетайпы уступили место текстовым видеотерминалам, сохраняя интерфейс токовой петли. В 1980-х стандарт RS-232 окончательно заменил токовую петлю^{[источник не указан 465 дней]}.

Принципы работы[ | ]

Стандарт цифровой токовой петли использует отсутствие тока как значение SPACE (низкий уровень, логический ноль) и наличие сигнала — как значение MARK (высокий уровень, логическая единица). Отсутствие сигнала в течение длительного времени интерпретируется как состояние BREAK (обрыв линии). Данные передаются старт-стопным методом, формат посылки совпадает c RS-232, например 8-N-1: 8 бит, без паритета, 1 стоп-бит.

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

Из-за неидеальности источника тока, максимально допустимая длина линии (и максимальное сопротивление линии) зависит от напряжения, от которого питается источник тока. Например при типичном напряжении питания 12 вольт сопротивление не должно превышать 600 Ом.

Источник тока может располагаться в приёмном или передающем конце токовой петли. Узел с источником тока называют активным. В зависимости от конструкции как передатчик, так и приёмник, могут быть либо активными (питать токовую петлю), так и пассивными (питаться от токовой петли).

Для компьютеров семейства ДВК по умолчанию принимается, что передатчик — активный, приёмник — пассивный.

Стандартизация

назначение, основные технические характеристики, принципы передачи данных. Интерфейс ИРПС: назначение, основные технические характеристики, принципы передачи данных.

ИРПС– это стандартный интерфейс для радиального подключения устройств с последовательной передачей данных. Он применялся в выпускавшихся в СССР до 90-х годов прошлого века компьютерах для подключения различных периферийных устройств (принтеров, телетайпов). В настоящее время ИРПС широко используется в промышленной автоматике для связи между контроллерами, передачи информации от различных счетчиков, например, тепловой и электрической энергии. Международное название этого интерфейса – токовая петля (Current Loop – CL).

Способ последовательной передачи данных «токовая петля» заимствован из телеграфии. Два устройства (передатчик и приемник) соединяются двухпроводной линией, образующей замкнутую электрическую цепь (рис. 14.5). В передатчике размещается ключ К, который может размыкать цепь, а в приемнике – детектор тока ДТ, определяющий наличие или отсутствие тока в цепи. Кроме того, в эту цепь включается источник питания E и ограничивающий резистор R_О. Резистор служит для получения стандартной величины тока, обычно 20 мА. Датчиком тока может служить обмотка электромагнитного реле. Логической 1 соответствует протекание тока в линии связи, логическому 0 – отсутствие тока в линии. В современных устройствах интерфейса ключи передатчиков и датчики тока в приемниках выполняются на основе электронных компонентов.

Рис. 14.5. Схема «токовой петли»

Дата добавления: 2015-12-07; просмотров: 638 | Нарушение авторских прав

mybiblioteka.su – 2015-2020 год. (0.017 сек.)

Исследование методов передачи информации между микроЭВМ с помощью стандартных интерфейсов ИРПС и С2 (Лабораторная работа № 21)

ЛАБОРАТОРНАЯ РАБОТА № 21

ИССЛЕДОВАНИЕ ПОСЛЕДОВАТЕЛЬНОГО ИНТЕРФЕЙСА

1. ЦЕЛЬ РАБОТЫ

Изучение и исследование методов передачи информации между микроЭВМ с помощью стандартных интерфейсов ИРПС и С2.

2. ОСНОВНЫЕ ТЕОРЕТИЧЕСКИЕ СВЕДЕНИЯ

Последовательные интерфейсы используются для связи удаленных внешних устройств (ВУ) с микроЭВМ. Передача данных производится побитно, обычно в асинхронном режиме. Для этих интерфейсов характерно малое количество линий связи и их большая длина. В странах СНГ широкое распространение получили два типа последовательных интерфейсов – ИРПС и С2.

ИРПС – это последовательный радиальный интерфейс. В нем передача сигналов организована по принципу токовой петли 20 мА (или 40 мА) по двухпроводной линии связи. Логической единице соответствует ток 20 мА, а логическому нулю – отсутствие тока. Для организации дуплексного обмена (в двух направлениях) требуется четырехпроводная линия связи. Передача информации осуществляется асинхронным способом. Стартовый бит соответствует отсутствию тока, число информационных бит может быть 5,7 и 8, предусмотрен контроль паритета, число стоповых бит – 1, 1,5 или 2. В интервалах между передачей данных цепь должна находиться в единичном состоянии (протекать ток 20 мА). Сторона ИРПС, которая выдает данные, называется передатчиком, а принимающая сторона – приемником.

Стандарт на ИРПС допускает использование отдельной линии взаимосвязи, указывающей на состояние приемника. Ток в цепи взаимосвязи означает готовность приемника, а его отсутствие – что приемник не готов к приему данных.

Интерфейс ИРПС обеспечивает возможность передачи данных со скоростью до 9600 Бод (бит/с) на расстояние до 500 м. Двухпроводная линия цепи передачи тока выполнена в виде витой пары. ИРПС нашел основное применение в промышленных системах, так как позволяет осуществить связь на большие расстояния без необходимости использования модемов.

Интерфейс С2 (называется также стык С2) является последовательным интерфейсом, широко применяемым в сетях ЭВМ. Он является аналогом зарубежного интерфейса RS-232C. Стандартом на интерфейс определены скорости передачи данных, типы и число контактов разъема, электрические параметры приемников и передатчиков, виды соединений и алгоритмы обмена.

Стандарт определяет электрические параметры сигналов интерфейса С2. Так, состояние лог.0 в передатчике определяется уровнем от +5 В до +15 В, а в приемнике – выше +3 В. Состоянию лог.1 в передатчике соответствует уровень от -5 В до -15 В, а в приемнике – ниже -3 В. При разомкнутой линии связи напряжение может достигать величины +25 В или -25 В.

Все соединительные линии интерфейса С2 можно условно разбить на две группы: линии передачи данных и линии управления передачей. Часть линий управления используется для квитирования установления связи, другая часть может выполнять синхронизацию, задавать скорость передачи, управлять связным оборудованием. В простейшем случае линии управления могут отсутствовать. Тогда для односторонней передачи необходимо только 2 провода, а для двухсторонней – 4.

Длина линии связи для интерфейса С2 зависит от скорости передачи и вида устройств согласования с линией. Так, для несогласованной линии при скорости передачи 19200 Бод ее длина не должна превышать 15 м.

Стандарт на последовательные интерфейсы устанавливает строго определенные скорости передачи данных. Например, для интерфейса С2 (RS-232C) предусмотрены скорости 19200, 9600, 4800, 2400, 1200, 600, 300 Бод.

2.2. Лабораторный макет для исследования

последовательных интерфейсов

В качестве лабораторного макета используется ТЭЗ (сокращение от слов – типовой элемент замены) с маркировкой ППИ, который присоединяется к учебной микроЭВМ УМК с помощью разъема, расположенного на передней панели. Этот ТЭЗ предназначен для исследования двух БИС микропроцессорного комплекта КР580: адаптера последовательной связи КР580ВВ51А и программируемого таймера КР580ВИ53. На плате ТЭЗа находятся все необходимые устройства для связи этих БИС с системной шиной микроЭВМ: дешифраторы адреса, буферы данных и т.д. В верхней части ТЭЗа находится макетное поле , на котором пользователь может размещать дополнительные элементы.

Лабораторный макет выполняет роль устройства сопряжения микроЭВМ с линией связи последовательного интерфейса, при этом реализуется однонаправленная передача данных от стороны 1 к стороне 2. На рис.1 приведена упрощенная схема последовательного интерфейса, реализованного в данной работе.

В дальнейшем микроЭВМ УМК и ТЭЗ стороны 1 (передатчик) будут обозначаться как УМК1 и ТЭЗ1, а стороны 2 (приемник) – УМК2 и ТЭЗ2.

Для реализации последовательной передачи данных передатчик и приемник должны иметь тактовые генераторы, работающие с одинаковой частотой. Допускается разброс частот не более 5%. На ТЭЗах, используемых в лабораторной работе, в качестве тактового генератора применен счетчик CT0 таймера КР580ВИ53, который работает в режиме 3 – программируемого генератора прямоугольных импульсов. На вход счетчика CLK0 подаются тактовые импульсы F2ттл микроЭВМ. БИС КР580ВВ51А предусматривает передачу и прием последовательных данных со скоростью, равной частоте синхронизации, а также меньшей в 16 или 64 раза. Чем больше частота передачи данных отличается от частоты синхронизации TxC (RxC), тем надежнее передача и менее жесткие требования к стабильности частоты генераторов. Для связи ПСА с линией связи в лабораторной работе используются инверторы DD3.1, установленные на передающей и приемной сторонах. В линии связи при этом будет действовать инверсная логика: лог.1 соответствует низкий уровень, а лог.0 – высокий. Таким образом, напряжение в линии связи будет по форме (но не по уровням) соответствовать стандарту интерфейса С2 (RS-232C).

Интерфейс «Токовая петля» — Студопедия

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

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

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

Цепи взаимосвязи приведены в табл. 5.6. Сигналы в цепи 1 возникают в источнике и проходят к приемнику.

Таблица 2.6. Цепи интерфейса ИРПС

Номер	Наименование	Обозначение	Направление
	Передаваемые данные	ПД+/ПД–	От И к П/ от П к И
	Принимаемые данные	ПрД+/ПрД–	От П к И / от И к П
	Готовность приемника (необязательная цепь)	ГП+/ГП–	От П к И / от И к П

Знаки «+», «–» указывают направление тока в петле

Цепи 1, 2 и интервале между передаваемыми знаками или словами находятся в состоянии 1. Состояние 1 или 0 должно удерживаться в течение целого интервала сигнала. В случае, если устройство предназначено только для приема, цепь 1 остается разомкнутой. Цепь 3 в состоянии 1/0 указывает готовность/неготовность приемника к приему новой информации.

Формат передаваемой информации (в битах) следующий: старт – 1; передаваемые данные – 5,7 или 8; четность – 1 или отсутствует; стоп – 1,5 или 2. Формат кадра при последовательном асинхронном протоколе связи приведен на рис. 2.19.

Рис. 2.19. Формат кадра

В активном/пассивном режиме цепи взаимосвязи реализованы так, чтобы они питались от передатчика/приемника. Уровни сигналов для двух вариантов ИРПС приведены в таблице 5.7.

Таблица 2.7. Уровни сигналов ИРПС

Тип петли ИРПС	Состояние	Ток, мА
40-миллиамперная токовая петля	лог. 1 / 0	30÷50 / 5÷10
20-миллиамперная токовая петля	лог. 1 / 0	15÷25 / 0÷3

Соединяемые оконечные устройства имеют гальваническое разделение, осуществляемое со стороны цепи взаимосвязи, которая не питается током. Номинальное значение изоляционного напряжения гальванического разделения – 500 В.

Максимальная длительность фронтов сигналов в конце линии, нагруженной на характеристическое сопротивление, не превышает 50 мкс. Цепи взаимосвязи обеспечивают передачу сигналов со скоростью 9600 бит/с на расстояние от 0 до 500 м. При передаче на большие расстояния пропорционально понижается скорость передачи.

Сигналы взаимосвязи должны приближаться к прямоугольной форме. Крутизна фронтов сигналов, измеряемых на выходных зажимах передатчика, нагруженного сопротивлением 100 Ом, не более 1 мкс.

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

Параметры приемника следующие: падение напряжения, измеряемое на входных зажимах приемника, в состоянии 1 в цепи взаимосвязи – не более 2,5 В; входная емкость – менее 10 нФ; приемник работает независимо от крутизны фронтов в диапазоне 0…50 мкс.

Цепи взаимосвязи выполняются витой парой. Типы применяемого разъема и кабеля не регламентируются, по своим параметрам они должны удовлетворять вышеприведенным требованиям.

Подключение оборудования по интерфейсу «Токовая петля», четырехпроводное включение, полный дуплекс показано на рис. 2.20.

Рис. 2.20. Подключение полный дуплекс

5. Беспроводные интерфейсы Оптический интерфейс с открытым каналом IrDa

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

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

Воздушная среда передачи данных рассеивает излучение и не позволяет организовывать несколько линий или дуплексный режим работы. Поэтому в стандарт на интерфейс IrDA заложен полудуплекный режим.

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

Интерфейс IrDA разработан как расширение стандарта RS-422. В формате передачи данных много общего. Как следствие, реализация портов IrDA и конвертеров СОМ-IrDA не представляет трудностей, можно использовать совместимую элементную базу.

При передаче данных импульсы излучения генерируются в однозначном соответствии с сигналами интерфейса RS-422. Уровень логического «0» передается в IrDA коротким импульсом. Уровень логической «1» – отсутствием излучения (рис. 5.1).

Свободная линия в RS-422 принимает значение логической «1». Передача начинается с формирования стартового бита уровнем логического «0». По этому импульсу приемник синхронизируется и начинает прием последовательных данных. Аналогично в интерфейсе IrDA, при отсутствии передачи не формируется ни каких импульсов, что соответствует логической «1».

Рис. 5.1. Схожесть формирования сигналов интерфейсов RS-422 и IrDA

Начало передачи обозначается импульсом стартового бита, вслед за ним передаются данные. Стоповый бит обозначается уровнем логической «1». Помехозащищенность, достоверность и надежность такого канала обмена – низкие. Соответственно интерфейс IrDA может быть использован в неответственных приложениях.

Для работы компактных устройств очень важно невысокое потребление энергии батарей. Поэтому импульсы передатчика интерфейса IrDA имеют высокую скважность. Длительность импульса должна быть равна 3/16 от времени передачи одного бита. Но импульс не может быть короче 1,63 мс. Такой импульс формируется при скорости обмена данными 115,2 кбит/с и выше (табл. 5.1).

Таблица 5.1

Временные параметры импульса интерфейса IrDA

Скорость передачи данных, кбит/с	2,4	9,6	19,2	38,4	57,6	115,2
Время передачи одного бита, мс	416	104	52	26	17,3	8,68
Длительность импульса, мс, ±0,22мс	78,13	19,53	9,77	4,88	3,26	1,63

Оптический приемопередатчик стандарта IrDA часто выполняется в виде приставки к универсальному порту последовательного интерфейса UART. Такая архитектура обеспечивает очень низкую стоимость оборудования. На рис. 5.2 показана типовая схема трансивера IrDA.

Рис. 5.2. Типовая схема трансивера IrDA

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

Конструктивно трансивер интерфейса IrDA обычно выполняется в виде микросхемы в корпусе, прозрачном для инфракрасного излучения (длина волны в IrDA равна 880 нм, с допуском в пределах 850–900 нм). Такая конструкция технологична, недорога в изготовлении и монтаже.

В корпусе изделия сосредоточены инфракрасные светодиод и фотоприемник со своей оптикой, выходные каскады передатчика, входной усилитель и схема первичной обработки приемника.

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

90000 IRP_MN_QUERY_INTERFACE – Windows drivers | Microsoft Docs 90001 90002 90003 90004 08/12/2017 90005 90006 90003 6 minutes to read 90006 90003 90006 90011 90012 In this article 90013 90014 The 90015 IRP_MN_QUERY_INTERFACE 90016 request enables a driver to export a direct-call interface to other drivers.90017 90014 A bus driver that exports an interface must handle this request for its child devices (child PDOs). Function and filter can optionally handle this request. 90017 90014 An “interface” in this context consists of one or more routines, and possibly data, exported by a driver or set of drivers. An interface has a structure that describes its contents and a GUID that identifies its type. 90017 90014 For example, the PCMCIA bus driver exports an interface of type GUID_PCMCIA_INTERFACE_STANDARD that contains routines for operations such as getting the write-protect condition of a PCMCIA memory card.The function driver for such a memory card can send an 90015 IRP_MN_QUERY_INTERFACE 90016 request to the parent PCMCIA bus driver to get pointers to the PCMCIA interface routines. 90017 90014 This section describes the query-interface IRP as a general mechanism. Drivers that expose an interface should provide additional information about their specific interface. 90017 90028 Value 90029 90014 0x08 90017 90028 Major Code 90029 90014 90015 IRP_MJ_PNP 90016 90017 90028 When Sent 90029 90014 A driver or system component sends this IRP to get information about an interface exported by a driver for a device.90017 90014 A driver or system component sends this IRP at IRQL = PASSIVE_LEVEL in an arbitrary thread context. 90017 90014 A driver can receive this IRP at any time after the driver’s 90045 AddDevice 90046 routine has been called for the device. The device might or might not be started when this IRP is sent (that is, you can not assume that the driver has successfully completed an 90015 IRP_MN_START_DEVICE 90016 request for the device). 90017 90028 Input Parameters 90029 90014 The 90015 Parameters.QueryInterface 90016 member of the 90015 IO_STACK_LOCATION 90016 structure is itself a structure, which describes the interface being requested. The structure contains the following information: 90017 90058 90059 CONST GUID * InterfaceType; USHORT Size; USHORT Version; PINTERFACE Interface; PVOID InterfaceSpecificData 90060 90061 90014 The members of the structure are defined as follows: 90017 90014 90015 InterfaceType 90016 90067 Points to a GUID that identifies the interface being requested.The GUID can be for a system-defined interface, such as GUID_BUS_INTERFACE_STANDARD, or a custom interface. The GUIDs for system-defined interfaces are listed in Wdmguid.h. GUIDs for custom interfaces should be generated with Uuidgen. 90017 90014 90015 Size 90016 90067 Specifies the size of the interface being requested. Drivers that handle this IRP must not return an 90015 INTERFACE 90016 structure larger than 90015 Size 90016 bytes. 90017 90014 90015 Version 90016 90067 Specifies the version of the interface being requested.90017 90014 If a driver supports more than one version of an interface, the driver returns the closest supported version without exceeding the requested version. The component that sent the IRP should examine the returned 90015 Interface.Version 90016 field and determine what to do based on that value. 90017 90014 90015 Interface 90016 90067 Points to a structure in which to return the requested interface. This structure must contain an 90015 INTERFACE 90016 structure as its first member.The component sending the IRP allocates this structure from paged memory. 90017 90014 A driver that exports an interface defines a new structure type containing the 90015 INTERFACE 90016 structure, plus members for routines and / or data in the interface. (The driver also defines a GUID for the interface, as described in the 90015 InterfaceType 90016 member, above.) 90017 90014 A driver that exports an interface defines the execution environment for each routine in the interface, including the IRQL at which the routine can be called, and so forth.90017 90014 90015 InterfaceSpecificData 90016 90067 Specifies additional information about the interface being requested. 90017 90014 For some interfaces, the component sending the IRP specifies additional information in this field. Typically, this field is 90015 NULL 90016 and the 90015 InterfaceType 90016 and 90015 Version 90016 are sufficient to identify the interface being requested. 90017 90028 Output Parameters 90029 90014 On success, a driver fills in the members of the 90015 Parameters.QueryInterface.Interface 90016 structure. 90017 90028 I / O Status Block 90029 90014 A driver sets 90015 Irp-> IoStatus.Status 90016 to STATUS_SUCCESS or to an appropriate error status. 90017 90014 On success, a bus driver sets 90015 Irp-> IoStatus.Information 90016 to zero. 90017 90014 If a function or filter driver does not handle this IRP, it calls 90015 IoSkipCurrentIrpStackLocation 90016 and passes the IRP down to the next driver. Such a driver must not modify 90015 Irp-> IoStatus.Status 90016 and must not complete the IRP. 90017 90014 If a bus driver does not export the requested interface and therefore does not handle this IRP for a child PDO, the bus driver leaves 90015 Irp-> IoStatus.Status 90016 as is and completes the IRP. 90017 90028 Operation 90029 90014 A driver handles this IRP if the parameters specify an interface the driver supports. 90017 90014 A driver must not queue this IRP if the IRP requests an interface that the driver does not support. A driver must check 90015 Parameters.QueryInterface.InterfaceType 90016 in its 90015 IO_STACK_LOCATION 90016 structure. If the interface is not one the driver supports, the driver must pass the IRP to the next lower driver in the device stack without blocking. 90017 90014 Each interface must provide 90015 InterfaceReference 90016 and 90015 InterfaceDereference 90016 routines, and the driver that exports the interface must supply the addresses of these routines in the 90015 INTERFACE 90016 structure. Before a driver returns an interface in response to the IRP, it must increment the interface’s reference count by calling its 90015 InterfaceReference 90016 routine.When the driver that requested the interface has finished using it, that driver must decrement the reference count by calling the interface’s 90015 InterfaceDereference 90016 routine. 90017 90014 If the driver that sends the IRP (driver 90045 x 90046) later passes the interface to another driver (driver 90045 y 90046) then driver 90045 x 90046 must increment the interface’s reference count and driver 90045 y 90046 must decrement it. 90017 90014 A driver that handles this IRP should avoid passing the IRP to another device stack to get the requested interface.Such a design would create dependencies between the device stacks that are difficult to manage. For example, the device represented by the second device stack can not be removed until the appropriate driver in the first stack dereferences the interface. 90017 90014 Interfaces can be bus-specific or bus-independent. Bus-specific interfaces are defined in the header files for those buses. The system defines a bus-independent interface, 90015 BUS_INTERFACE_STANDARD 90016, for exporting standard bus interfaces.90017 90014 See Plug and Play for the general rules for handling Plug and Play minor IRPs. 90017 90014 This IRP is used specifically to pass routine entry points between layered kernel-mode drivers for a device. Do not confuse the interfaces exposed by this IRP with 90045 device interfaces 90046. A device interface is used primarily for exposing a path to a device for use by user-mode components or other kernel components. For more information about device interfaces, see Device Interface Classes.90017 90014 90015 Sending This IRP 90016 90017 90014 See Handling IRPs for information about sending IRPs. The following steps apply specifically to this IRP: 90017 90191 90003 90014 Allocate an 90015 INTERFACE 90016 structure from paged pool and initialize it to zeros. If the interface will be called at IRQL> = DISPATCH_LEVEL, based on the interface contract, the caller can copy the contents to memory that is allocated from nonpaged pool. 90017 90006 90003 90014 Set the values in the next I / O stack location of the IRP: set 90015 MajorFunction 90016 to 90015 IRP_MJ_PNP 90016, set 90015 MinorFunction 90016 to 90015 IRP_MN_QUERY_INTERFACE 90016, and set the appropriate values in 90015 Parameters.QueryInterface 90016. 90017 90006 90003 90014 Initialize 90015 IoStatus.Status 90016 to STATUS_NOT_SUPPORTED. 90017 90006 90003 90014 Deallocate the IRP and the 90015 INTERFACE 90016 structure when they are no longer needed. 90017 90006 90003 90014 Use the interface routines and context parameter as described in the specification for the interface. 90017 90006 90003 90014 Decrement the reference count using the 90045 InterfaceDereference 90046 routine when the interface is no longer needed.Do not call any interface routines after dereferencing the interface. 90017 90006 90011 90014 A driver typically sends this IRP to the top of the device stack in which the driver is attached. If a driver sends this IRP to a different device stack, the driver must register for target device notification on the other device if the other device is not an ancestor of the device that the driver is servicing. Such a driver calls 90015 IoRegisterPlugPlayNotification 90016 with an 90045 EventCategory 90046 of 90015 EventCategoryTargetDeviceChange 90016.When the driver receives notification of type GUID_TARGET_DEVICE_QUERY_REMOVE, the driver must dereference the interface. The driver can requery for the interface if it receives a subsequent GUID_TARGET_DEVICE_REMOVE_CANCELLED notification. 90017 90028 Requirements 90029 90245 90246 90247 90247 90249 90250 90251 90252 90014 Header 90017 90255 90252 Wdm.h (include Wdm.h, Ntddk.h, or Ntifs.h) 90255 90258 90259 90260 90028 See also 90029 90014 90015 BUS_INTERFACE_STANDARD 90016 90017 90014 90015 INTERFACE 90016 90017 90014 90015 IoRegisterPlugPlayNotification 90016 90017 .90000 _BUS_INTERFACE_STANDARD (wdm.h) – Windows drivers 90001 90002 90003 90004 04/30/2018 90005 90006 90003 2 minutes to read 90006 90009 90010 In this article 90011 90012 The 90013 BUS_INTERFACE_STANDARD 90014 interface structure enables device drivers to make direct calls to parent bus driver routines.This structure defines the GUID_BUS_INTERFACE_STANDARD interface. 90015 90016 Syntax 90017 90018 90019 typedef struct _BUS_INTERFACE_STANDARD { USHORT Size; USHORT Version; PVOID Context; PINTERFACE_REFERENCE InterfaceReference; PINTERFACE_DEREFERENCE InterfaceDereference; PTRANSLATE_BUS_ADDRESS TranslateBusAddress; PGET_DMA_ADAPTER GetDmaAdapter; PGET_SET_DEVICE_DATA SetBusData; PGET_SET_DEVICE_DATA GetBusData; } BUS_INTERFACE_STANDARD, * PBUS_INTERFACE_STANDARD; 90020 90021 90016 Members 90017 90012 90019 Size 90020 90015 90012 The size, in bytes, of this structure.90015 90012 90019 Version 90020 90015 90012 The driver-defined interface version. 90015 90012 90019 Context 90020 90015 90012 A pointer to interface-specific context information. 90015 90012 90019 InterfaceReference 90020 90015 90012 A pointer to an InterfaceReference routine that increments the interface’s reference count. 90015 90012 90019 InterfaceDereference 90020 90015 90012 A pointer to an InterfaceDereference routine that decrements the interface’s reference count.90015 90012 90019 TranslateBusAddress 90020 90015 90012 A pointer to a TranslateBusAddress routine that translates addresses on the parent bus to logical addresses. 90015 90012 90019 GetDmaAdapter 90020 90015 90012 A pointer to a GetDmaAdapter routine that returns a DMA adapter structure (DMA_ADAPTER) for the target device. 90015 90012 90019 SetBusData 90020 90015 90012 A pointer to a SetBusData routine that writes data to the device’s configuration space. 90015 90012 90019 GetBusData 90020 90015 90012 A pointer to a GetBusData routine that reads data from the device’s configuration space.90015 90016 Remarks 90017 90012 The 90013 BUS_INTERFACE_STANDARD 90014 structure is an extension of the INTERFACE structure. 90015 90012 Some operations on a device are reserved for the device’s parent bus driver. These operations might include accessing the device-specific configuration space of a bus or programming a DMA controller. 90015 90012 To read from or write to a device’s configuration space, a device driver must rely on the agency of the bus driver in either of two ways: 90015 90088 90003 By sending the I / O request packets (IRPs) IRP_MN_READ_CONFIG and IRP_MN_WRITE_CONFIG to the bus driver.90006 90003 By obtaining an interface from the bus driver. The device driver can then access its device’s configuration space by making direct calls to the bus driver routines provided by the 90013 BUS_INTERFACE_STANDARD 90014 interface structure. Its member routines, GetBusData and SetBusData, can be used to read from and write to a device’s configuration space, respectively. 90006 90009 For more information about the ways to access configuration space, see Accessing Device Configuration Space.90012 Some types of devices, such as a bus-mastering storage device, have on-board DMA controllers. However, the device drivers for these devices can not program these DMA controllers directly. Instead they must rely on routines provided by the parent bus driver. For a device driver to program the DMA controller for its device, it must first request an adapter object from the parent bus driver. The adapter object contains the routines supplied by the bus driver that can be used to program the device’s DMA controller.Device drivers must rely on the 90013 BUS_INTERFACE_STANDARD 90014, either directly or indirectly, to obtain the adapter object. 90015 90012 If the driver is executing at IRQL = PASSIVE_LEVEL, it should obtain a device’s DMA adapter object by calling IoGetDmaAdapter. 90013 IoGetDmaAdapter 90014 detects whether the bus driver supports the 90013 BUS_INTERFACE_STANDARD 90014 interface. If it does, 90013 IoGetDmaAdapter 90014 calls the routine pointed to by the GetDmaAdapter member of this interface to obtain the adapter object.Otherwise, 90013 IoGetDmaAdapter 90014 calls an equivalent legacy routine. 90015 90012 However, if a driver must obtain an adapter object while running at IRQL> = DISPATCH_LEVEL, it can not do so with IoGetDmaAdapter. In this case, the driver must query for the 90013 BUS_INTERFACE_STANDARD 90014 interface while still at IRQL = PASSIVE_LEVEL by using IRP_MN_QUERY_INTERFACE. 90015 90016 Requirements 90017 90116 90117 90118 90119 90120 90119 90120 90123 90124 90125 90118 90127 90128 Header 90129 90130 90127 wdm.h (include Wdm.h, Ntddk.h, Ntifs.h) 90130 90123 90134 90135 90016 See also 90017 90012 DEVICE_DESCRIPTION 90015 90012 DMA_ADAPTER 90015 90012 GUID_BUS_INTERFACE_STANDARD 90015 90012 GetBusData 90015 90012 GetDmaAdapter 90015 90012 INTERFACE 90015 90012 IRP_MN_QUERY_INTERFACE 90015 90012 IRP_MN_READ_CONFIG 90015 90012 IRP_MN_WRITE_CONFIG 90015 90012 InterfaceDereference 90015 90012 InterfaceReference 90015 90012 IoGetDmaAdapter 90015 90012 SetBusData 90015 90012 TranslateBusAddress 90015 .90000 irp extension command – Windows drivers 90001 90002 90003 90004 08/23/2018 90005 90006 90003 4 minutes to read 90006 90003 90010 90003 90006 90003 90006 90015 90006 90015 90018 In this article 90019 90020 The 90021! Irp 90022 extension displays information about an I / O request packet (IRP).90023 90024 90025! Irp Address [Detail] 90026 90027 90028 Parameters 90029 90020 90031 Address 90032 90033 Specifies the hexadecimal address of the IRP. 90023 90020 90031 Detail 90032 90033 If this parameter is included with any value, such as 1, the output includes the status of the IRP, the address of its memory descriptor list (MDL), its owning thread, and stack information for all of its I / O stacks, and information about each stack location for the IRP, including hexadecimal versions of the major function code and the minor function code.If this parameter omitted, the output includes only a summary of the information. 90023 90018 DLL 90019 90042 90043 90044 90044 90046 90047 90048 90049 90020 90021 Windows XP and later 90022 90023 90054 90049 90020 Kdexts.dll 90023 90054 90059 90060 90061 90018 Additional Information 90019 90020 See Plug and Play Debugging and Debugging Interrupt Storms for applications of this extension command. For information about IRPs, see the Windows Driver Kit (WDK) documentation and 90031 Microsoft Windows Internals 90032 by Mark Russinovich and David Solomon.For further information on the major and minor function codes, see the Windows Driver Kit (WDK) documentation. 90023 90020 This topic describes the IRP structure, 90021 IRP 90022. 90023 90020 For detailed information on decoding the IRP structure including the returned Args, see the following resources. 90023 90074 90003 Windows Internals by Mark E. Russinovich, David A. Solomon and Alex Ionescu 90006 90003 Developing Drivers with the Windows Driver Foundation Guy Smith and Penny Orwick 90006 90015 90028 Remarks 90029 90020 The output also indicates under what conditions the completion routine for each stack location will be called once the IRP has completed and the stack location is processed.There are three possibilities: 90023 90020 90021 Success 90022 90033 Indicates that the completion routine will be called when the IRP is completed with a success code. 90023 90020 90021 Error 90022 90033 Indicates that the completion routine will be called when the IRP is completed with an error code. 90023 90020 90021 Cancel 90022 90033 Indicates that the completion routine will be called if an attempt was made to cancel the IRP. 90023 90020 Any combination of these three may appear, and if any of the conditions shown are satisfied, the completion routine will be called.The appropriate values are listed at the end of the first row of information about each stack location, immediately after the 90021 Completion-Context 90022 entry. 90023 90020 Here is an example of the output from this extension for Windows 10: 90023 90024 90025 0: kd>! Irp ac598dc8 Irp is active with 2 stacks 1 is current (= 0xac598e38) No Mdl: No System Buffer: Thread 8d1c7bc0: Irp stack trace. cmd flg cl Device File Completion-Context > [IRP_MJ_FILE_SYSTEM_CONTROL (d), N / A (0)] 1 e1 8a6434d8 ac598d40 853220cb-a89682d8 Success Error Cancel pending \ FileSystem \ Npfs fltmgr! FltpPassThroughCompletion Args: 00000000 00000000 00110008 00000000 [IRP_MJ_FILE_SYSTEM_CONTROL (d), N / A (0)] 1 0 8a799710 ac598d40 00000000-00000000 \ FileSystem \ FltMgr Args: 00000000 00000000 0x00110008 00000000 90026 90027 90020 Starting with Windows 10 the IRP major and minor code text is displayed, for example, “IRP_MJ_FILE_SYSTEM_CONTROL” The code value is also shown in hex, in this example “(d)”.90023 90020 The third argument displayed in the output, is the IOCTL code. Use the 90021! Ioctldecode 90022 command to display information about the IOCTL. 90023 90020 Here is an example of the output from this extension from Windows Vista. 90023 90024 90025 0: kd>! Irp 0x831f4a00 Irp is active with 8 stacks 5 is current (= 0x831f4b00) Mdl = 82b020d8 Thread 8c622118: Irp stack trace. cmd flg cl Device File Completion-Context [0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 [0, 0] 0 0 00000000 00000000 00000000-00000000 Args: 00000000 00000000 00000000 00000000 > [3,34] 40 e1 828517a8 00000000 842511e0-00000000 Success Error Cancel pending \ Driver \ disk partmgr! PmReadWriteCompletion Args: 00007000 00000000 fe084e00 00000004 [3, 0] 40 e0 82851450 00000000 842414d4-82956350 Success Error Cancel \ Driver \ PartMgr volmgr! VmpReadWriteCompletionRoutine Args: 129131bb 000000de fe084e00 00000004 [3, 0] 0 e0 82956298 00000000 847eeed0-829e2ba8 Success Error Cancel \ Driver \ volmgr Ntfs! NtfsMasterIrpSyncCompletionRoutine Args: 00007000 00000000 1bdae400 00000000 [3, 0] 0 0 82ac2020 8e879410 00000000-00000000 \ FileSystem \ Ntfs Args: 00007000 00000000 00018400 00000000 90026 90027 90020 Note that the completion routine next to the driver name is set on that stack location, and it was set by the driver in the line below.In the preceding example, 90021 Ntfs! NtfsMasterIrpSyncCompletionRoutine 90022 was set by 90021 \ FileSystem \ Ntfs 90022. The 90021 Completion-Context 90022 entry above 90021 Ntfs! NtfsMasterIrpSyncCompletionRoutine 90022, 90021 847eeed0-829e2ba8 90022, indicates the address of the completion routine, as well as the context that will be passed to 90021 Ntfs! NtfsMasterIrpSyncCompletionRoutine 90022. From this we can see that the address of 90021 Ntfs! NtfsMasterIrpSyncCompletionRoutine 90022 is 90021 847eeed0 90022, and the context that will be passed to this routine when it is called is 90021 829e2ba8 90022.90023 90020 90021 IRP major function codes 90022 90023 90020 The following information is included to help you interpret the output from this extension command. 90023 90020 The IRP major function codes are as follows: 90023 90042 90043 90044 90044 90046 90154 90048 90156 Major Function Code 90157 90156 Hexadecimal Code 90157 90059 90161 90047 90048 90049 90020 IRP_MJ_CREATE 90023 90054 90049 90020 0x00 90023 90054 90059 90048 90049 90020 IRP_MJ_CREATE_NAMED_PIPE 90023 90054 90049 90020 0x01 90023 90054 90059 90048 90049 90020 IRP_MJ_CLOSE 90023 90054 90049 90020 0x02 90023 90054 90059 90048 90049 90020 IRP_MJ_READ 90023 90054 90049 90020 0x03 90023 90054 90059 90048 90049 90020 IRP_MJ_WRITE 90023 90054 90049 90020 0x04 90023 90054 90059 90048 90049 90020 IRP_MJ_QUERY_INFORMATION 90023 90054 90049 90020 0x05 90023 90054 90059 90048 90049 90020 IRP_MJ_SET_INFORMATION 90023 90054 90049 90020 0x06 90023 90054 90059 90048 90049 90020 IRP_MJ_QUERY_EA 90023 90054 90049 90020 0x07 90023 90054 90059 90048 90049 90020 IRP_MJ_SET_EA 90023 90054 90049 90020 0x08 90023 90054 90059 90048 90049 90020 IRP_MJ_FLUSH_BUFFERS 90023 90054 90049 90020 0x09 90023 90054 90059 90048 90049 90020 IRP_MJ_QUERY_VOLUME_INFORMATION 90023 90054 90049 90020 0x0A 90023 90054 90059 90048 90049 90020 IRP_MJ_SET_VOLUME_INFORMATION 90023 90054 90049 90020 0x0B 90023 90054 90059 90048 90049 90020 IRP_MJ_DIRECTORY_CONTROL 90023 90054 90049 90020 0x0C 90023 90054 90059 90048 90049 90020 IRP_MJ_FILE_SYSTEM_CONTROL 90023 90054 90049 90020 0x0D 90023 90054 90059 90048 90049 90020 IRP_MJ_DEVICE_CONTROL 90023 90054 90049 90020 0x0E 90023 90054 90059 90048 90049 IRP_MJ_INTERNAL_DEVICE_CONTROL IRP_MJ_SCSI 90054 90049 90020 0x0F 90023 90054 90059 90048 90049 90020 IRP_MJ_SHUTDOWN 90023 90054 90049 90020 0x10 90023 90054 90059 90048 90049 90020 IRP_MJ_LOCK_CONTROL 90023 90054 90049 90020 0x11 90023 90054 90059 90048 90049 90020 IRP_MJ_CLEANUP 90023 90054 90049 90020 0x12 90023 90054 90059 90048 90049 90020 IRP_MJ_CREATE_MAILSLOT 90023 90054 90049 90020 0x13 90023 90054 90059 90048 90049 90020 IRP_MJ_QUERY_SECURITY 90023 90054 90049 90020 0x14 90023 90054 90059 90048 90049 90020 IRP_MJ_SET_SECURITY 90023 90054 90049 90020 0x15 90023 90054 90059 90048 90049 90020 IRP_MJ_POWER 90023 90054 90049 90020 0x16 90023 90054 90059 90048 90049 90020 IRP_MJ_SYSTEM_CONTROL 90023 90054 90049 90020 0x17 90023 90054 90059 90048 90049 90020 IRP_MJ_DEVICE_CHANGE 90023 90054 90049 90020 0x18 90023 90054 90059 90048 90049 90020 IRP_MJ_QUERY_QUOTA 90023 90054 90049 90020 0x19 90023 90054 90059 90048 90049 90020 IRP_MJ_SET_QUOTA 90023 90054 90049 90020 0x1A 90023 90054 90059 90048 90049 IRP_MJ_PNP IRP_MJ_MAXIMUM_FUNCTION 90054 90049 90020 0x1B 90023 90054 90059 90060 90061 90020 The Plug and Play minor function codes are as follows: 90023 90042 90043 90044 90044 90046 90154 90048 90156 Minor Function Code 90157 90156 Hexadecimal Code 90157 90059 90161 90047 90048 90049 90020 IRP_MN_START_DEVICE 90023 90054 90049 90020 0x00 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_REMOVE_DEVICE 90023 90054 90049 90020 0x01 90023 90054 90059 90048 90049 90020 IRP_MN_REMOVE_DEVICE 90023 90054 90049 90020 0x02 90023 90054 90059 90048 90049 90020 IRP_MN_CANCEL_REMOVE_DEVICE 90023 90054 90049 90020 0x03 90023 90054 90059 90048 90049 90020 IRP_MN_STOP_DEVICE 90023 90054 90049 90020 0x04 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_STOP_DEVICE 90023 90054 90049 90020 0x05 90023 90054 90059 90048 90049 90020 IRP_MN_CANCEL_STOP_DEVICE 90023 90054 90049 90020 0x06 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_DEVICE_RELATIONS 90023 90054 90049 90020 0x07 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_INTERFACE 90023 90054 90049 90020 0x08 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_CAPABILITIES 90023 90054 90049 90020 0x09 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_RESOURCES 90023 90054 90049 90020 0x0A 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_RESOURCE_REQUIREMENTS 90023 90054 90049 90020 0x0B 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_DEVICE_TEXT 90023 90054 90049 90020 0x0C 90023 90054 90059 90048 90049 90020 IRP_MN_FILTER_RESOURCE_REQUIREMENTS 90023 90054 90049 90020 0x0D 90023 90054 90059 90048 90049 90020 IRP_MN_READ_CONFIG 90023 90054 90049 90020 0x0F 90023 90054 90059 90048 90049 90020 IRP_MN_WRITE_CONFIG 90023 90054 90049 90020 0x10 90023 90054 90059 90048 90049 90020 IRP_MN_EJECT 90023 90054 90049 90020 0x11 90023 90054 90059 90048 90049 90020 IRP_MN_SET_LOCK 90023 90054 90049 90020 0x12 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_ID 90023 90054 90049 90020 0x13 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_PNP_DEVICE_STATE 90023 90054 90049 90020 0x14 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_BUS_INFORMATION 90023 90054 90049 90020 0x15 90023 90054 90059 90048 90049 90020 IRP_MN_DEVICE_USAGE_NOTIFICATION 90023 90054 90049 90020 0x16 90023 90054 90059 90048 90049 90020 IRP_MN_SURPRISE_REMOVAL 90023 90054 90049 90020 0x17 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_LEGACY_BUS_INFORMATION 90023 90054 90049 90020 0x18 90023 90054 90059 90060 90061 90020 The WMI minor function codes are as follows: 90023 90042 90043 90044 90044 90046 90154 90048 90156 Minor Function Code 90157 90156 Hexadecimal Code 90157 90059 90161 90047 90048 90049 90020 IRP_MN_QUERY_ALL_DATA 90023 90054 90049 90020 0x00 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_SINGLE_INSTANCE 90023 90054 90049 90020 0x01 90023 90054 90059 90048 90049 90020 IRP_MN_CHANGE_SINGLE_INSTANCE 90023 90054 90049 90020 0x02 90023 90054 90059 90048 90049 90020 IRP_MN_CHANGE_SINGLE_ITEM 90023 90054 90049 90020 0x03 90023 90054 90059 90048 90049 90020 IRP_MN_ENABLE_EVENTS 90023 90054 90049 90020 0x04 90023 90054 90059 90048 90049 90020 IRP_MN_DISABLE_EVENTS 90023 90054 90049 90020 0x05 90023 90054 90059 90048 90049 90020 IRP_MN_ENABLE_COLLECTION 90023 90054 90049 90020 0x06 90023 90054 90059 90048 90049 90020 IRP_MN_DISABLE_COLLECTION 90023 90054 90049 90020 0x07 90023 90054 90059 90048 90049 90020 IRP_MN_REGINFO 90023 90054 90049 90020 0x08 90023 90054 90059 90048 90049 90020 IRP_MN_EXECUTE_METHOD 90023 90054 90049 90020 0x09 90023 90054 90059 90060 90061 90020 The power management minor function codes are as follows: 90023 90042 90043 90044 90044 90046 90154 90048 90156 Minor Function Code 90157 90156 Hexadecimal Code 90157 90059 90161 90047 90048 90049 90020 IRP_MN_WAIT_WAKE 90023 90054 90049 90020 0x00 90023 90054 90059 90048 90049 90020 IRP_MN_POWER_SEQUENCE 90023 90054 90049 90020 0x01 90023 90054 90059 90048 90049 90020 IRP_MN_SET_POWER 90023 90054 90049 90020 0x02 90023 90054 90059 90048 90049 90020 IRP_MN_QUERY_POWER 90023 90054 90049 90020 0x03 90023 90054 90059 90060 90061 90020 The SCSI minor function codes are as follows: 90023 90042 90043 90044 90044 90046 90154 90048 90156 Minor Function Code 90157 90156 Hexadecimal Code 90157 90059 90161 90047 90048 90049 90020 IRP_MN_SCSI_CLASS 90023 90054 90049 90020 0x01 90023 90054 90059 90060 90061 90028 See also 90029 90020 90021 IRP 90022 90023 90020 90021! Irpfind 90022 90023 90020 90021! Ioctldecode 90022 90023 .90000 WDM IRPs and WDF Event Callback Functions – Windows drivers 90001 90002 90003 90004 04/20/2017 90005 90006 90003 4 minutes to read 90006 90003 90010 90003 90006 90003 90006 90015 90006 90015 90018 In this article 90019 90020 Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF) support a subset of Windows IRPs.The following table lists the major WDM IRP types and the corresponding framework event callback functions. Unless otherwise specified, the callbacks apply to both KMDF and UMDF. 90021 90022 KMDF Callbacks for IRP_MJ_PNP 90023 90020 The following table lists, in order of execution, the KMDF callbacks that correspond to the minor IRP codes for 90025 IRP_MJ_PNP 90026. The arrows indicate whether a WDM FDO handles the IRP as it travels up or down the stack. 90021 90020 90025 Note 90026 In a KMDF driver, Plug and Play and power management are integrated operations and the driver does not receive the individual minor 90025 IRP_MJ_PNP 90026 or 90025 IRP_MJ_POWER 90026 requests.Instead, the framework calls a core set of callbacks at power up and a corresponding set at power down, and calls additional callbacks before and after this core set as appropriate for each individual Plug and Play request. For comprehensive diagrams that show the power-up and power-down sequences, see Porting PnP and Power Management Functionality. 90021 90022 KMDF Callbacks for IRP_MJ_POWER 90023 90020 The following table lists, in order of execution, the KMDF callbacks that correspond to the minor IRP codes for 90025 IRP_MJ_POWER 90026.The arrows indicate whether a WDM FDO handles the IRP as it travels up or down the stack. 90021 90020 90025 Note 90026 Note: In a KMDF driver, Plug and Play and power management are integrated operations and the driver does not receive the individual minor 90025 IRP_MJ_PNP 90026 or 90025 IRP_MJ_POWER 90026 requests. Instead, the framework calls a core set of callbacks at power up and a corresponding set at power down, and calls additional callbacks before and after this core set as appropriate for each individual Plug and Play request.For comprehensive diagrams that show the power-up and power-down sequences, see Porting PnP and Power Management Functionality. 90021 .