ПРОТОКОЛ 1-WIRE

1-Wire – протокол передачи данных в обе стороны по одному проводу.

Данный протокол разработан корпорацией Dallas Semiconductor (сейчас Maxim Integrated) в далёких 90-х, но активно используется и сейчас: именно на 1-Wire работает большинство «таблеток» — домофонных чипов (DS1990A), карточек доступа, а также через 1-Wire общаются популярные датчики температуры (DS18S20 и DS18B20), транзисторные ключи (DS2405, DS2406), программируемые порты ввода-вывода (DS2408), АЦП и ЦАП, часы реального времени (DS2417) и многое другое.

Режим связи в этом протоколе – асинхронный и полудуплексный (об этом подробнее тут), а также «остроконечный» (при отсылке многобайтовых целых передача идёт от младшего байта к старшему).

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

Ещё раз подчеркнём – на шине может быть только ОДИН ведущий – иначе возникнут конфликты, когда оба ведущих будут тянуть одеяло на себя (на самом деле, есть некоторые приёмы организации сетей 1-Wire в режиме мультимастера – например, с помощью ветвителя сети DS2409 – но в «обычной» жизни все-таки предпочтительней иметь только одного ведущего на шине).

Протокол 1-Wire хорош тем, что не сложен в реализации и требует для связи всего два-три провода (шина данных, земля и при необходимости питание); однако при этом он не лишён и недостатков – этот протокол весьма чувствителен ко времени и к помехам. Также 1-Wire не предназначена для передачи больших объёмов информации и для скоростного обмена данными – максимальная скорость 9600 Бод/с.

Протокол 1-Wire описывает физический, канальный, сетевой и транспортный уровни взаимодействия (см. модель OSI).
На физическом уровне даются описания способов подключения, требования к шине данных и питанию и т.д.
Канальный уровень описывает способы чтения и передачи битов по протоколу.
Сетевой уровень описывает способы адресации к различным устройствам на линии.
Наконец, транспортный уровень описывает функциональные команды, используемые устройствами 1-Wire.

ФИЗИЧЕСКИЙ УРОВЕНЬ ПРОТОКОЛА

Физически для организации интерфейса необходимы как минимум линия для данных и «земля»; достаточно часто также для подключения устройств необходима также линия питания, однако некоторые ведомые устройства могут питаться и паразитно – получать «подпитку» через шину данных.

Рисунок 1. Пример подключения ведущего и ведомых устройств по протоколу 1-Wire.

Упрощенный пример подключения шины представлен на рисунке 1: так, у нас есть ведущее устройство и три ведомых, Slave1, Slave2 и Slave3. Шина данных (data) подтянута резистором к питанию и к ней присоединены все четыре устройства; также каждое из устройств подсоединено к земле. Master, Slave2 и Slave3 подключены к питанию (от 3 до 5 В, в зависимости от требований устройств), а устройство Slave1 питается паразитно через шину данных (об этом подробнее ниже).

К слову, о питании – согласно даташиту, шина данных должна быть подтянута к питанию резистором 4.7 кОм, однако данный номинал используется при относительно коротких линиях; если же расстояние между устройствами достаточно велико, то сопротивление резистора можно уменьшить.

КАНАЛЬНЫЙ УРОВЕНЬ ПРОТОКОЛА

