Обработка ошибок передачи

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Передача данных по шине IEEE 1394

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

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

Пакет запроса пришел к адресованному узлу с ошибкой CRC данных:

• действия узла-ответчика: канальный уровень передает его уровню транзакций поврежденный пакет с признаком ошибки. Уровень транзакций отбрасывает пакет и через канальный уровень посылает квитанцию с кодом ошибки. Прикладной драйвер никаких уведомлений не получает;
• действия узла-запросчика: канальный уровень принимает эту квитанцию и передает ее код уровню транзакций, который информирует прикладной драйвер о неудаче. Какая на это последует реакция — зависит от приложения, которое знает, что до ответчика запрос не дошел.

Пакет запроса пришел нормально, но пакет квитирования «потерялся» (канальный уровень запросчика не дождался корректной квитанции):

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

Пакет ответа пришел к запросчику с ошибкой CRC данных:

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

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

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

Взаимодействие драйвера с уровнем транзакций

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Передача данных по шине IEEE 1394

Уровень транзакций взаимодействует с прикладным драйвером четырьмя примитивами сервисов:

• запрос (request), используемый запросчиком транзакции для инициирования субакции запроса. В запросе передается:

1. код типа транзакции (Read, Write, Lock с указанием операции);
2. адрес получателя;
3. длина данных;
4. данные (для Write и Lock);
5. скорость передачи.

Передавая запрос канальному уровню, уровень транзакций добавляет еще метку транзакции и код повтора.

• Индикация (indication), уведомляющая ответчика о приходе запроса. Драйверу ответчика передается:

1. код типа транзакции (Read, Write, Lock с указанием операции);
2. адрес узла$запросчика (получателя для данной субакции);
3. длина данных;
4. данные (для Write и Lock);
5. метка транзакции;
6. код повтора;
7. скорость передачи.

• Ответ (response), используемый ответчиком для получения состояния или данных запроса, запускающий субакцию ответа. В ответе передается:

1. код типа транзакции;
2. адрес запросчика (получателя);
3. длина данных;
4. данные (для Read и Lock);
5. код ответа;
6. метка транзакции;
7. скорость передачи.

• Подтверждение (confirmation), уведомляющее запросчика о завершении транзакции. В нем прикладному драйверу передается;

1. состояние запроса: завершение (успешное), тайм$аут (отсутствие своевременного ответа), отсутствие квитанции о приеме запроса, исчерпание предела повторов, ошибка принятых данных;
2. код ответа (завершение или ошибка данных);
3. данные и их длина (для Read и Lock).

Организация потоковых передач и изохронный обмен

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Передача данных по шине IEEE 1394

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

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

Пакеты изохронных передач передаются широковещательно и физически адресуются по номеру канала (0–63), указанному в заголовке пакетов.

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

Для выполнения изохронных обменов прикладной драйвер пользуется сервисами LINK-уровня:

• Запрос изохронной передачи (Link Isochronous Request), в котором драйвер передает:

1. номер канала;
2. длину данных;
3. данные;
4. скорость;
5. тег, определяющий формат данных;
6. код синхронизации (специфичен для приложений).

• Индикация изохронной передачи (Link Isochronous Indication), в которой драйвер получает те же данные. LINK-уровень будет давать индикацию только при приеме пакетов с требуемыми номерами каналов;
• управление изохронным обменом (Link Isochronous Control), в котором драйвер указывает номер канала, прием которого следует начать или завершить;
• синхронизация циклов (Link Cycle Synch) — индикация приема пакета начала цикла с сообщением текущего значения счетчика циклов и счетчика секунд. По этой информации и своим часам приложение может определить опоздание начала цикла и обеспечить свою синхронизацию с остальными участниками обмена.

Пакеты для потоковых передач

Подробности

Родительская категория: Шина IEEE 1394 — FireWire

Категория: Передача данных по шине IEEE 1394

Потоковые передачи выполняются в широковещательной форме, в которой присутствует только пакет запроса и нет ни квитирования, ни ответов. Потоковые данные передаются пакетами с tcode = Ah. Этот код транзакции указывает на то, что пакет адресуется не по номеру узла, а по номеру канала channel. Формат данных в пакете определяется 2-битным полем tag: 00 — неформатированные данные, 01 — общий формат CIP (Common Isochronous Packet), 1x — резерв. Информацию о синхронизации, специфическую для приложений, может нести поле sy (4 бита). Длина блока данных data_length (в байтах) ограничивается. Пакет может иметь и нулевую длину данных, при этом размер пакета сокращается до двух квадлетов заголовка. Если длина данных не кратна квадлету, то последний квадлет данных дополняется до целого байтами-заполнителями.

Мастер циклов регулярно (с периодом 125 мкс) передает пакеты начала цикла (рис. б). В каждом таком пакете мастер циклов передает значение 32-битного счетчика времени (CYCLE_TIME), инкрементируемого с частотой 24,576 МГц. Метки времени нужны каждому узлу, поддерживающему изохронный обмен. Если к моменту подачи очередного пакета начала цикла шина оказывается занятой передачей, то пакет начала цикла задерживается до момента освобождения шины. В поле данных cycle_time_data передается значение регистра CYCLE_TIME мастера циклов на момент его фактической передачи, так что точная синхронизация узлов обеспечивается и при опозданиях пакета. Пакет передается во время асинхронной части цикла, но с коротким зазором арбитража, что обеспечивает приоритетность данных пакетов. Пакет передается широковещательно (destination_ID = 3Fh), его принимают все узлы, интересующиеся изохронными передачами. В поле destination_offset указывается адрес регистра CYCLE_TIME (смещение 200h в пространстве регистров CSR). Поле tl не используется (ответов не предусматривается), rt = = 00 (без квитирования). Поле source_ID содержит номер шины и идентификатор корневого узла, который и должен быть мастером циклов.