5.3.6. Протоколы, поддерживаемые на уровне загружаемого микрокода

Apple Talk-контроллер. Стек протоколов Apple Talk разработан фирмой «Apple Computer» для объединения в сеть компьютеров Macintosh. Протоколы Apple Talk могут использовать для передачи данных по физическому и канальному уровням управления многие протоколы других фирм-производителей, например протокол Ethernet. Но в стеке протоколов Apple тоже есть протокол канального уровня Local Talk, который основан на создании HDLC-канала и который обеспечивает на физическом уровне управления ско­рость передачи 230,4 Кбит/с.

Контроллер Apple Talk реализуется в МРС860 при помощи настроек HDLC-контрол-лера и за счет изменения установки отдельных бит в регистрах настройки, он обеспечи­вает работу SCC-канала с протоколом Local Talk, а также необходимую синхронизацию кадра, порядок битов, преамбулу и закрывающую ABORT-последовательность для HDLC-кадра. Таким образом, в основе кадра Apple Talk лежит HDLC-кадр с его управляющими полями и процедурами. Сам Apple Talk-контроллер только добавляет поля, необходи­мые для передачи этого кадра по сети APPLE. Благодаря этой особенности HDLC-koh-троллер при работе с FMO-способом кодирования данных может быть легко настроен на работу с кадрами Local Talk Bus. Карта памяти параметров HDLC-контроллера и кон­троллера Apple Talk совпадают, так как оба эти контроллера используют одинаковые ал­горитмы обработки и контроля на канальном уровне управления. Формат кадра протоко­ла Apple Talk представлен на рис. 5.141.

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

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

Таким образом, при передаче кадра данных контроллер Apple Talk автоматически встав­ляет/добавляет начальную синхропоследовательность из 6 бит (preamble) и конечную за­рывающую последовательность из 16 единичных бит (postamble). При приеме получение 6-битной последовательности не вызывает дополнительного CD-прерывания.

Для обнаружения следующего далее полудуплексного HDLC-кадра передается не менее двух открывающих HDLC-флагов. Размер полей адреса и контроля соответствуе-требованиям HDLC-протокола. В поле данных может быть передано до 600 байт инфор­мации. Двухбайтное поле контрольной суммы используется для хранения 16-битногс проверочного кода, вычисленного с использованием циклических полиномов. HDLC-кадр закрывается 8-битным закрывающим флагом. Формат полей флага 01111110 совпадает с форматом флага в протоколе HDLC. Кадр Local Talk закрывается специальным фла­гом, состоящим из 12-18 (обычно 16) «единичных» бит. Такой набор единичных бит бу­дет воспринят HDLC-приемником как ABORT-последовательность. После передачи кад­ра передатчик выключается.

При передаче контроллер получает из буфера данные полей адресов, контроля v данных и добавляет поле контрольной суммы, два флага HDLC-кадра и две последова­тельности кадра Apple Talk.

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

Хотя поле контроля имеет одинаковый размер в кадрах Local Talk и HDLC, назначе­ние его различно. В поле контроля HDLC-протокола передается информация, управляю­щая процессом передачи и контроля последовательности пакетов. В Local Talk-протоко­ле содержимое этого поля определяет тип кадра и тип передаваемой в поле данных информации. Если в поле содержится код от 0x01 до 0x7F, то это информационный кадр. а если код от 0x80 до 0xFF, то это управляющий кадр. В протоколе Local Talk определены 4 типа управляющих кадров:

1. кадр запроса ENQ (enquiry);

2. кадр подтверждения запроса АСК (ENQ acknowledgment);

3. запрос для передачи данных RTS (request to send data frame);

4. разрешение передачи данных CTS (clear to send data frame).

Процесс передачи группы кадров называется диалогом и обычно управляется про­граммным обеспечением пользователя. Обычно диалог состоит из трех основных кад­ров. Если станция желает передать данные, она посылает кадр запроса на передачу RTS, указав в поле адреса свой адрес и адрес получателя. Если станция-получатель готова, то она посылает кадр разрешения передачи CTS к станции отправителя запроса. Далее передается кадр данных. Эти три кадра определяют один из возможных типов диалога. Другие станции, не участвующие в диалоге, вынуждены ждать, пока диалог бу­дет закончен. Кадры внутри диалога передаются с максимальным межкадровым интер­валом 200 мс (IFG-interframe gap). Минимальное значение IFG = 50 мс. Интервал между диалогами IDG (interdialog gap) должен быть не менее 400 мс.Все эти временные интервалы

контролируются программным обеспечением.

Коллизия может возникнуть в сети только при передаче кадра RTS и ENQ-кадров. Если обнаружена коллизия, то текущая передача кадров станциями не прекращается и доводится до конца.

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

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

Для кодирования данных используется способ FM0. При этом «1» кодируется перепа­дом сигнала в начале битового интервала, а «0» -двумя перепадами сигнала: первый в начале, второй - в середине битового интервала. Под перепадом следует понимать сме­ну состояния или уровня сигнала не. противоположное. Способ FM0 позволяет переда­вать тактовую частоту прямо в закодированных данных и не использовать дополнитель­ные линии для передачи тактовых сигналов. Специальная SYNC-последовательность «начало кадра Local Talk» позволяет приемнику распознать частоту передачи и подстро­ить свой тактовый генератор.

Передача выполняется в полудуплексном режиме, и приемник на время передачи находится в выключенном режиме.

Для того чтобы контроллер Apple Talk получил непосредственный доступ к физичес­кому уровню управления сети, необходимо на его выходах подключить микросхему RS-422 передатчика (transceiver). Для обмена сигналами с RS-422 передатчика используют­ся всего три сигнала SCC-канала; TxD, RxD и rts , который используется для стробирования передачи данных. Сигнал rts равен нулю во время передачи всего кадра данных контроллера Apple Talk и используется для управления RS-422 передатчиком. Пример построения сети Apple Talk показан на рис. 5.142.

Для синхронизации работы приемника и передатчика тактовая частота в 3,686 МГц может быть получена или от внешнего источника, или от внутреннего BRG-генератора.

При выполнении операции oversampling контроллер протоко­ла Apple Talk производит внутрен­нее увеличение частоты в 16х раз. Кроме вышеперечисленных особенностей, функционирование контроллера Apple Talk полностью совпадает с работой HDLC-koh-троллера, поэтому настройки реги­стров режима совершенно анало­гичны. Только при настройке реги­стров GSMR и PSMR следует учи­тывать специфические режимы работы контроллера Apple Talk.

Рис. 5.142. Пример построения сети Apple Talk

Настройки регистра GSMR и PSMR для работы с AppleTalk:

1. Бит GSMR[MODE] := 0010 - произведена настройка для работы с протоколом Apple Talk.

2. Биты GSMR[ENR] := 1 и GSMR[ENT] := 1 - разрешена работа приемника и пере­ датчика.

3. Биты GSMR[DIAG] := 00 - контроллер SCC-канала настроен на нормальный режим работы с использованием внешних сигналов и

4. Биты GSMR[RDCR] := 10 и GSMR[TDCR] := 10-для приемника и передатчика уста­ новлено внутреннее увеличение частоты в 16х раз.

5. Биты GSMR[RENC] := 010 и GSMR[TENC] := 010 - для приемника и передатчика установлен способ кодирования/декодирования данных FM0.

6. Бит GSMR[TEND] := 0 - данные на линии TxD при передаче кодируются FM0- способом. В пассивном состоянии на линию TxD выдается постоянный уровень «1» без кодирования.

7. Биты GSMR[TRR] := 11 - формат преамбулы - все биты равны «1».

8. Биты GSMR[TPL] равны 000, если между кадрами не нужна синхронизирующая рreamble-последовательность, или равны 001, если следующий кадр Apple Talk переда­ ется с 6-битной синхропоследовательностью..

9. Биты GSMR[TINV] = GSMR[RINV] := 0 - при кодировке данных способом FM0 до­полнительное инвертирование не используется.

10. Биты GSMRfTSNC] := 10 - следующий перепад сигнала на линии RxD должен произойти через 1,5 битовых интервала увеличенной в 16х тактовой частоты. Этот бит определяет, сколько битовых интервалов внутреннего сигнала будет показывать свобод­- ный канал после начала передачи по RxD-линии. В контроллере Apple Talk эта задержка используется, чтобы не вызвать CD-прерывания при приеме первой 6-битной синхропос- ледовательности.

11. Биты GSMR[EDGE] := 00 - линии данных будут анализироваться блоком DPLL и по положительному перепаду тактового сигнала, и по отрицательному.

12. Бит GSMR [RTSM] := 0 - при передаче кадров сигнал будет сбрасываться

( = 1) в интервале между кадрами и устанавливаться ( = 0) при передаче кадра. В перерыве между кадрами передаются IDLE-символы, как определено битом TEND. Если бит RTSM = 1, то сигнал равен нулю всегда после включения SCC-канала в работу, даже когда в интервале между кадрами передаются символы флага или IDLE.

Настройка всех остальных бит производится как в HDLC-контроллере и согласно ре­жимам, выбранным пользователем.

Настройка регистра режима PSMR производится так же, как для HDLC-протокола:

1. Биты PSMR[NOF] := 0001 - между кадрами передаются два флага: один - открыва­ ющий, второй -дополнительный.