Обмен информацией ведётся так называемыми временными, или тайм-слотами (60 мкс): один тайм-слот служит для обмена одним битом информации. Данные передаются бит за битом, начиная с младшего бита младшего байта – это, кстати, достаточно часто приводит к ошибкам у новичков – кажется, что нужно передавать данные слева направо, так, как они хранятся в памяти (то есть, следите за словами: кажется, что нужно начинать со старшего бита младшего байта (вы уже запутались, да?) – но нет! При передаче по 1-Wire, например, двухбайтового числа порядок передачи будет таким:
Имеем число 1023410 – в двоичном виде выглядит так: 00100111 111110102
В памяти (так как у нас «остроконечный» порядок хранения данных) выглядит так: 11111010 00100111.
А передача по 1-Wire будет выглядеть так:
0→1→0→1→1→1→1→1→1→1→1→0→0→1→0→0
Если вы запутались так же, как и я – самое время выпить чая с шоколадкой и немного утрясти все в голове.

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

Внимание: ни ведущий, ни ведомые не выставляют на шине «единицу» — это черевато коротким замыканием: если одно устройство выставит на шине «1», а другое – «0»; поэтому как ведущий, так и ведомый могут использовать только два состояния: «на выход в ноль» и «z-состояние» (на вход без подтяжки). Подтяжка к питанию осуществляется резистором (!).

Рассмотрим 5 основных команд для связи по шине 1-Wire: «Запись 1», «Запись 0», «Чтение», «Сброс» и «Присутствие». При этом на рисунках красным выделено управление линией от ведущего, синим – управление линией от ведомого, черным – освобожденная линия (с помощью подтяжки шина автоматически переходит в «единицу»).

Сигнал «Запись 1». Ведущий устанавливает низкий уровень в течение 1…15 мкс. После этого, в течение оставшейся части временного слота он освобождает шину.

Сигнал «Запись 0». Ведущий формирует низкий уровень в течение не менее 60 мкс, но не дольше 120 мкс.

Сигнал «Чтение». Ведущий устанавливает низкий уровень в течение 1…15 мкс. После этого подчинённый, если хочет передать 0, удерживает шину в низком состоянии до 60 мкс; если же подчинённых хочет передать 1, то он просто освобождает линию. Ведущий обычно сканирует состояние шины по истечении 15 мкс после установки низкого уровня на шине.

Так, ведомый удерживает линию к земле, если хочет передать «0», и просто отпускает линию, если хочет передать «1».
Таким образом при чтении получаем следующие диаграммы.

Сигнал «Чтение при получении 1»:

Сигнал «Чтение при получении 0»:

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

Сигнал «Сброс/присутствие». Здесь временные интервалы импульсов отличаются. Ведущий устанавливает низкий уровень в течение 8 временных слотов (480 мкс), а затем освобождает шину. Данный длительный период низкого состояния называется сигнал «Сброс».
Если на шине присутствует подчинённый, то он должен в течение 60 мкс после освобождения ведущим шины установить низкий уровень длительностью не менее 60 мкс. Данный отклик носит название «Присутствие». Если такой сигнал не обнаруживается, то ведущий должен полагать, что нет подключённых устройств к шине и дальнейшая связь невозможна.
Данная связка сигналов всегда начинает любой обмен информацией между устройствами.
Помимо этого, нужно учитывать, что любое ведомое устройство после получения питания сразу же выдаёт сигнал присутствия.
Сигнал же «Сброс» позволяет ведущему досрочно завершить обмен информацией – например, если датчик температуры передаёт нам всю свою память, а нам нужны только первые два байта, которые содержат значение температуры, то после получения этих двух байт микросхема просто может опустить линию в ноль на нужное количество времени – датчик поймет, что больше ничего пересылать не нужно.

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

СЕТЕВОЙ И ТРАНСПОРТНЫЙ УРОВНИ ПРОТОКОЛА

Рассмотрим «более высокий» уровень протокола 1-Wire – последовательность действий при взаимодействии ведущего и ведомого, а также основные команды. При этом нужно отметить, все данные, в том числе команды, отсылаются побитно последовательно, начиная с младшего бита.

Алгоритм взаимодействия:

1. Ведущий посылает на линию сигнал reset («Сброс»). После линия освобождается для «ответных действий». Если на шине присутствует ведомый, то в течение 60 мкс он сообщает о «присутствии».
   Если же ведущий не получает отклика-«присутствия», то он считает, что подключённых к шине устройств нет.
2. Далее следует сетевой уровень протокола: ведущий должен определить, к какому из устройств на шине данных он будет дальше обращаться. Данный выбор обеспечивается отсылкой одной из ROM-команд (длиной в 1 байт), которые работают с уникальными кодами устройств:
   • Search ROM ($F0) – «поиск ROM». Если коды подключённых устройств не известны, то эта команда позволяет ведущему определить их. Подробное описание данной команды представлено ниже.
   • Read ROM ($33) – «чтение ROM» – команда используется, если мы точно знаем, что у нас только одно подчинённое устройство (например, только один датчик температуры или один домофонный ключ), тогда для считки его кода можно не париться с поиском ROM. При получении данной команды все ведомые устройства на шине отсылают свой уникальный код.
   • Skip ROM ($CC) – «пропуск ROM». Это команда используется, когда необходимо дать команду всем устройствам на шине – например, нужно, чтобы все подключённые датчики одновременно считали температуру.
   • Match ROM ($55) – «совпадение ROM». Используется для выбора конкретного подчинённого устройства на шине. После отсылки команды ведущий передаёт 64-разрядный код. По завершении только тому подчинённому устройству, которое приняло свой идентификатор, разрешается отвечать после приёма следующего импульса сброса – остальные же молча ждут импульса сброса.

   Естественно, для отдельных устройств какие-то ROM-команды могут добавляться.

3. Если были отправлены команды «Match ROM» или «Skip ROM», то далее ведущий отправляет какую-либо функциональную команду – это уже транспортный уровень протокола; при этом набор функциональных команд и дальнейшее поведение (должен ли ведущий быть готов принимать данные от выбранного ведомого устройства, например) зависит от конкретного устройства 1-Wire.

Так, например, если у нас есть микроконтроллер и DS18S20 – датчик температуры, и мы хотим получить от этого датчика значение температуры, то алгоритм работы будет следующим:

1. МК отсылает импульс сброса
2. Датчик отвечает импульсом приветствия
3. МК отсылает адресную команду «Skip ROM» — так как датчик у нас на линии один, то нам нет необходимости работать с «адресами»
4. МК отсылает функциональную команду «Convert T» — по этой команде датчик температуры начнёт однократное температурное преобразование; результат же этого преобразования будет записан в память датчика
5. МК ждёт, пока датчик закончит преобразование (ведомое устройство никоим образом не может само сообщить, что оно «освободилось», поэтому микроконтроллер просто ждёт время, указанное в даташите)
6. МК отсылает импульс сброса
7. Датчик отвечает импульсом приветствия
8. МК отсылает адресную команду «Skip ROM»
9. МК отсылает функциональную команду «Read Scratchpad» — по этой команде датчик отсылает 9 байт своей памяти
10. МК считывает нужное количество байт (значение температуры содержится в первых двух)
11. При необходимости МК завершает сеанс связи, отсылая импульс сброса

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

1. МК отсылает импульс сброса
2. Датчик коротит линию на ноль – МК обнаруживает, что есть импульс приветствия
3. МК отсылает адресную команду «Skip ROM» — не проверяя при этом линию, конечно
4. МК отсылает функциональную команду «Convert T» — датчик всё ещё в коме
5. МК ждёт
6. МК отсылает импульс сброса
7. история повторяется, датчик отсылает ноль
8. МК отсылает адресную команду «Skip ROM»
9. МК отсылает функциональную команду «Read Scratchpad»
10. МК считывает нужное количество байт — и получает, естественно, все нули. Даже если мы считываем всю память вместе с CRC, CRC от нуля будет равно нулю – то есть ошибки не произойдет МК конвертирует температуру, получает ноль, отправляет команду нагревать печь. И так до бесконечности!

Выглядит все это довольно печально – и черевато большими проблемами! Так что на протокол полагайся, но сам не плошай.

Вернёмся к алгоритму взаимодействия ведущего и ведомого по протоколу. Как видно, реализовать работу ведущего устройства не так уж сложно – при этом есть как уже готовые библиотеки с кодом, так и аппаратные реализации – например, от той же фирмы Maxim Integrated. Так, например, для AVR-ок написан целый даташит для реализации 1-Wire.

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

ПАРАЗИТНОЕ ПИТАНИЕ

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

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

Например, для датчика температуры DS18S20, использующего протокол 1-Wire, необходимо гарантировать, что на шине данных будет достаточное напряжение при выполнении температурного преобразования или при копировании данных из памяти EEPROM. Согласно даташиту, при этом рекомендуется подтягивать линию данных к питанию с помощью полевого транзистора; на деле же при использовании напряжения +5-+5.5 В микроконтроллеру достаточно просто не опускать шину данных в ноль (в случае именно с датчиком DS18S20 – другие датчики могут потреблять больше тока). Также именно паразитное питание является одной из причин, почему микроконтроллеру стоит передавать сигналы (то есть опускать линию данных в ноль) по минимальному времени – это позволяет устройствам на паразитном питании нормально функционировать.

К слову, не все авторы библиотек заморачиваются данным вопросом – так, при попытке заставить работать датчик DS18S20 на паразитном питании в среде MikroElectronika с использованием библиотеки этой среды датчик просто не получал достаточного питания и не мог нормально «общаться».

ОБЛАСТИ ПРИМЕНЕНИЯ

Существует целый ряд устройств, использующих интерфейс 1-Wire, — так, например, всем известная «таблетка» — домофонный ключ – работает в большинстве случаев именно через данный протокол: микроконтроллер в замке просто спрашивает уникальный код «таблетки», и если этот код содержится в списке разрешённых устройств, микроконтроллер открывает замок.

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

УНИКАЛЬНЫЕ КОДЫ УСТРОЙСТВ 1-WIRE

Пару слов об уникальных кодах устройств, с которыми и работают ROM-команды. Каждое «одноварное» устройство имеет свой 64-хбитный код, состоящий из трёх частей:

Младший байт – это код семейства, к которому относится устройство, 6 следующих байт – уникальный в семействе серийный номер, ну и наконец, старший байт – это CRC, который служит для проверки правильности приёма всего кода. Так, например, на родных даллосовских (сейчас максимовских) «таблетках» часть уникального кода – а именно, 48-битный серийный номер – пишется на металле в шестнадцатиричном виде (все дружно посмотрели на свои домофонные ключи).

Рассмотрим подробнее, какие коды семейств устройств 1-Wire бывают:

Код семейства (HEX)	Устройство iButton	Описание
01	DS1990A, DS1990R, DS2401, DS2411	Уникальный серийный номер-ключ
02	DS1991	Мультиключ, 1152-битная защищённая EEPROM
04	DS1994, DS2404	4 КБ NV RAM + часы, таймер и будильник
05	DS2405	Одиночный адресуемый ключ
06	DS1993	4 КБ NV RAM
08	DS1992	1 КБ NV RAM
09	DS1982, DS2502	1 КБ PROM
0A	DS1995	16 КБ NV RAM
0B	DS1985, DS2505	16 КБ EEPROM
0C	DS1996	64 КБ NV RAM
0F	DS1986, DS2506	64 КБ EEPROM
10	DS1920, DS1820, DS18S20, DS18B20	Датчик температуры
12	DS2406, DS2407	1 КБ EEPROM + двухканальный адресуемый ключ
14	DS1971, DS2430A	256 бит EEPROM и 64 бита PROM
1A	DS1963L	4 КБ NV RAM + счётчик циклов записи
1C	DS28E04-100	4 КБ EEPROM + двухканальный адресуемый ключ
1D	DS2423	4 КБ NV RAM + внешний счётчик
1F	DS2409	Двухканальный адресуемый ключ с возможностью коммутации на возвратную шину
20	DS2450	Четырёхканальный АЦП
21	DS1921G, DS1921H, DS1921Z	Термохронный датчик с функцией сбора данных
23	DS1973, DS2433	4 КБ EEPROM
24	DS1904, DS2415	Часы реального времени
26	DS2438	Датчик температуры, АЦП
27	DS2417	Часы реального времени с прерыванием
29	DS2408	Двунаправленный 8-разрядный порт ввода/вывода
2C	DS2890	Одноканальный цифровой потенциометр
2D	DS1972, DS2431	1 КБ EEPROM
30	DS2760	Датчик температуры, датчик тока, АЦП
37	DS1977	32 КБ защищённой паролем EEPROM
3A	DS2413	Двухканальный адресуемый коммутатор
41	DS1922L, DS1922T, DS1923, DS2422	Термохронные и гигрохронные датчики высокого разрешения с функцией сбора данных
42	DS28EA00	Цифровой термометр с программируемым разрешением, возможностью работать в режиме подключения к последовательному каналу и программируемыми портами ввода/вывода
43	DS28EC20	20 КБ EEPROM

NV RAM – Non-Volatile Random-Access Memory (энергонезависимое ОЗУ)
PROM – Programmable Read-Only Memory (однократно программируемое ПЗУ)
EEPROM – Electrically Erasable Programmable Random-Access Memory (электрически стираемое перепрограммируемое ПЗУ)

ПРО КОМАНДУ SEARCH ROM (F0H):

По мотивам статьи Чернова Геннадия.
Если ведущий не знает серийный номер устройств, подключенных к шине, то существует возможность идентифицировать коды ROM каждого устройства – для этого необходимо использовать команду «Search ROM» [F0h]. Эта команда действует как команда «Read ROM», объединенная с командой «Match ROM».

Процесс идентификации кодов ROM ведомых устройств выглядит так:

После формирования мастером команды «Search ROM» все устройства посылают на шину значение своего младшего бита; при этом сначала в течение одного такта ведомыми посылается «прямое» значение бита, а в течение следующего такта – «обратное» (логическое НЕ, дополнение) значение этого же бита.
Тогда мастер может считать следующие последовательности:

• «01» — если у всех ведомых устройств младший бит равен «0» (сначала они отсылают «0», потом {НЕ «0»} = «1»)
• «10» — если у всех ведомых устройств младший бит равен «1»
• «00» — если есть так называемый конфликт – у некоторых устройств младший бит равен «1», у остальных – «0». Тогда при передаче «прямого» значения устройства с «0» опускают линию, при передаче «обратного» — устройства с «1» также опускают линию.

Далее мастер в следующем временном слоте отсылает «0» или «1», таким образом определяя, с какими устройствами дальше будет общаться – все устройства, у которых младший бит не соответствует биту, сформированному мастером на этом этапе, перейдут в состояние ожидания и будут находиться в нём, пока не получат импульс сброса. Затем происходят аналогичные 63 цикла чтения-выбора, пока, наконец, ведущее устройство не определит код ROM одного из подчинённых устройств и не обратится к нему.
Для мастера каждая стадия выбора состоит из двух тайм-слотов чтения и одного тайм-слота записи.

Разберем работу команды «Search ROM» на примере.

Пусть на шине установлено четыре ведомых устройства со следующими значениями кодов:
устройство 1: xxxxxx10101100
устройство 2: xxxxxx01010101
устройство 3: xxxxxx10101111
устройство 4: xxxxxx10001000
для упрощения символом «x» заменены старшие биты и показаны только младшие восемь битов

Поиск младшего бита происходит следующим образом:

1. Ведущее устройство начинает последовательность инициализации – формирует импульс сброса; ведомые устройства отвечают импульсами присутствия.
2. Ведущее устройство формирует команду «Search ROM».
3. Ведущее устройство читает два бита с шины. Сначала каждое ведомое устройство ответит, помещая значение первого бита, соответствующего его данным ROM. Устройства 1 и 4 поместят «0» на шину, то есть, они установят на шине низкий уровень. Устройства 2 и 3 сформируют «1», позволяя на линии оставаться в высоком уровне. Результат – «логическое И» всех устройств на линии; поэтому мастер читает 0.
   Следует отметить, что с тех пор, как ведущий послал команду «Search ROM», все ведомые устройства отвечают одновременно.
   Далее мастер читает следующий бит. Все устройства помещают на шину дополнение их первого бита. Устройства 1 и 4 сформируют «1»; устройства 2 и 3 сформируют «0». Таким образом, на шине будет состояние логического «0». Мастер снова читает «0» при формировании дополнительного кода первого информационного разряда ROM (чтение дает «00» — состояние разрядных конфликтов). Это говорит ведущему устройству, что есть устройства на шине содержащие в первом бите как «0», так и «1».
   Если бы все устройства имели «0» в этой позиции двоичного разряда, чтение дало бы результат «01«; если бы позиция двоичного разряда содержала во всех устройства «1» результат был бы «10«.
4. Ведущее устройство решает далее анализировать устройства с нулём в младшем бите — формирует запись «0» на шину. Эта операция переводит устройства 2 и 3 (содержащие в этом разряде «1») в пассивное состояние, оставляя только устройства 1 и 4 для участия в процессе поиска.
5. Мастер выполняет еще два чтения и получает «01». Это говорит, что все активные устройства имеют 0 в этой позиции двоичного разряда их ROM.
6. Мастер тогда пишет 0, чтобы сохранить устройства 1 и 4 активными.
7. Мастер выполняет два чтения и получает «00». Это снова указывает, что у устройств на линии в этом разряде есть как «1», так и «0.
8. Мастер снова пишет 0. Это деактивирует устройство 1, оставляя устройство 4 единственным активным элементом.
9. Следующие чтения до конца ROM не будут давать состояние разрядных конфликтов. Отсутствие разрядных конфликтов до конца цикла поиска говорит, что происходит чтение ROM только одного активного элемента. Прочитав следующий бит, мастер снова посылает этот бит, чтобы сохранить устройство активным. Как только все биты ROM устройства известны и последний бит снова послан Главным устройством, устройство готово принять функциональную команду (для обмена информацией).
10. Ведущее устройство должно изучить данные ROM других устройств. Поэтому оно запускает следующую последовательность Поиска ROM, повторяя шаги 1-7.
11. B самой старшей позиции двоичного разряда, где ведущее устройство писало «0» в первом проходе (шаг 8), оно теперь пишет «1». Это снимает выделение устройства 4, оставляя теперь устройство 1 активным.
12. Как в шаге 9, следующие чтения до конца ROM не будет давать состояние разрядным конфликтам. Этим заканчивается второй Поиск ROM, где мастер считывает содержание ROM другого устройства.
13. Ведущее устройство должно изучить данные ROM других устройств. Поэтому оно запускает следующую последовательность Поиска ROM, повторяя шаги 1-3.
14. Во втором проходе в наивысшей степени позиция двоичного разряда, где мастер отсылал «0» в первом проходе (шаг 4), теперь он пишет «1». Это снимает выделение устройств 1 и 4, оставляя устройства 2 и 3 активными.
15. Ведущее устройство считывает «00» — разрядный конфликт.
16. Мастер отсылает «0». Это снимает выделение устройства 3, оставляя устройство 2 как единственное активное устройство.
17. Как в шаге 9, следующие чтения до конца ROM не будет показывать разрядным конфликтам. Этим заканчивается третий Поиск ROM.
18. Ведущее устройство должно изучить данные ROM других устройств. Поэтому оно запускает следующую последовательность Поиска ROM, повторяя шаги 13 — 15.
19. В самой высокой позиции двоичного разряда, где мастер отсылал «0» (шаг 16), теперь он отсылает «1». Это снимает выделение устройства 2, оставляя устройство 3 активным.
20. Как в шаге 17, следующие чтения до конца ROM не будут показывать разрядным конфликтам. Это заканчивает четвертый Поиск ROM.

Иными словами, в процессе поиска ROM мы строим одно или два двоичных дерева размером 64 (длина кода ROM), с корнями в виде значений младшего бита и листьями в виде значений старшего байта кода ROM.
Время, требуемое для считывания содержания одного ROM (без учёта процессорного времени мастера) = 960 мкс + (8 + 3*64) *61 мкс =13.16 мс.

Автор — Moriam

Понравилось? Поделитесь:

↑Как установить такие кнопки?↑

: