[maksya 0]

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

 

Есть задача: между платой и датчиками существует 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

[ASN 0]

maksya

Я бы поставил простенький МК + драйвер.

На нём реализовать протокол управления устройством и т.д.

Связь с FPGA - по внешней шине или SPI.

З.Ы. Реализовывал вышеперечисленную схему, а также UART в FPGA. В качестве основы взял Xilinx appnote213 (кажется). Всё работало как часы.

[Chudik 0]

Присоединяюсь к ASN: почему бы не поставить махонький микроконтроллер, подключить его к трём управляемым буферам и соединить этот МК к твоей FPGA? Имхо, это гораздо проще, чем самому творить UART.

Изменено 19 мая, 2006 пользователем Chudik

[prototype 2]

Насколько мне известно, в классическом построении UART используется опорный клок в 16 раз больше скорости передачи. Переход в ноль вызывает синхронизацию процесса и запуск автомата, затем берется выборка значений на 8, 9 и 10 клоке и при совпадении двух из трех - определяется значение бита. Если в старт бите пришел не ноль, цифровой автомат сбрасывается в исходное состояние. При наличии старт - бита автомат принимает все в соответствии с форматом (7 или 8 бит, 1, 2 или 1,5 стоп - бита) - выборка значений аналогично старт - биту. Принятый байт записывается в выходной регистр (ФИФО). После чего автомат останавливается и ждет следующего старт - бита.

А вообще-то народ прав - микроконтроллер и драйверы позволят все сделать быстрее и с меньшим геммороем.

[vladec 12]

Зачем чего то придумывать? У Xilinx-а есть готовые очень компактные и проверенные UARTы, разработанные для использования с ядрами PicoBlaze (см. Xapp627 для Spartan3 и Xapp213 для Spartan2). Кстати и сами ядра для такой задачи можно использовать, а внешний контроллер здесь, на мой взгляд, избыточен.

[iosifk 3]

В качестве ядра системы предполагаю использовать FPGA (естественно не только для целей обмена с датчиками).

5. Есть ли у кого опыт решения похожей задачи?

 

Вы не написали - какого объема FPGA Вы планируете использовать? UART - это классика, этому студентов учат и готовых море. Если FPGA большого объема, то ставить что-то снаружи - не выгодно, можно ставить только преобразователи уровней.

И еще, а нужно ли 3 независимых канала? Насколько велик поток информации? Если есть возможность, то подайте выход ОДНОГО UARTа на мультиплексор и берите данные по-очередно с каждого из трех каналов. Или можно сделать LIN и все повесить на один провод.

PLL там совершенно не нужна. Вполне хорошо работает стандартный прием 16-ти кратной частоты с 3-мя отсчетами по каждому импульсу. Далее мажоритар из этих 3-х отсчетов и все дела. Посмотрите на то, как сделана периферия к микроконтроллерам, там на блок-схеме все понятно.

 

Удачи!

[sazh 8]

А хорошо Вам преподавали в Вузе. Налицо подход настоящего железячника. И првильно Вы пожметиди. Все на сегодня предложенные реализации этопо сути решения применяемые в микроконтроллерах. так ведь там по другому и не сделать. Ох уж эта присловутая мажоритарность.

Нет необходимости в микроконтроллерах при наличии FPGA. А приемник делается за день. Глвное преимущество, его можно реализовать на несущей глобальной частоте (хоть в 256 раз выше, точнее серидину нащупаете). При этом не надо будет заботиться о синхронизации этих потоков от датчиков внутри FPGA для обработки информации. И не надо ресурсы экономить. Сегодня это ничего не стоит. Я уже выкладывал на верилоге проект в этой конференции. Поищите по rs232. Там и обнаружение стартового бита, и мажоритарность, все в кучу. Наверно работает, раз не растерзали.

[Kopart 0]

В качестве ядра системы предполагаю использовать FPGA (естественно не только для целей обмена с датчиками).

5. Есть ли у кого опыт решения похожей задачи?