2. Бит PSMR[CRC] := 00 -для контроля используется 16-битный CRC-CCITT

полином.

3. Бит PSMR[DRT] := 1 -при передаче данных приемник временно выключается, пока сигнал = 0.

Другие биты регистра PSMR либо сбрасываются в «0», либо принимают значения по умолчанию.

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

BISYNC-контроллер может функционировать в двух режимах работы (нормальной передачи - «режим nontransparent» и прозрачной передачи «режим transparent») и под­держивает работу с немультиплексируемым интерфейсом NMSI и мультиплексируемы­ми интерфейсами IDL , GCI, РСМ.

Протокол поддерживает три типа кадров: Transparent - для «прозрачной» передачи данных, Transparent with header - для передачи команд управления и служебной инфор­мации и Non Transparent without header-для непрозрачной передачи данных (рис. 5.143). Каждый кадр начинается с двух 8-битных синхросимволов SYN1 и SYN2 , которые обес­печивают взаимную синхронизацию приемника и передатчика, и заканчивается 16-бит­ным полем контрольной суммы блока ВСС. Приемник автоматически выделяет символы синхронизации из входного потока и удаляет их.

Если контроллер работаете 8-битными символами, то для вычисления контрольной суммы ВСС применяется 16-разрядный циклический код CRC16. Если же контроллер использует 7-битные символы, то применяется комбинация вертикальной контрольной суммы (VRC parity) и горизонтальной контрольной суммы (LRC).

Служебный символ SOH (Start of Heading) определяет начало заголовка сообщения. В заголовок сообщения обычно включают информацию, требующуюся для выполнения функций адресации, управления потоком данных и маршрутизации.

Текст в поле данных выделяется служебными символами «старт текста» (STX) и «ко­нец текста» (ЕТХ). В режиме прозрачной передачи поле данных является бит-ориенти­рованным, т. е. допускаются любые комбинации битов. Для выделения прозрачной части кадра введен специальный 8-битный символ DLE (Data Link Escape), который сигнализи­рует, что дальше до следующего символа DLE следует текст, а не контрольные символы из таблицы служебных символов. Если символ DLE должен быть передан в тексте как данные, то ему должен предшествовать дополнительный DLE-символ. Этот дополни­тельный DLE-символ вставляется при передаче и автоматически удаляется при приеме (процедура byte-stuffing). Формат символа DLE задается пользователем в ячейке BDLE памяти параметров BISYNC-контролпера (рис. 5.144).

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

Если при приеме данных в прозрачном режиме работы приемник получил DLE-символ и установлен бит V= 1 в ячейке BDLE памяти параметров, то контроллер удаляет этот символ и не учитывает его при подсчете контрольной суммы блока BSC. Если следу­ющим принят символ SYNC, то контроллер его тоже отбрасывает и не учитывает при подсчете контрольной суммы. Если же второй принятый символ - DLE, то он записывает­ся в буфер приема и учитывается при подсчете BSC. Если следующий принятый символ и не DLE, и не SYNC, то контроллер проверяет его на совпадение в таблице служебных символов. Если этот символ не является и контрольным, то буфер приема закрывается и регистрируется ошибка «некорректного символа, следующего за DLE-символом». При­знаком этой ошибки является установка бита DLE := 1 в слове состояния буфера приема. Если же бит V = 0, то контроллер воспринимает этот символ как корректный и записыва­ет его в буфер приема.

Формат символа SYNC задается пользователем в регистре BSYNC памяти парамет­ров (см. рис. 5.144). Если во время нормальной непрозрачной (nontransparent) передачи данных обнаруживается ошибка незаполнения буфера FIFO передатчика underrun, то контроллер начинает передавать в канал связи SYNC-символы, пока не будут подготов­лены следующие данные для передачи.

Если контроллер работает в нормальном режиме (не режим «охоты» hunt) и в ячейке BSYNC установлен бит V = 1, то при приеме SYNC-символы будут отбрасываться. Если бит V = 0, то принятый SYNC-символ воспринимается как обычные данные и записыва­ется в память.

Выбор протокола BISYNC производится в битах MODE в регистре GSMRJ-, а кон­фигурирование режимов работы BISYNC-контроллера выполняется в регистре PSMR (рис. 5.145).

Если система сконфигурирована так, что выводы RXD и TXD объединены в одну шину, и передача идет в режиме полудуплексного обмена, то пользователь, установив бит DRT := 1 в регистре PSMR, может на время работы передатчика выключать работу приемника, чтобы не принимать собственную передаваемую информацию.

