Микроэлектронные проекты. Игорь Коваль. Конвертер интерфейсов ИРПС -> RS485 с исправлением однократных ошибок

Данная работа посвящена реализации преобразователя интерфейса ИРПС (Current Loop) в интерфейс RS485. Для улучшения помехоустойчивости конвертер снабжен кодером/декодером Хемминга, что позволяет обнаруживать и исправлять все однократные ошибки. Преобразование интерфейсов реализовано на микросхемах типа SN75ALS176, кодер и декодер выполнены на микроконтроллерах AT90S2313-10PI. Связь с компьютером осуществляется через оптронную развязку, гальваническая развязка от питающей сети обеспечивается применением трансформаторного источника питания. Устройство подключается к компьютеру и работает на одной из трех фиксированных скоростей - 9600, 19200 или 38400 Бит/c. Требуемая скорость задается кнопочным переключателем. Программное обеспечение очень легко модифицировать с целью добавления поддержки более высоких или более низких скоростей. В частности, имеется резерв повышения скорости до 57600 Бит/c. Не составляет труда доработать конвертер для поддержки стандарта RS232C. Кроме того, в данной работе кратко описан алгоритм помехоустойчивого кодирования по Хеммингу и приведены соответствующие примеры.

На разработку данного устройства автора вдохновила необходимость повысить помехоустойчивость и скорость приема/передачи при связи компьютера с удаленным терминалом. В данном случае речь идет о компьютере, оснащенном мультипортовой платой с интерфейсами ИРПС. К каждому из портов платы при помощи соединительных линий длиной до 500 метров подключено по одному удаленному терминалу. Проблема заключается в том, что при установлении скорости выше 9600 Бит/Сек появляются ошибки приема данных. Идея состоит в том, чтобы заменить интерфейс ИРПС на более помехоустойчивый и современный RS485. Кроме того, для повышения надежности было решено использовать помехоустойчивое кодирование данных. Как отмечается в литературе [4], вероятность искажения битов для каналов связи, не использующих дополнительных средств защиты от ошибок, лежит в пределах 1/10000 … 1/1000000. Это означает, что из 10000 … 1000000 битов в среднем искажается один. Такие сравнительно скромные вероятности искажния позволяют использовать код с исправлением однократных ошибок. Для убедительности приведу небольшую табличку, заимствованную из [5]:

Длина линии связи	Скорость приема/передачи
12 м	10 МБит/c
120 м	1 МБит/c
1200 м	100 КБит/c

Итак, рассмотрим алгоритм кодирования восьмиразрядного слова вида (A₇, A₆, A₅, A₄, A₃, A₂, A₁, A₀) по Хеммингу. Как это принято, A₇ - старший разряд, A₀ - младший. Определим, сколько проверочных битов нам потребуется. Легко сообразить, что их потребуется минимум четыре [1]. Синдром (число, локализующее ошибку), вычисляемый декодером на основании информационных и проверочных битов в этом случае будет состоять из четырех разрядов. Четыре бита синдрома смогут указать ошибочный бит при разрядности кодовой комбинации до 15 бит. Если все биты синдрома равны нулю, то кодовая комбинация передана по линии без ошибок. В нашем случае разрядность кодовой комбинации будет равна 12, так как мы добавляем к восьми информационным битам четыре проверочных. Проверочные биты нужно разместить на позициях с номерами 1, 2, 4 и 8 [1]. При этом кодовая комбинация будет выглядеть так:

Номер разряда	1	2	3	4	5	6	7	8	9	10	11	12
Разряд	C1	C2	A7	C4	A6	A5	A4	C8	A3	A2	A1	A0

