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

Есть задача: между платой и датчиками существует 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. Есть ли у кого опыт решения похожей задачи?

TO NIOS:
А не могли бы Вы привести схему Вашего приемника. Для ознакомления. Ведь она явно отлична от классического представления. И на словах ничего не понятно.

Если любит, то почему бы тогда конвеер из 10-ти лишних тактов не впиндюрить. Или из 100? Кашу маслом не испортишь.



Так, значит счётчик сэмплов всё-таки сущетвует. Можно конечно делать выборку с каждым отсчётом и потом голосовать. На мой взгдяд -- параноя. Проще выбирать один раз в серёдке, как все делают. Дополнительные биты как раз употребить счётчик 4-х битный. Да и без разницы наверное, что делать многобитный делитель основной частоты до 3х baudrate или перекинуть пару бит из него на SampleCnt для 16х baudrate, а точность вычисления центра битового интервала повысится.



Как можно не считая биты узнать, что кадр окончился?





В моём поримании, стробирование = выборка, стробирующий сигнал -- синхросигнал. Какое отношение данный процесс имеет к ФНЧ я совершенно не представляю. Вообще, каждый вкладывает свой смысл в данное слово. Так что разъяснение. Особенно это отноится любителям изобретать собственные термины вроде "бодовыех байтов". Но раз уж они обижаются на просьбу о разъяснении смысла своих мудрёных слов, предпочитая вместо этого удар промеж глаз, я умываю руки. Себя по голове ударь.


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

//Как можно не считая биты узнать, что кадр окончился?

Это пишу уже в третий раз - до приема регистр[9:0] (в который будем сдвигать) устанавливаем ВСЕМИ "1", сдвигаем ТАКЖЕ и стартовый бит(который "0") - стартовый "0" добрался до скажем конца (регистр[9] ==0) -> это значит в Вашем понимании "кадр" принялся.

под "бодовым байтом" я понимаю информационный "байт" + служебные биты(старт, стопы, четность).
В вашем понимании это кадр - что тоже не коректно,
тк кадром называют отдельный сегмент на более высоком уровне в транспортной моделе OSI.
Хотя Кто-то нам подскажет точное название, приведенное в стандарте.

А стробирование - думаю для любого инженера работающего с ПЛИС понятно как - пропуск асинхронного входа через тригер с глобальной тактовой ПЛИС

Привожу проект. Но тк это был мой первый пробный проект, то я в нем отрабатывал саму идею реализации. Поэтому это не универсальный стандарт RS232, а конкретная задача, правильность выполнения в живую проверялась в HyperTerminale Винды.

Задача: скорость 115200, без паритета, 8 байт, один стоповый. Принимаем "байт" от компа -> суммируем с предыдущим принятым "байтом" и отправляем результат обратно в комп.
На компе контролируем правильность работы по сумме скан-кодов.

Схема блоками (наглядная) (МЖФ входной, FSM и "общий блок")

Изображение уменьшено (67.65 килобайт)

Простой FSM (в графике наглядней)

Изображение уменьшено (33.13 килобайт)

Сам код "Общего блока" - по нему наврное будет больше всего вопросов(коментил мало) - задавайте.


И общий проект модуль на Verilog
 RS232.zip ( 1.45 килобайт ) Кол-во скачиваний: 271



PS Принимаются замечания по стилю описания на Verilog!!! Совершенству - нет предела.

Сам текст понятен. А вот идея всегда будет вызывать споры. Да и кто, когда будет reset нажимать.
Это монолог. Отвечать не обязательно. В качестве ответа приемник (без бита паритета)

module rxd_232
(
input ti_20, ///// 20mhz // 115200
input rxd,
output reg [7:0] rg_rs232_out,
output reg ochibka_kadra,
output reg int_rs232_cpu
);

reg [1:0] dff_meta_rx;
reg [7:0] ct_period;
reg [3:0] ct_bit;
reg dff_enable_work;
reg stop;
reg [8:0] rg_rs232;

wire clr_enable_work;