Бит RVD определяет порядок передачи битов внутри байтов данных в канал. Если бит равен нулю, то первым передается LSB-бит, это нормальный режим. Если бит равен единице, то первым в канал передается MSB-бит, это инверсный режим.

Распределение памяти параметров BISYNC-контроллера в микроконтроллере МРС860 приведено в табл. 5.84.

Передача данных. Когда центральный процессор устанавливает бит ENT := 1, BISYNC-контроллер включается в работу, него передатчик начинает передавать в канал симво­лы синхронизации. Бит RTSM в регистре GSMRH определяет тип синхросимволов. Если бит RTSM=1, то контроллер передает синхросимволы SYN1 и SYN2, формат которых определен в регистре синхросимволов DSR. Если бит RTSM = 0, то передатчик передает в канал связи для синхронизации IDLE-символы («все 1»).

Далее контроллер опрашивает первый буфер в таблице дескрипторов передачи и, если он готов, начинает передачу сообщения. Перед началом передачи в канал всегда предварительно передается не менее одной пары синхросимволов SYN1 и SYN2 для синхронизации приемника. Биты NOS в регистре PSMR определяют минимальное число пар синхросимволов, которые передаются между сообщениями или перед новым сооб­щением. Число пар символов SYN1-SYN2 равно ([NOS3-NOS0J+1).

Когда буфер данных полностью передан, контроллер сбрасывает бит R := 0 и прове­ряет бит L в его слове состояния. Если бит L = 1 и бит ТВ = 1, то контроллер добавляет к кадру данных поле контрольной суммы блока CRC16 или LRC и завершает передачу всего кадра. По окончании передачи кадра в слове состояния последнего буфера уста­навливаются биты статуса переданного сообщения. Перед началом передачи следую­щего сообщения в канал выдается заданное число символов синхронизации. Если бит L = 0, т. е. сообщение занимает несколько буферов, то контроллер переходит к передаче следующего буфера данных.

Если следующий буфер данных еще не готов, то регистрируется ошибка незаполне­ния underrun, и BISYNC-контроллер начинает передавать в канал символы синхрониза­ции SYN1-SYN2 или IDLE-символы. Если же контроллер работает в прозрачном режиме работы, он начинает передавать пары символов DLE-SYNC.

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

Биты CRC в регистре PSMR определяют тип контрольной суммы, которая может вычисляться по двум алгоритмам. Если биты CRC = 01, то 8-битные данные кодируют­ся с использованием 16-разрядного циклического кода с полиномом Х^{^}16+Х^{^}15+Х^{^}12+1. Если биты CRC = 11, то 7-битные данные кодируются при помощи комбинации горизон­тальной контрольной суммы LRC и вертикальной контрольной суммы VRC (контроль четности). Сумма LRC вычисляется как операция «исключающего ИЛИ» XOR всех 7-битных символов. Контроль VRC используется для заполнения восьмого незанятого бита (бит контроля или parity-бит) и представляет собой контроль по четности/нечетнос­ти, как определено в битах ТРМ в регистре PSMR (табл. 5.85).

Таблица 5.85 Тип контроля в сети

Вычисление контрольной суммы производится побуферно. Если в слове состояния текущего буфера бит В = 1, то содержимое буфера участвует в подсчете контрольной суммы. Если же бит В = 0, то содержимое буфера игнорируется при подсчете контрольной суммы. Если же в слове состояния текущего буфера установлен бит BR = 1, то BISYNC-контроллер перед передачей текущего буфера сбросит счетчик контрольной суммы BCS. Обычно этот сброс производится при передаче специфичных буферов, например, со­держащих символы начала блока STB или начала текста STX. Если бит BR = 0, то сброс счетчика BCS не производится.

Если BISYNC-контроллер работает в прозрачном режиме передачи, то перед каждым DLE-символом в кадре вставляется дополнительный DLE-символ, но при подсчете конт­рольной суммы учитывается только первый DLE-символ.

Пользователь может управлять работой передатчика BISYNC-контроллера при по­мощи команд RESTART TRANSMIT, STOP TRANSMIT, GRACEFUL STOP TRANSMIT, INIT TX PARAMETERS.

При передаче кадра данных контролируются ошибки незаполнения и потери сигнала cts . Ошибка незаполнения underrun возникает, когда RISC-процессор не успевает под­готовить новые данные в ячейке буфера FIFO передатчика. При возникновении этой ошибки контроллер прекращает передачу текущего буфера, закрывает буфер, устанав­ливает бит ошибки UN := 1 в его слове состояния и бит ТХЕ := 1 в регистре событий канала, вызывая маскируемое прерывание центрального процессора. Передатчик во­зобновит свою работу после получения команды RESTART TRANSMIT. Ошибка underrun не регистрируется в интервале между передачей отдельных кадров и при передаче пары символов DLE-XXX в прозрачном режиме работы.

В контроллере МРС860 размер буфера FIFO передатчика должен быть установлен равным 32 байтам для канала SCC1 и 16 байтам - для других SCC-каналов (бит TFL = 0 в регистре GSMR_H).

Ошибка потери сигнала cts возникает, если при передаче сигнал CTS станет пассив­ным (CTS= 1). При возникновении этой ошибки канал прерывает передачу, закрывает буфер передачи, устанавливает бит ошибки СТ := 1 в слове состояния буферного дескрип­тора и бит ТХЕ := 1 в регистре событий канала, вызывая прерывание центрального про­цессора. Передача будет возобновлена после получения команды RESTART TRANSMIT.

Прием данных. При приеме данных BISYNC-контроллер без вмешательства централь­ного процессора выполняет обработку кадра данных: подсчет и сравнение контрольной суммы блока BCS (CRC16 или LRC, VRC), удаление символов SYNC в нормальном ре­жиме передачи , удаление пар символов DLE-SYNC и первого DLE-символа в паре DLE-DLE при работе в прозрачном режиме передачи, сравнение принятого символа со слу­жебными символами в таблице контрольных символов.

После включения приемника в работу (бит ENR = 1) канал переходит в режим поиска -ового кадра (hunt mode). Начало нового кадра обнаруживается при приеме символов 3YN1-SYN2, формат которых задан в регистре синхросимволов DSR. Прием этих симво-гов выполняет синхронизацию кадра данных, далее контроллер начинает прием и обра­ботку самого кадра.

Возврат в режим hunt будет возможен или когда контроллер получит от центрального процессора команду ENTER HUNT MODE, или если при приеме будет обнаружена ошибка, или если будет принят определенный контрольный символ.

Бит RTR определяет режим работы приемника. Если бит RTR = 0, то приемник рабо­тает в нормальном режиме с распознаванием и удалением SYNC-символов и анализом служебных символов. Если бит RTR = 1, то приемник работает в режиме прозрачного обмена (в этом режиме всегда вычисляется контрольная сумма CRC16).

При приеме каждого байта данных контроллер подсчитывает контрольную сумму при­нятых данных и обновляет значение бита CR в слове состояния буферного дескриптора. При этом контроллер при приеме очередного байта данных делает паузу в восьми пери­одах тактового сигнала приемника RCLK перед включением этого байта в расчет конт­рольной суммы BCS. В течение приема следующего байта пользователь может устано­вить бит RBCS = 0 в регистре PSMR, и тогда предыдущий принятый байт будет исключен из расчета контрольной суммы BCS. Если же бит RBCS = 1, то принятый байт будет включен в подсчет контрольной суммы.

Если выбран подсчет LRC контрольной суммы, то бит RPM определяет тип контроля по четности/нечетности (табл. 5.86) для приемника.

Таблица 5.86

Когда буфер приема будет полностью заполнен, контроллер сбрасывает бит пустого буфера Е := 0, и если установлен бит I = 1, то генерирует маскируемое прерывание к цент­ральному процессору. Если размер принимаемых данных больше, чем установленная длина буфера приема, то контроллер проверяет бит незанятости следующего буфера в таблице RxBD, и если этот бит равен Е = 1, то продолжает прием данных в новый буфер.

Когда принимается поле BCS, BISYNC-контроллер сравнивает подсчитанное значе­ние контрольной суммы блока с содержимым этого поля и записывает его в буфер. По­скольку это было последнее поле кадра, контроллер устанавливает в слове состояния буфера бит последнего буфера кадра L = 1, записывает биты статуса принятого кадра и сбрасывает бит Е := 0. Затем контроллер генерирует маскируемое прерывание к цент­ральному процессору, уведомляя его, что блок данных принят и находится в памяти.

Пользователь может управлять работой приемника BISYNC-контроллера при помо­щи команд INIT RX PARAMETERS, ENTER HUNT MODE, CLOSE RX BD, RESET BCS CALCULATION. Команда RESET BCS CALCULATION обычно передается контроллеру после того, как получен и проанализирован контрольный символ начала блока, напри­мер символы STX или SOH, чтобы для последующих данных нового блока данных прове­сти независимый подсчет контрольной суммы.

При приеме кадра данных контролируются ошибки переполнения, ошибки проверки бита контроля, ошибки проверки контрольной суммы и ошибки потери сигнал

Ошибка переполнения overrun возникает, когда RISC-процессор не успевает осво­бождать ячейки буфера FIFO приемника, и BISYNC-контроллер вынужден записывать новые данные поверх старых, в результате старые данные теряются. При возникновении этой ошибки канал прекращает прием данных, закрывает буфер приема, устанавливает бит ошибки OV := 1 в слове состояния буферного дескриптора и бит RX := 1 в регистре событий, вызывая запрос на прерывание.

В контроллере МРС860 размер ячейки буфера FIFO приемника должен быть уста-­ новлен равным 8 битам (бит RFW = 1 в регистре GSMRH). При этом размер буфера FIFO будет установлен равным 8 байтам для канала SCC1 и 4 байтам для других SCC- каналов.

Ошибка потери сигнала CD возникает, если при приеме данных этот сигнал стано­вится пассивным (CD = 1). При возникновении этой ошибки канал прекращает прием данных, закрывает буфер, устанавливает бит ошибки CD:=1 в слове состояния буферно­го дескриптора и бит RX := 1 в регистре событий BISYNC-контроллера, вызывая запрос на прерывание. Эта ошибка имеет самый высокий приоритет среди других ошибок при­ема, и при ее возникновении другие ошибки не проверяются.

При приеме сообщений BISYNC-контроллер постоянно проверяет полученные дан­ные по четности/нечетности. Если возникает ошибка четности (parity), то канал записы­вает последний принятый символ в буфер, прекращает дальнейший прием данных, закрывает буфер приема, устанавливает бит ошибки PR := 1 в его слове состояния и бит RX := 1 в регистре событий, а также увеличивает на единицу счетчик ошибок четно­сти/нечетности в ячейке PAREC памяти параметров BISYNC-контроллера.

При возникновении всех вышеперечисленных ошибок приема контроллер немедлен­но переходит в режим поиска новых кадров (hunt mode).

Во время приема каждого символа BISYNC-контроллер постоянно, с задержкой в во­семь периодов тактовой частоты приема RCLK обновляет значение бита CR в слове состояния текущего буфера приема. Контроллер, получив служебный символ окончания блока данных, завершает вычисление контрольной суммы CRC и сравнивает ее со зна­чением в поле CRC, которое следует сразу за символом окончания блока. Если обнару­жено несовпадение подсчитанной и полученной контрольных сумм, то контроллер запи­сывает полученную CRC-сумму в буфер приема, закрывает буфер, устанавливает бит ошибки CR := 1 в слове состояния буферного дескриптора и бит RX := 1 в регистре собы­тий канала, вызывая маскируемое прерывание центрального процессора.

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

Второй способ более эффективен, так как используется при приеме данных в многобу­ферную структуру. Программное обеспечение пользователя, анализируя первые биты бу­фера приема, определяет, какой тип кадра или блока принимается контроллером, и произ­водит дополнительные настройки режима приема. Приход контрольного символа может информировать контроллер, что закончен прием текущего блока данных и ожидается сле­дующий блок данных. Например, символ ЕТВ информирует о приеме блока данных, а сим­вол ЕТХ - о приеме блока текста, и что контроллер ожидает приема блока контрольной суммы BCS. Прием символа ENQ информирует, что принят блок данных, но без поля BCS. Дальнейший прием данных будет производиться без вмешательства центрального про­цессора. Для реализации этого метода бит разрешения прерывания от события RCH в регистре маски BISYNC-контроллера должен быть предварительно установлен, разре-шая прерывание при приеме каждого байта данных. Это позволит программному обес­печению пользователя анализировать тип принимаемого блока данных. После этой про­верки, если был принят символ DLE-STX, приемник необходимо перевести в режим «про­зрачного» приема данных, установив для этого бит RTR := 1 в регистре режима BISYNC-онтроллера. Этот бит необходимо сбросить после приема пары символов DLE-ETX. Если же был принят символ начала блока SOH, то каналу необходимо передать команду гброса в исходное состояние счетчиков контрольной суммы RESET BCS CALCULATION, после выполнения этих действий прерывание от бита RCH должно быть замаскировано.

Далее BISYNC-контроллер будет принимать данные без вмешательства основного процессора, пока не примет контрольный символ, означающий конец принимаемого блока. После приема символа конца текста ЕТХ-контроллер будет ожидать прием поля кон­трольной суммы BCS, а затем буфер приема будет закрыт.

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

После приема контрольного символа конца блока данных бит RCH в регистре маски BISYNC-контроллера должен быть снова установлен, чтобы начать прием нового блока данных.

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

BISYNC-контроллер позволяет определить до восьми служебных символов в ячейках CHAR1-CHAR8 (рис. 5.146) памяти параметров. В полях CHAR1-CHAR8 определен фор­мат служебного символа. Бит Е = 1 (end of table) позволяет ограничивать число служеб­ных символов в таблице. Бит В определяет действия контроллера при приеме служебно­го символа. Если бит В = 0, то символ записывается в память и буфер закрывается. Если бит В = 1, то принятый символ записывается в буфер и контроллер ожидает приема, или 1 байта контрольной суммы LRC, или 2 байт контрольной суммы CRC. После приема поля контрольной суммы текущий буфер закрывается. Рекомендуется служебные сим­волы конца блоков ЕТХ (End of Text) и ЕТВ (End of Transmission Block) использовать с битом В = 1. После закрытия буфера генерируется маскируемое прерывание к централь­ному процессору.

Бит Н определяет режим работы BISYNC-контроллера после закрытия текущего бу­фера. Если бит Н = 0, то контроллер остается в рабочем режиме и поддерживает син­хронизацию символа. Если бит Н = 1, то контроллер после закрытия буфера переходит в режим поиска нового кадра (hunt mode). Если установлены оба бита - В = Н = 1, то контроллер перейдет в режим поиска нового кадра сразу по окончании приема поля контрольной суммы BCS.

В контроллере МРС860 пользователь может управлять проверкой контрольных сим­волов при приеме с помощью регистра маски RCCM (рис. 5.147) в памяти параметров BISYNC-контроллера. В младших восьми разрядах этого регистра можно маскировать

проведение анализа (сравнение) выбранного служебного символа. Бит i, равный единице, разрешает проверку/сравнение принятого символа с контрольным символом CHAR в таблице служебных символов. Бит i, равный нулю, запрещает проведение проверки Биты с 0-го по 2-й должны быть всегда установлены, иначе может возникнуть ошибка npi начале анализа служебных символов.

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

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

Таблица 5.87

Бит-ориентированная процедура HDLC и ее сравнение с BISYNC. В табл. 5.88 приводятся данные, позволяющие сопоставить по основным параметрам символьно-ориентированную процедуру BISYNC и бит-ориентированную процедуру HDLC.

Таблица 5.88

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

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

данном случае избирательная передача в адрес какой-либо станции ведется уже не на основе удержания соединения в режиме передачи избранному абоненту, что равносиль­но коммутации каналов, а на основе соответствующей адресации каждого кадра тому абоненту, которому предназначена содержащаяся в нем информация. В процедуре BISYNC используются управляющие последовательности, передаваемые по каналу в режиме управления, тогда как в процедуре HDLC выбор вторичной станции, к которой обращается первичная станция, осуществляется передачей в области адреса соответ­ствующего адреса вторичной станции. При этом область управления кадра используется не только для передачи команд и ответов, но и номеров передаваемых и подтверждае­мых кадров, применяющихся для организации надежного упорядоченного обмена дан­ными, а также организации управления. Функция опроса осуществляется с применением бита P/F, передаваемого в области управления каждого кадра. При этом первичная стан­ция устанавливает бит Р := 1 (опрос - Poll), если требуется инициировать передачу дан­ных или сигналов подтверждения от вторичной станции, которой адресуется кадр с би­том Р = 1. Вторичная станция оповещает первичную о завершении передачи установкой («1») в последнем передаваемом кадре бита F (окончание опроса - Final). Этот способ реализации функции выбора и опроса позволяет организовать достаточно эффективное управление передачей данных в сети с различными конфигурациями и разными спосо­бами передачи данных.

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

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

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

Протокол DDCMP. Символьно-ориентированный DDCMP-протокол (Digital Data Communication Message Protocol) разработан фирмой DEC для применения в сетях и системах телекоммуникации. Протокол DDCMP предназначен для синхронной работы по полнодуплексным и полудуплексным соединениям, устанавливаемым по сетям «точ­ка-точка» и многоточечным соединениям. Протокол может быть также использован для передачи данных в асинхронном старт-стопном режиме. В настоящее время этот прото­кол мало используется в современных сетях и поэтому как основной протокол он реали­зован только в контроллерах семейства МС68302, а в контроллере семейств МРС860 этот протокол предлагается фирмой «Motorola» в виде загружаемого микрокода, кото­рый пользователь при необходимости может загрузить в память контроллера.

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

Для передачи информации протокол использует три типа пакетов. Каждый тип пакета начинается с двух байтовых синхросимволов SYN1 и SYN2, формат которых задается в регистре синхронизации DSR и в специальном регистре DSYN1, и заканчивается 16-битной контрольной суммой. В зависимости от типа пакета и для повышения надежности передачи информации каждый логически законченный блок кадра (заголовок или блок данных) может иметь свою контрольную сумму. Например, заголовок кадра (от поля SOH/ ENQ/DLE до поля ADDR) и поле данных имеют различные поля контрольных сумм -CRC1 и CRC2. Типы пакетов показаны на рис. 5.148.

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

1) информационное сообщение (data message) служит для передачи данных и отме­чается символом SOH (формат 0x81);

