RS-232 + FPGA Опции

[maksya]

Доброго времени суток, уважаемые.

Есть задача: между платой и датчиками существует RS-232 канал, точнее 3 канала в направлении от платы к датчикам и 3 - противоположном. Цель - обеспечить работоспособность этой связки.

В качестве ядра системы предполагаю использовать FPGA (естественно не только для целей обмена с датчиками). Если Я правильно понимаю, то придется ставить внешние микросхемы (типа MAX220–MAX249) для преобразования уровней TTL <-> RS-232. Остается дело за малым - реализовать в системе приемопередатчики. С этого момента постараюсь раскрыть проблему более подробно.

С передатчиком более-менее понятно: типичный Serializer с двумя регистрами и одним PLL (старт_бит:байт_данных:контроль:стоп_бит и все это наружу). С приемником сложнее: только deserializer'ом, наверное, обойтись не получится

В классическом представлнии (в соответствии с остаточными знаниями, полученными в ВУЗе) приемник должен запустить свой внутренний генератор (работающий с частотой, например, в 16 раз превышающей бодовую) после обнаружения на линии перехода сигнала с 1 в 0, т.е. обнаружения старт-бита. Через 8 импульсов после этого события еще раз проверяем состояние линии, и если там 0, то считаем что пришел старт-бит. Далее входной поток мереем через каждые 16 тактов (т.е. с бодовой скоростью), предположительно попадая на середину бита. Записав биты в регистр, проверяем четность, наличие стоп-бита и все по-новой.

Помимо попытки вычисления значения бита в середине интервала, Я встречал еще в литературе варианты когда в битовом интервале производится 3 выборки и по мажоритарному принципу определяется значение.

Теперь к вопросу реализации:

Вариант 1. Брать внешнюю миросхему с реализованным UART'ом. Вроде Intel 8251 для этих целей используется в качестве внешнего устрйоства процессора. Есть и встроенные в корпус МК UART'ы, но ставить МК на плату только ради этих целей как-то нелепо. Кстати, а существует ли вариант, объединяющий UART с драйвером RS-232?

Вариант 2. Самому делать на FPGA. В этом случае Я вижу несколько проблем:
- как мне осуществить "запуск" генератора приемника при обнаружении старт-бита?
- т.к. мне требуется реализовать 3 передатчика и 3 приемника RS-232, и скорее всего эти каналы будут работать независимо друг от друга, то вроде как получается, чересчур большие затраты по количеству PLL-ресурсов. Как бы не вышло, что придется ставить несколько ПЛИС...

Нашел в закромах VHDL код UART'а (прикладываю в тему). Бегло просмотрев код, выявил для себя одну интересную вещь - там используется CLK в 4 раза быстрее бодовой скорости, производится выборка значения бита 3 раза за интервал. Т.е. если вдвинутое из Rx-линии в трехразрядный регистр значение = 000, то считаем, что пришел старт-бит. Далее - по алгоритму. Насколько такой способ отражает реальные потребности реализации? Влиять на UART на стороне датчиков не представляется возможным. Всвязи с этим непонятно, будет ли всегда данные от датчика адекватно приниматься в FPGA'шный приемник.

И еще - встречал в каких-то статьях, что в FPGA встраиваются блоки SERDES. В hepl'е Quartus'а говорится что вроде как в Stratix'е есть такая возможность. Кто-нибудь работал с ними? И не слишком ли "жирно" будет использовать такие SERDES для 115 Кбит/с?

Быть может Я делаю из РПГ-18 (гранатомет "муха") слона, и задача решается современными средствами намного проще? Вообщем если у кого есть опыт общения с датчиками по RS-232, то просьба поделиться знаниями.

P.S.: Резюмируя вышесказанное, прошу по возможности ответить на следующие вопросы:
1. Применяются ли сейчас отдельные микросхемы UART'ов? Есть ли варианты UART+драйвер RS-232 в одном корпусе?
2. Обязательно ли использовать PLL для этой задачи?
3. Приложенный VHDL код UART'а (или аналогичный ему) может гарантировать правильный обмен информацией?
4. К месту ли применение аппаратных встроенных в ПЛИС блоков SERDES?
5. Есть ли у кого опыт решения похожей задачи?

Прикрепленные файлы

 hUART.zip ( 2.07 килобайт ) Кол-во скачиваний: 303

 

[Kopart]

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

Если в схеме с делением битового интервала на 16 частей и выборке 3х средних значений, к моменту приема последнего бита такая выборка может "уплыть" от центра битового интервала к его краю, то есть на время, приблизительно равное половине битового интервала, то при предложенном NIOSом методе, искажение данных произойдет, если выборка "уплывет" хотя бы на треть.