always @ (posedge ti_20)
begin
dff_meta_rx <= {dff_meta_rx[0], rxd};
if (dff_meta_rx[1] & ~dff_enable_work) ct_period <= 8'h00;
else if (ct_period == 8'd173) ct_period <= 8'h00;
else ct_period <= ct_period + 1'b1;
if (dff_enable_work == 1'b0) ct_bit <= 4'h0;
else if ((ct_period == 8'd87) & (ct_bit != 4'h8)) ct_bit <= ct_bit + 1'b1;
end

assign clr_enable_work = stop | (dff_meta_rx[1] & ~dff_enable_work);

always @ (posedge ti_20 or posedge clr_enable_work)
begin
if (clr_enable_work) dff_enable_work <= 1'b0;
else if (ct_period == 8'd87) dff_enable_work <= 1'b1;
end

always @ (posedge ti_20)
begin
if ((ct_period == 8'd87) & dff_enable_work) rg_rs232[ct_bit] <= dff_meta_rx[1];
stop <= (ct_period == 8'd87) & (ct_bit == 4'h8);
int_rs232_cpu <= stop;
if (stop) begin
rg_rs232_out <= rg_rs232[7:0];
ochibka_kadra <= ~rg_rs232[8]; end
end

endmodule

reset должен быть, потомучто нету такого блока (для не SRAM ПЛИС проект)

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

Мне он кажется проще - избавились от некоторых критичных элементов (хотя бы точность определения старта)

Кста на AHDL я (как и Вы) тоже прием кадра разворачивл временой диаграмой по счетчикам - мне тоже нравится так.
Но на Verilog'e решил попробовать по-другому - идейку подкинули про МЖФ -> и получилось

Reset не обязателен. Система сама должна переходить в начальное состояние по прошествии в нашем случае 11 тактов значения 1 в линии. Ваша идея не отличается простотой. Она выскальзывает как уж при попытке анализа. Да и невозможно при спорности самой идеи проверить досканально все частные возможные случаи. Например промоделируйте состояние 20 тактов 1, четверть такта 0, 20 тактов 1.

Да и раасогласование в скорости приемника и передатчика может быть как сплюсом, так и с минусом

Теперь понял. Отслеживалка числа принятых битов совмещёна в сдвиговом регистре с данными. Прежде не доходило, как такое возможно, хотя протогол rs232 основан на этой идее. В таком случае отдельный счётчик бит действительно не нужен.

Но. Попробуте как я грузить битики данных с rs232 прямо в регистр контроллера (контроллер -- набор регистров команд с логикой для управления FPGA системой, команды принимаются по с компьютера по rs232). Придётся выход каждого регистра инициализировать единицами и снабжать выходной связью на rs232 приёмник, ведь стартовый бит будет путешествовать каждый раз по новому регистру. Куча регистров -- много нелокальных связей. Компактный счётчик возле rs232-автомата выйдет дешевле. К тому же совершенно не обязательно, что все загружаемые таким непосредственным образом регистры будут 8-битные.

Да и сам сброс в единицы как реализуется? 9 мультиплксоров подле каждой ячейки данных выбирают между 1 и shift_in. Может 3-битный счётчик принятых битов всё же экономнее?




А они не объяснили -- на фига МЖФ, если без него работает идеально надёжно?

Этот ресет нужен обязательно при включении питания ПЛИС, а не для проекта. (я же говорю это НЕ SRAM-ПЛИС, а флеш)
Подается от простого монитора питания, когда установилось.


кста про четверть такта "0" - он и не поймет что был ноль - так и будет единица. А вот если >=2/3 такта "0", тогда есть вероятность что схватит "левый старт".
Но ваш метод тоже схватит "левый ноль" >=1/2 такта - он же проверит снова в середине -> и будет принимать ...

Этот ресет нужен обязательно при включении питания ПЛИС, а не для проекта. (я же говорю это НЕ SRAM-ПЛИС, а флеш)
Подается от простого монитора питания, когда установилось./////
А вот это уже интересно. Причем тут включение плис, и тем более его структура. Это работает на любой структуре Альтеры, у Xilinx работал только на FPGA 3000 тысячнике без всяких там прммитивов установки сетапов.
Если речь об Эктел, снимаю шляпу. Такой хоккей нам не нужен.

Что-то вы не сразу догадались про определение не SRAM-ПЛИС
Не сталкивались видать... Там просто нет цепей сброса по причине того, что универсальная ячейка может быть как тригером так и логической функцией.

Что-то вы не сразу догадались про определение не SRAM-ПЛИС
Не сталкивались видать... Там просто нет цепей сброса по причине того, что универсальная ячейка может быть как тригером так и логической функцией./////

Я не стал догадываться. Еще раз повторю. Нет необходимости в цепях сброса. Не имеет значения в каком состоянии все триггеры по включению. Дались Вам эти нули. Система сама должна переходить в начальное состояние при наличии в линии 1. И при этом подстраивать свои внутренние часы по каждому стопу. Иначе грош цена такой схеме.

Не думаю, что хорошая идея завязыватся на сигнал 1 на линии. От него ничего толового не сделать.
Я же написал, что Вы правильно предположили производителя ПЛИС - поэтому сигнал сброса нужен по-определению(поверьте!).

А по подстраивание по стопу я не понял - или, если это Вы совместно с начальным состоянием при наличие 1 на линии - то я про это уже написал.

Спасибо большое за идею(или даже за решение). Сделал как Вы советуете - работает как часы.

Упс. Тут уже даже код появился. Я правда все равно в VHDL писал

Сообщение отредактировал sanek78 - Sep 26 2006, 09:27

О! Если это Вы будете и дальше эксплуатировать в устройстве, то можно будет получить реальную проверку работоспособности такой реализации...
Напишите здесь о результатах?!