2. управляющее сообщение (control message) служит для передачи управляющей и контрольной информации и отмечается символом ENQ (формат 0x05);

3. вспомогательное сообщение (transparent message) служит для передачи служеб­ ной информации и команд управления и отмечается символом DLE (формат 0x90).

Поле данных является байт-ориентированным. Полная длина поля данных в байтах указана в поле COUNT. Суммарная длина полей COUNT+F(Flag) равна 2 байтам.

Поле F (Flag) имеет размер 2 бита и содержит флаги соединения, которые использу-ются для управления монопольным использованием соединения и синхронизацией co­rf .цения. Назначение бит:

• bit 0 - флаг быстрой синхронизации (QSYNC флаг), используемый, чтобы сообщить приемнику, что после этого сообщения должна следовать повторная синхронизация; быстрый синхронизирующий флаг уменьшает длину синхронизирующих последова­тельностей на синхронных каналах;

• bit 1 - флаг выбора (флаг SELECT); используется для управления монопольным ис­пользованием передачи на многоточечных и полудуплексных каналах; изменяет на­ правление передачи в полудуплексных каналах; в multipoint-режиме разрешает пере­ давать или требует остановить передачу у выбранного узла.

Заголовка любого пакета в DDCMP имеет фиксированную длину, поэтому в состав некоторых пакетов введен байт заполнитель FILL со значением «0».