Здесь C₁, C₂, C₄, C₈ - проверочные биты. Вычисляются они с помощью операции "Исключающее ИЛИ":
C₁ = A₇ A₆ A₄ A₃ A₁
C₂ = A₇ A₅ A₄ A₂ A₁
C₄ = A₆ A₅ A₄ A₀
C₈ = A₃ A₂ A₁ A₀
Как видно, G кодирование не вызывает трудностей. Не совсем удобно то, что AVR - семейство не имеет флага паритета, но, эффективный кодер/декодер легко построить и без него. Алгоритм декодирования выглядит очень похожим, но при декодировании в вычислении синдрома (числа, локализующего поврежденный бит) используются не только информационные, но и проверочные разряды:
S₁ = C₁ A₇ A₆ A₄ A₃ A₁
S₂ = C₂ A₇ A₅ A₄ A₂ A₁
S₄ = C₄ A₆ A₅ A₄ A₀
S₈ = C₈ A₃ A₂ A₁ A₀
Сам синдром однозначно указывает, в каком именно бите произошла ошибка. Если синдром нулевой, ошибок не зафиксировано. Если синдром лежит в интервале [1 .. 12], то имеет место устранимая ошибка. Если же синдром равен 13, 14 или 15, то произошла неустранимая ошибка. Что делать с такими символами - личное дело пользователя. Например, при передаче данных через последовательный порт персонального компьютера имеется возможность настроить порт так, что поврежденные (и всегда неисправимые, аппаратура порта не допускает исправлений) символы будут заменяться некоторым заранее определенным байтом. Это неудобно, ведь тогда этот байт намеренно нельзя передавать через порт. Хотя, если вспомнить, что чисто экономические соображения вызвали к жизни протокол XON/XOFF, то еще одним байтом можно пожертвовать. Следует заметить, что не все неустранимые ошибки при декодировании дадут синдром от 13 до 15 включительно. В самом деле, ошибка (более, чем двукратная) может так исказить посылку, что полученное на приемном конце линии кодовое слово будет выглядеть абсолютно легальным и даже дать при декодировании нулевой синдром. Выход из этой ситуации - применение более мощных (и более избыточных) кодов. Естественно, при таком подходе скорость передачи в линию будет расти, если только не исходить из предположения, что байты для передачи не формируются хостом с достаточно длинными задержками друг между другом. В данной разработке мы предполагаем, что байты могут генерироваться машиной непрерывно, и интервал между ними может быть не более половины длительности одного бита. В любом случае, здесь все зависит от самого хоста. Преобразователь интерфейсов должен быть "прозрачным" для компьютера, и не может диктовать ему свои условия. Теперь рассмотрим небольшой пример. Пусть компьютер передал нашему кодеру код 65h. Посмотрим, что при этом произойдет. Сначала построим небольшую табличку, расставив исходные биты в требуемом порядке:

Номер разряда	1	2	3	4	5	6	7	8	9	10	11	12
Бит	C1	C2	A7	C4	A6	A5	A4	C8	A3	A2	A1	A0
Значение	?	?	0	?	1	1	0	?	0	1	0	1

А теперь вычислим проверочные разряды:
C₁ = 0 1 0 0 0 = 1
C₂ = 0 1 0 1 0 = 0
C₄ = 1 1 0 1 = 1
C₈ = 0 1 0 1 = 0 В результате кодовая комбинация примет вид:

Номер разряда	1	2	3	4	5	6	7	8	9	10	11	12
Значение	1	0	0	1	1	1	0	0	0	1	0	1

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

Номер разряда	1	2	3	4	5	6	7	8	9	10	11	12
Бит	C1	C2	A7	C4	A6	A5	A4	C8	A3	A2	A1	A0
Значение	1	0	0	1	1	1	0	0	0	1	0	1

Вычисляем синдром:
S₁ = 1 0 1 0 0 0 = 0
S₂ = 0 0 1 0 1 0 = 0
S₄ = 1 1 1 0 1 = 0
S₈ = 0 0 1 0 1 = 0 Нулевой синдром говорит об отсутствии ошибок. Рассмотрим случай, когда имеется однократная ошибка. Пусть под воздействием помех исказился символ A₇ (третий бит кодовой комбинации). Слово, полученное из линии, выглядит так:

Номер разряда	1	2	3	4	5	6	7	8	9	10	11	12
Бит	C1	C2	A7	C4	A6	A5	A4	C8	A3	A2	A1	A0
Значение	1	0	1	1	1	1	0	0	0	1	0	1

Вычисляем синдром:
S₁ = 1 1 1 0 0 0 = 1
S₂ = 0 1 1 0 1 0 = 1
S₄ = 1 1 1 0 1 = 0
S₈ = 0 0 1 0 1 = 0 Если учесть тот факт, что S₈ - старший бит синдрома, а S₁ - младший, и что 0011 = 3, то нужно скорректировать (проинвертировать) третий бит, а именно - искаженный помехой бит A₇. И последнее. Если при передаче произойдет более чем однократная ошибка, то код окажется бессильным. Теперь - о реализации приведенного алгоритма. На практике все выглядит примерно так:

• С машины поступает некоторый байт данных. Кодер должен как можно быстрее закодировать этот байт и отправить его в линию. При этом посылка, пришедшая с компьютера, состоит из 10 битов, а результирующая кодовая комбинация состоит из 14 битов: Старт-бит (всегда лог.0), 12 информационных битов (данные + проверочные разряды), Стоп-бит (всегда лог.1).
• На приемном конце линии имеется декодер, который непрерывно сканирует линию с целью обнаружить старт-бит (переход из лог.1 в лог.0). Как только такой переход обнаружен, запускается процесс выделения битов. Для этого декодер опрашивает линию в середине каждого битового интервала и считанное значение запоминает. Если при опросе линии обнаружен единичный старт-бит или нулевой стоп-бит, то принимается решение о приеме сбойной кодовой комбинации. Такие комбинации не декодируются и не исправляются, а просто отбрасываются, и декодер начинает отыскивать новый переход линии из состояния лог.1 в состояние лог.0. После приема кодовой комбинации с корректными старт- (и стоп-) битами декодер при необходимости исправляет ошибку, после чего передает символ в компьютер и ожидает появления нового старт-бита.