Макс возможный случай - что к приему стопового бита генератор уплывет на треть длительности БИТА.
Прикинем какое должно быть рассогласование опорных генераторов, чтобы выборка уплыла на треть.
Макс скорость передачи 128000, максимально возможно бит = 1+8+1+2 = 12
Те за 93.75мкс частота должна уйти на 2.604мкс не более 2.7% (это для частоты 128кГц)
В вашем случае (1/2 бита) получается не более 4.1%
Стабильность генератора не хуже 10^-6 те 0.0001%.
А вот точность, сейчас программируемых генераторов, я на вскидку не скажу - это уже другой вопрос, который также актуален при рассогласовании в 1/2 бита.
Те жертвуя 1/2-1/3 ~= 0.16 бита Вы получает удобство по компактности реализации и простоте алгоритма приема.

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

Логика проста: Первый МЖФ - простейщий фильтр на входе в ПЛИС (получще будет чем стробирование)
- к минимум задача фильтровать пички.
Второй МЖФ нужен по идее метода - определять значения бодовых битов (+не учитывать, если выборка попадет на перепад сигнала)

Если просто сравнивать с тем, что предлагает Вы - мне не требуется точно определять начала стартового бита, чтобы потом попасть на середину. Я работаю максимально с частотой в 3 раза больше бодовой, а Вам нужно довольно точно защелкивать, чтобы быть увереным, что попали в середину.
А определение начала и конца "посылки" в моем методы тоже присутствует - в КА, и не требует такой точности.

[javalenok]

Допустим один проголосовал против -- и что дальше? Правильные голоса появились -- мажоритарность можно реализовать проще -- выборкой 1-го бита в середине битового интервала. Какой смысл пропускать ряд пичков 1010101010 -- не понял. Это как-то повышает надёжность? Ещё не понял, как без стопового бита вы будете засекать появление стартового, ведь последний бит данных может быть нулём, т.е. неразличим от старта.

И ещё, когда считаете погрешности рассинхронизации, не забывайте, что передискретизация 16х сама по себе даёт задержку до 6,5% от настоящего старт-фронта. При эхо-тестировании приёмопередатчика длинными потоками у меня случались сбои. Чтобы ошибка не накапливалась, сбрасывать приёмник надо в середине стоп-бита.

Никто не сказал ничего вразумительного про метастабильность, но в примере который я брал за основу применялся синхронизатор. Видимо он нужен чтоб предотвратить "непонятки" когда Rx зависает между небом и землёй и вся логика, на нём завязанная, интерпретирует уровень на своё усмотрение, приводя автомат в полный беспорядок.

Но вообще идея использовать сдвиг вместо подсчёта бит заслуживает рассмотрения. Парадоксально, но декодер на N адресов в FPGA занимает вдвое больше ресурсов, чем цепочка из N FF-ов.

[Kopart]

Вы хоть обозначайте кому пишите! А лучше ставьте цитаты, того на что отвечаете.
Про комментирую то, что покажется обращено ко мне.

Допустим один проголосовал против -- и что дальше? Правильные голоса появились -- мажоритарность можно реализовать проще -- выборкой 1-го бита в середине битового интервала. Какой смысл пропускать ряд пичков 1010101010 -- не понял. Это как-то повышает надёжность? Ещё не понял, как без стопового бита вы будете засекать появление стартового, ведь последний бит данных может быть нулём, т.е. неразличим от старта.

Тут вопрос определения "середины битового интервала" (для этого "точно" надо знать начала стартового бита)
А с МЖФ не надо синхронизоватся - сам поймет "опосля" - вот уже стартовый "ноль" - надо бы начать вдвигать. Плюс фильтруются пологие фронты, спады.
Я изначально "вдвиговый" регистр инициализурую всеми "1", и как стартовый добрался до определенной ячейки (последней, предпоследней, i-ой) - понимаю сколько принял, и жду дальше/сравниваю (четность)/сбрасываю приемник(с задержкой) - в паралель (это же ПЛИС)

И ещё, когда считаете погрешности рассинхронизации, не забывайте, что передискретизация 16х сама по себе даёт задержку до 6,5% от настоящего старт-фронта.

Поподробнее откуда такие циферки?
В моем способе синхронизация не требуется... (это паралельный процесс)

Никто не сказал ничего вразумительного про метастабильность, но в примере который я брал за основу применялся синхронизатор. Видимо он нужен чтоб предотвратить "непонятки" когда Rx зависает между небом и землёй и вся логика, на нём завязанная, интерпретирует уровень на своё усмотрение, приводя автомат в полный беспорядок.
Но вообще идея использовать сдвиг вместо подсчёта бит заслуживает рассмотрения. Парадоксально, но декодер на N адресов в FPGA занимает вдвое больше ресурсов, чем цепочка из N FF-ов.

+ если я правильно понял - то нужен еще счетчик битов([3:0] макс до 12)

Из непонятного состояния всегда можно выйти по таймауту.