Для повышения надежности передачи информации используется механизм нуме­рации пакетов, аналогичный механизму, который применяется в HDLC-контроллере. Для нумерации передаваемых пакетов используется 8-битное поле NUM, а для нуме­рации подтверждаемых пакетов - 8-битное поле RESP.

Поле Message type определяет тип управляющего сообщения и обычно состоит из -етырех полей (табл. 5.89).

АСК-сообщение (Acknowledge Message) используется, чтобы подтвердить правиль­ное получение пронумерованных информационных сообщений с номерами до RESP. ACKTYPE - тип сообщения АСК со значением «1», ACKSUB - подтип АСК со значением «0», F - флаги соединения, FILL - байт заполнитель со значением «0».

NAK-сообщение (Negative Acknowledge Message) используется, чтобы передать ин­формацию об ошибке от приемника данных передатчику данных. Причина ошибки ука­зывается в поле подтипа REASON. Сообщение NAK выполняет две функции: подтверж­дение предварительно полученных сообщений с номерами до RESP и об ошибке в RESP+1 сообщении и передача передатчику информации об ошибке. NAKTYPE - тип сообщения NAK со значением «2», REASON - причина ошибки, F - флаги соединения, FILL - байт заполнитель со значением «0».

REP-сообщение (Reply to Message Number) используется, чтобы запросить о состоя­нии определенного полученного сообщения с номером NUM от приемника данных. Оно обычно высылается, когда master-станция передала информационные сообщения и не получила ответ за некоторое фиксированное время. Ответом на REP-пакет является или АСК- или NAK-ответ в зависимости от того, получила ли slave-станция (приемник) или не получила все сообщения, предварительно посланные master-станцией (передатчиком). REPTYPE -тип сообщения REP со значением «3», REPSUB-подтип REP со значением «0», F-флаги соединения, FILL - байт заполнитель со значением «0».

