Локальная сеть корвет

[forth32]

Наконец я осуществил свою давнюю мысль - изучил ОПТС 2.0 в дизассемблере IDA и, в частности, разобрал протокол работы локальной сети. Хочу поделиться результатами с общественностью.

Но вначале хотелось бы обсудить физический уровень сети. Я нигде не нашел никакой документации об этом, видимо, она прилагалась только в бумажном виде к комплексу КУВТ. Приходится строить предположения. Как видно из схемы корвета, передатчик сети выведен в виде транзистора с открытым эмиттером. Это позволяет соединять выходы нескольких корветов параллельно. В конце линии обязательно должен иметься нагрузочный резистор на землю. При бездействии передатчика транзистор закрыт и не влияет на работу сети, но в случае попытки одновременной передачи несколькими машинами произойдет коллизия. Приемник сети - обычный TTL-вход. Их также можно соединить параллельно.

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

Но возникло одно затруднение. Имеющиеся у меня тестовые программы (KTDP и OLD) имеют режим проверки сети. Так вот они требуют, чтобы данные от передатчика сети попадали на вход приемника - то есть передатчик и приемник образуют петлю. В таком случае устройство сети получается немного другим. По помещению проложен двухпроводной кабель. К одной из жил подключены все передатчики и периемники сети, как клиентов, так и сервера. Вторая жила - земля, и между жилами включен нагрузочный резистор. Такая топология сети похожа на распространенный в свое время тонкий ethernet 10base2. Возникающее при передаче пакета паразитное эхо на входе своего же приемника подавляется тем, что на время передачи данных прерывания от приемника сети запрещаются (поначалу я не мог въехать, зачем так сделано в коде ОПТС). Поскольку протокол сети полудуплексный, и целиком контролируется сервером, коллизий в кабеле возникать не должно.
Какой из вариантов использовался на практике, трудно сказать. Работать должны оба.

Теперь насчет параметров последовательного канала. Скорость передачи здесь всегда 19200 baud. Параметры кадра - 8О1. То есть 8 бит данных, 1 стоп-бит и бит проверки на НЕЧЕТНОСТЬ. Обратите внимание - контроль четности в последовательных интерфейсах применяется крайне редко, тут он сделан, очевидно, из-за высоких помех на линии связи.

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



Повезло, что в корвете на входе и выходе ВВ51 уже стоят инверторы. Это позволяет соединить передатчик корвета прямо с компортом, а приемник - через простейший делитель. Такая схема работает, проверено, с современными набортными компортами и USB-Serial преобразователями. Со старыми компортами, на мультикартах, могут быть пробемы, поскольку логический 0 здесь именно 0, а не -12В, как положено по стандарту. В этом варианте поключения петля с выхода на вход не обеспечивается. К переходнику можно подключить и несколько корветов, соединив у них параллельно соответственно входы и выходы.

Второй вариант подключения:



Здесь уже использована специализированная микросхема формирователя RS-232 уровней. Такая схема гарантированно будет работать с любым компортом. Также здесь имеется полноценная петля с выхода передатчика на вход приемника. Разумеется, к нему также можно подключить несколько корветов.

При любом варианте подключения, чтобы корвет стал РМУ (клиентом), надо назначить ему адрес сети, соединив с землей какие-либо из выводов A0-A3 на сетевом разъеме. На схемах я условно показал их как Ax. Если такого соединения не делать, то корвету назначается номер 0, и он становится сервером.

Теперь я немного систематизирую свои записи и в следующем письме опишу логический протокол сети.

---------- Post added at 11:52 ---------- Previous post was at 10:57 ----------

Логическая организация сети. Транспортный уровень.

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

Смещение длина   описание
+00        1     Байт всегда равен 01 - признак начала пакета
+01        1     Длина пакета. Равен фактической длине + 1Dh
+02        1     Номер пакета. Пакеты нумеруются начиная с 20h и до FFh
+03        1     Буква, определяющая тип пакета
+04       nnn    Тело пакета
+nnn+4     1     Контрольная сумма пакета
+nnn+5     1     Байт всегда равен 0D - признак конца пакета

Далее я опишу форматы отдельных пакетов.
Как видно, пакет всегда начинается с байта 01 и заканчивается 0D. Байт 01 не может встретиться в теле пакета. Фактически, когда клиент во время приема данных встречает 01 до конца пакета, он отбрасывает весь ранее принятый блок данных и начинает принимать пакет заново. Это позволяет избежать подвисаний в случае потери нескольких байт при приеме. Более того, прняты специальные меры, чтобы в пакете не встречалось байтов с кодами 00-1F (все управляющие). Таким образом всеь пакет состоит только из отображаемых байтов. Зачем так сделано - мне не совсем понятно. Похожие меры применяются, например, при передаче вложений по e-mail и сети фидо(MIME- и UUE-кодирование). Но там они оправданны, а здесь?

Длина пакета - это полная длина, включая префикс 01 и окончание 0D. К этой длине добавляется 1Dh для того, чтобы этот байт был не менее 20h. Таким образом, максимальная длина пакета не должна превышать 226 байт. На практике пакеты создаются меньшего размера - не более 100 байт. Это позволяет уменьшить объем перепосылаемой по сети информации в случае ошибки.

Номер пакета индивидуален для каждого пакета. Пакеты нумеруют начиная с 20h. При последовательной передаче данных номера постепенно увеличивают вплоть до FFh, а затем снова заворачивают на 20h. При приеме адресного пакета счетчик номеров сбрасывается на начальное значение. Номера позволяют проконтролировать потерю пакетов при приеме - в этом случае последовательность нумерации собъется.

Буква типа пакета определяет, какая информация содержится в пакете. Всего в ОПТС поддерживается 7 типов пакетов:
A - пакет адреса
R - запрос передачи данных, от сервера к клиенту
S - запрос приема данных, от клиента к серверу
D - пакет данных
Z - пакет конца данных
Y - пакет подтвержения приема
N - пакет ошибки приема

Возможно, что существуют и другие типы пакетов, но ОПТС 2.0 поддерживает только эти, и любой другой тип вызовет ошибку.

Контрольная сумма вычисляется по всему пакету начиная от байта длины и заканчивая собственно контрольной суммой. Префикс 01 в сумму не входит. Вычисляется она так. Вначале все складываются все байты пакета. Затем берется младший байт полученной суммы и с ним делается такое преобразование (sum - младший байт суммы):

cs=((sum>>6)+sum)&0x3f+0x20;

Результат CS и есть искомая сумма. Последние 2 преобразования (&0x3f+0x20) очевидно, сделаны для того, чтобы контрольная сумма не попала в диапазон 00-1F.

[Advertiser]