PLL там совершенно не нужна. Вполне хорошо работает стандартный прием 16-ти кратной частоты с 3-мя отсчетами по каждому импульсу. Далее мажоритар из этих 3-х отсчетов и все дела. Посмотрите на то, как сделана периферия к микроконтроллерам, там на блок-схеме все понятно.

 

Своей первой разработкой на Verilog'e я сделал RS-232 приемо-передатчик, который проверял в HyperTerminal'e.

 

Не понимаю для чего 16-ти кратная частота?

 

У меня использовалась опорная частота(40мГц) из которой на простом счетчике получалась 3-х кратная частота(по отношению к скорости передачи). (Для скоростей RS - производительности счетчика хватит с лихвой)

На входе сигнала RX в ПЛИС стоял мажоритарный фильтр (фильтрация сигнал по опорной частоте), а далее такой же МЖ фильтр работащий на опорной частоте, но с разрешением по 3-х кратной частоте передачи.

 

Получалось, по "0" на входном МЖФ(по 2-ум из 3-х значений) -> стартовый, а дальше из каждых 3 значений на МЖФ определяем значения принимаемого бита.

 

Из оптимизации ресурсов:

Один счетчик нужен только для полученния 3-х кратной частоты (можно и не на счетчике)

Второй считает до Трех (определяет, что уже следиший бит в канале)

 

У меня он был расчитан на фиксированое значение бит в передаче (что не обязательно) - это позволило не использователь счетчик принятых битов, а использовать один решистр на все биты (от стартового до стопого). В начале инициализируем его всеми "1" , а затем когда стартовый бит задвинется в начало -> посылка принята :)

 

Аналогичный подход и к регистру передаче. Сколько занимает можно по пальцам пересчитать.

 

Так что удобней делать на ПЛИС и гибкость больше...

[Motorhead 0]

P.S.: Резюмируя вышесказанное, прошу по возможности ответить на следующие вопросы:

1. Применяются ли сейчас отдельные микросхемы UART'ов? Есть ли варианты UART+драйвер RS-232 в одном корпусе?

2. Обязательно ли использовать PLL для этой задачи?

3. Приложенный VHDL код UART'а (или аналогичный ему) может гарантировать правильный обмен информацией?

4. К месту ли применение аппаратных встроенных в ПЛИС блоков SERDES?

5. Есть ли у кого опыт решения похожей задачи?

 

1. да

2. нет

3. может

4. перебор

5. конечно

 

[Alexandr 0]

Однозначно за ПЛИС. PLL не нужна - у Вас на ПЛИС в любом случае должен тактовый сигнал заходить, так вот его и делите. Причем не обязательно чтоб он был кратен скорости обмена по RS232. Я писал UART - так в нем я использовал частоту в 10 раз больше бодовой (а не классическую 16) и все нормально работало. Контроллеры не нужны в данном случае вообще. Какая разница что писть для ПЛИС - UART или SPI? Не на много сложнее, а разводка платы упростится.

[Iouri 0]

http://www.quicklogic.com/images/appnote20.pdf

 

посмотрите здесь может пригодится

 

 

я думаю UART надо делать самому

1 если UART снимут с производства вас эта беда не затронет

2 цена изделия будет меньше

3 у вас будет свой UART CORE и если соберетесь что то делать позже у вас будет рабочий модуль

 

удачи

[ASN 0]

Alexandr

На МК удобно реализовать протокол обмена с ПЭВМ, сохранение настроек в ЭСППЗУ и т.п.

Зачем экономить - то?

[maksya 0]

Прям мозговой штурм какой-то :)

 

7.5 : 2.5 в пользу ПЛИС! Пожалуй на этом и остановимся. Теперь по порядку.

 

2 ASN

МК не очень то хочется ставить. И дело не только в счете (см. выше). Во-первых не уверен, что есть варианты 3 UART'а в одном корпусе МК. Во-вторых, надо предусмотреть запись программы МК в память команд. Для остальных задач ТЗ МК пока не требуется, так что вот как-то так. А вот то, что VHDL-код UART'а - не липа, это Я рад слышать.

 