Стартовое сообщение (STRT - Start Message) не используется, чтобы установить соединение и синхронизацию или при его реинициализации. Функционирует совмест­но с сообщением подтверждения начала STACK. При передаче этого сообщения сбра­сываются счетчики нумерации сообщения в передатчике и в адресованном приемни­ке. STRTTYPE -тип сообщения STRT со значением «6», STRTSUB - подтип STRT со значением «0», F - флаги соединения (оба флага равны «1»), FILL - байт заполни­тель со значением «0».

Сообщение, подтверждающее установление соединения (STACK - Start Acknowledge Message) является ответом на STRT-сообщение, когда станция-получатель завершила ини­циализацию и сбросила счетчики нумерации сообщения. STCKTYPE - тип сообщения STACK со значением «7», STCKSUB - подтип STACK со значением «0», F - флаги соеди­нения (оба флага равны «1»), FILL - байт заполнитель со значением «0».

DDCMP протокол функционирует в двух основных режимах:

1. on-line (интерактивный), или нормальный режим выполнения;

2. off-line (автономный), или режим сопровождения.

Предыдущие сообщения описывают режим on-line. Off-line (автономный), или режим сопровождения, может использоваться для тестирования/диагностики станций и простых рабочих процедур типа начальной загрузки или загрузки по линии связи, для передачи этих «прозрачных» данных используются служебные сообщения (Transparent Message).