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

 

[sazh]

Сам текст понятен. А вот идея всегда будет вызывать споры. Да и кто, когда будет 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

[Kopart]

Сам текст понятен. А вот идея всегда будет вызывать споры. Да и кто, когда будет reset нажимать.

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

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

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

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