2 Chudik

Честно сказать, на VHDL лично для меня проще материться, чем на языке Ц.

 

prototype

Про классическое представление Я вроде как сам и написал :) Ну ничего, повторенье - мать. Только если Я правильно понял, то при реализации в ПЛИС, пуск автомата приемника возникает НЕ по спаду сигнала в линии (т.к. воспринимать это событие как falling_edge сигнала не совсем корректно в идеалогии ПЛИС), а по факту обнаружения последовательности 00..0, записанных в регистр с частотой в несколько раз больше бодовой.

 

vladec

Ядро UART, ядро PicoBlaze... Это сколько же бутылок мне надо сдать, чтобы приобрести все это? Ах, да, забыл сказать - с Xilinx'ом не работал, и в ближайшее время наверное не буду работать. Ориентируюсь на Altera. За ссылки спасибо, посмотрю.

 

iosifk

- Скорее всего Циклон буду брать, т.к. опыт работы с ним есть.

- Насчет мультиплекса - Допустим на вход по трем RS-каналам приходят одновременно кадры. Частота выборки тогда увеличится в 3 раза (чтобы успеть типа за один "такт" опросить все 3 канала)? Да и как быть с передатчиками? Что если захотим опять же по трем каналам выплюнуть кадры? Time Slicing в таком случае не прокатит (или Я ошибаюсь?). Думаю на UART'ах экономить не буду, поставлю 3. Остальной алгоритм ТЗ не настолько сложен, чтоб вести учет каждого триггера.

- LIN - это что за зверь (извините за неграмотность)?

- Про PLL осознал, больше не буду.

- Насчет мажоритара - если частота выборки значения линии в 16 раз выше бодовой, то для мажоритара выбирают 3 отчета примерно посередине битового интервала?

 

sazh

чего то не нашел Вашего проекта, да и VHDL мне ближе Verilog'а. Но все-равно спасибо.

 

NiOS

Мажоритарный фильтр - это вроде сдвигающего регистра? Вроде того, что когда в нем появится как минимум 2 нуля, то считаем что пришел старт-бит и разрешаем работу дальнейших схем?

 

Motorhead

лаконично

 

Alexandr

Брать "какую попало" частоту... А ничего там с метастабильностью не возникнет? И вот еще - ошибка в данном случае (если фронт частоты выборки вдруг совпадет с перепадом на линии) отсеется за счет мажоритарности?

 

Iouri

Ага, посмотрел, спасибо.

[rezident 0]

Микроконтроллер нужно выбирать в соответствии с предполагаемым кругом задач. Если нет МК с требуемой периферией, то имеет смысл рассматирвать систему из отдельных CPU, RAM, и Flash, а всю необходимую периферию реализовать в FPGA. Делали несколько проектов для военных, дык там в FPGA было и 4 и даже 6 UARTов плюс еще пара MIL-STD, задача крутилась на DSP (совсем хиленьком, кстати) с внешней RAM и Flash. Готовый МК со столь развестистой периферией просто не найти.

[Alexandr 0]

Alexandr

На МК удобно реализовать протокол обмена с ПЭВМ, сохранение настроек в ЭСППЗУ и т.п.

Зачем экономить - то?

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

 

Ух, пока писал еще посты появились

 

Alexandr

Брать "какую попало" частоту... А ничего там с метастабильностью не возникнет? И вот еще - ошибка в данном случае (если фронт частоты выборки вдруг совпадет с перепадом на линии) отсеется за счет мажоритарности?

 

Да, частоту выборки можно брать любую, но большую бодовой скорости хотя бы раз в 8. Насчет того что "фронт частоты выборки совпадет с перепадом на линии" я вообще не понял как это может быть. Поясню, идея работы таже, по старт-биту запускаем генератор с частотой в N раз большей бодовой скорости и выборку производим на N/2-1, N/2, N/2+1 импульсах генератора. С метастабильностью полный порядок, ибо генератор получаем делением из частоты на которой работает ПЛИС.

Изменено 19 мая, 2006 пользователем Alexandr