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

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

maksya
Я бы поставил простенький МК + драйвер.
На нём реализовать протокол управления устройством и т.д.
Связь с FPGA - по внешней шине или SPI.
З.Ы. Реализовывал вышеперечисленную схему, а также UART в FPGA. В качестве основы взял Xilinx appnote213 (кажется). Всё работало как часы.

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

Сообщение отредактировал Chudik - May 19 2006, 00:04

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

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

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

Удачи!

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

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

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

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

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

Из оптимизации ресурсов:
Один счетчик нужен только для полученния 3-х кратной частоты (можно и не на счетчике)
Второй считает до Трех (определяет, что уже следиший бит в канале)

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

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

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

1. да
2. нет
3. может
4. перебор
5. конечно

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

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

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


я думаю UART надо делать самому
1 если UART снимут с производства вас эта беда не затронет
2 цена изделия будет меньше
3 у вас будет свой UART CORE и если соберетесь что то делать позже у вас будет рабочий модуль

удачи

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

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

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
Ага, посмотрел, спасибо.

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

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

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



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

Сообщение отредактировал Alexandr - May 19 2006, 20:17