Вроде бы, все просто. Но на практике выясняется, что при работе в дуплексном режиме кодер и декодер должны быть реализованы на разных микроконтроллерах, иначе процессы приема и передачи будут мешать друг другу. В самом деле, при передаче кодовой комбинации в линию контроллер не должен обращать внимания ни на какие события, иначе длительности битов будут меняться случайным образом. Если при передаче кодовой комбинации от удаленного конвертера придут какие-либо данные, то они будут потеряны. Поэтому в данной разработке кодер и декодер выполнены в виде независимых устройств, хотя и в одном корпусе. Второй важный момент - во сколько раз нужно поднять скорость на линии, чтобы кодер не "захлебывался" данными, если компьютер передает байты непрерывно? Оценим эту величину. Поскольку количество битов с 10 вырастет до 14, то и скорость вырастет минимум в 1,4 раза:

Исходная скорость	9600	19200	38400
Результирующая скорость	13440	26880	53760

Кроме того, необходимо еще обеспечить некоторый запас времени для работы кодера/декодера. Простейший расчет показывает, что если увеличить скорость в 1,5 раза и в 1,6 раза, мы получим следующие значения запасов времени:

Исходная скорость, Бит/Сек	9600	19200	38400
Длительность приема/передачи байта, мкС	1041,46	520,83	260,42
Увеличение в 1,5 раза
Результирующая скорость, Бит/Сек	14400	28800	57600
Длительность приема/передачи байта, мкС	972,22	486,11	243,06
Длительность приема/передачи бита, мкС	69,45	34,72	17,36
Запас времени, мкС	69,24	34,72	17,36
Увеличение в 1,6 раза
Результирующая скорость, Бит/Сек	15360	30720	61440
Длительность приема/передачи байта, мкС	911,46	455,73	227,87
Длительность приема/передачи бита, мкС	65,11	32,55	16,28
Запас времени, мкС	130,21	65,1	32,55

Отсюда видно, что кодер (и декодер) должен успеть кодировать/ декодировать информационные посылки довольно быстро. Как показывает анализ управляющих программ кодера и декодера, увеличения скорости в 1,5 раза вполне достаточно.

Конвертер выполнен в виде отдельного блока на макетной плате. С целью упрощения схемы для каждого контроллера используется отдельный кварцевый резонатор, хотя ATMEL позволяет обойтись и одним резонатором. В этом случае следует использовать буфер - микросхему типа К1554ЛА3, подключив ее одним из входов к выводу XTAL2 контроллера, а с соответствующего выхода снимать сигнал тактовой частоты. Купить эту микросхему невозможно, поэтому пришлось обходиться имеющимися средствами. То же следует сказать и о чипах SN75ALS176. Они давно морально устарели, но ничего более нового (автор живет не в столице) найти не удалось. Можно лишь порекомендовать использовать в качестве преобразователей кристаллы MAX489 от MAXIM (если найдете). Следует немного рассказать о требованиях к линии связи. Длина линии, в соответствии со стандартом RS485, не должна превышать 1200 метров. Рекомендуется использовать кабель в виде экранированной витой пары. Волновое сопротивление кабеля находится в пределах 100 .. 120 Ом. Чтобы не допустить отражений сигнала от конца линии, входы приемников следует зашунтировать резисторами с сопротивлением, равным волновому сопротивлению кабеля. Реальная дальность и скорость связи сильно зависит от параметров линии, помеховой обстановки, симметрии линии связи и т.п. Управляющие программы конвертера снабжены подробными комментариями, поэтому здесь их построение рассматривать нет необходимости.

[1] Лапа В. Г. "Математические основы кибернетики". Киев. "Вища школа", 1974
[2] К.Г.Самофалов и др. "Теория и практика цифровых автоматов"
[3] Р.Блейхут. "Теория и практика кодов, контролирующих ошибки". Москва. "МИР", 1986
[4] В.Г. Олифер, Н.А. Олифер. "Компьютерные сети. Учебник". Санкт-Петербург. "Питер", 2000
[5] М.Гук. "Аппаратные средства IBM PC. Энциклопедия". Санкт-Петербург. "Питер", 2000

Вы можете загрузить следующие файлы, относящиеся к проекту:
CODER_H.A90 — исходный текст управляющей программы кодера
DECODERH.A90 — исходный текст управляющей программы декодера3
— Inc-файл для AT90S2313
— схема в формате PROTEL

Автор проекта: Игорь Коваль (E-mail: kovigor@yahoo.com)

 Разместите Ваш проект у нас на сайте и его смогут увидеть сотни посетителей в день. Ваши проекты присылайте вебмастеру.