реклама на сайте
подробности

 
 
> RS-232 + FPGA
maksya
сообщение May 18 2006, 20:52
Сообщение #1


Местный
***

Группа: Свой
Сообщений: 253
Регистрация: 28-08-04
Из: Ленинград
Пользователь №: 562



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

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

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

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

В классическом представлнии (в соответствии с остаточными знаниями, полученными в ВУЗе) приемник должен запустить свой внутренний генератор (работающий с частотой, например, в 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
 


--------------------
Лень - это не врожденное чувство русского человека, а средство борьбы с неуемной, но бестолковой энергией начальника.
Go to the top of the page
 
+Quote Post
6 страниц V   1 2 3 > »   
Start new topic
Ответов (1 - 88)
ASN
сообщение May 18 2006, 21:09
Сообщение #2


Местный
***

Группа: Свой
Сообщений: 459
Регистрация: 15-07-04
Из: g.Penza
Пользователь №: 326



maksya
Я бы поставил простенький МК + драйвер.
На нём реализовать протокол управления устройством и т.д.
Связь с FPGA - по внешней шине или SPI.
З.Ы. Реализовывал вышеперечисленную схему, а также UART в FPGA. В качестве основы взял Xilinx appnote213 (кажется). Всё работало как часы.
Go to the top of the page
 
+Quote Post
Chudik
сообщение May 19 2006, 00:03
Сообщение #3


Частый гость
**

Группа: Свой
Сообщений: 197
Регистрация: 31-03-06
Пользователь №: 15 676



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

Сообщение отредактировал Chudik - May 19 2006, 00:04
Go to the top of the page
 
+Quote Post
prototype
сообщение May 19 2006, 04:48
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 513
Регистрация: 1-02-05
Из: Харьков, СССР
Пользователь №: 2 334



Насколько мне известно, в классическом построении UART используется опорный клок в 16 раз больше скорости передачи. Переход в ноль вызывает синхронизацию процесса и запуск автомата, затем берется выборка значений на 8, 9 и 10 клоке и при совпадении двух из трех - определяется значение бита. Если в старт бите пришел не ноль, цифровой автомат сбрасывается в исходное состояние. При наличии старт - бита автомат принимает все в соответствии с форматом (7 или 8 бит, 1, 2 или 1,5 стоп - бита) - выборка значений аналогично старт - биту. Принятый байт записывается в выходной регистр (ФИФО). После чего автомат останавливается и ждет следующего старт - бита.
А вообще-то народ прав - микроконтроллер и драйверы позволят все сделать быстрее и с меньшим геммороем.
Go to the top of the page
 
+Quote Post
vladec
сообщение May 19 2006, 05:21
Сообщение #5


Профессионал
*****

Группа: Свой
Сообщений: 1 167
Регистрация: 3-10-05
Из: Москва
Пользователь №: 9 158



Зачем чего то придумывать? У Xilinx-а есть готовые очень компактные и проверенные UARTы, разработанные для использования с ядрами PicoBlaze (см. Xapp627 для Spartan3 и Xapp213 для Spartan2). Кстати и сами ядра для такой задачи можно использовать, а внешний контроллер здесь, на мой взгляд, избыточен.
Go to the top of the page
 
+Quote Post
iosifk
сообщение May 19 2006, 05:44
Сообщение #6


Гуру
******

Группа: Модераторы
Сообщений: 4 011
Регистрация: 8-09-05
Из: спб
Пользователь №: 8 369



Цитата(maksya @ May 19 2006, 00:52) *
В качестве ядра системы предполагаю использовать FPGA (естественно не только для целей обмена с датчиками).
5. Есть ли у кого опыт решения похожей задачи?


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

Удачи!


--------------------
www.iosifk.narod.ru
Go to the top of the page
 
+Quote Post
sazh
сообщение May 19 2006, 06:35
Сообщение #7


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



А хорошо Вам преподавали в Вузе. Налицо подход настоящего железячника. И првильно Вы пожметиди. Все на сегодня предложенные реализации этопо сути решения применяемые в микроконтроллерах. так ведь там по другому и не сделать. Ох уж эта присловутая мажоритарность.
Нет необходимости в микроконтроллерах при наличии FPGA. А приемник делается за день. Глвное преимущество, его можно реализовать на несущей глобальной частоте (хоть в 256 раз выше, точнее серидину нащупаете). При этом не надо будет заботиться о синхронизации этих потоков от датчиков внутри FPGA для обработки информации. И не надо ресурсы экономить. Сегодня это ничего не стоит. Я уже выкладывал на верилоге проект в этой конференции. Поищите по rs232. Там и обнаружение стартового бита, и мажоритарность, все в кучу. Наверно работает, раз не растерзали.
Go to the top of the page
 
+Quote Post
Kopart
сообщение May 19 2006, 07:42
Сообщение #8


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(iosifk @ May 19 2006, 09:44) *
Цитата(maksya @ May 19 2006, 00:52) *

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

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


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

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

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

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

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

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

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

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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
Motorhead
сообщение May 19 2006, 09:14
Сообщение #9


Участник
*

Группа: Новичок
Сообщений: 22
Регистрация: 24-04-06
Пользователь №: 16 436



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


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

biggrin.gif
Go to the top of the page
 
+Quote Post
Alexandr
сообщение May 19 2006, 12:04
Сообщение #10


Знающий
****

Группа: Модераторы
Сообщений: 804
Регистрация: 1-12-04
Пользователь №: 1 283



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


--------------------
Иван Сусанин - первый полупроводник
Go to the top of the page
 
+Quote Post
Iouri
сообщение May 19 2006, 12:27
Сообщение #11


Местный
***

Группа: Свой
Сообщений: 364
Регистрация: 11-07-05
Пользователь №: 6 707



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

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


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

удачи
Go to the top of the page
 
+Quote Post
ASN
сообщение May 19 2006, 19:30
Сообщение #12


Местный
***

Группа: Свой
Сообщений: 459
Регистрация: 15-07-04
Из: g.Penza
Пользователь №: 326



Alexandr
На МК удобно реализовать протокол обмена с ПЭВМ, сохранение настроек в ЭСППЗУ и т.п.
Зачем экономить - то?
Go to the top of the page
 
+Quote Post
maksya
сообщение May 19 2006, 19:39
Сообщение #13


Местный
***

Группа: Свой
Сообщений: 253
Регистрация: 28-08-04
Из: Ленинград
Пользователь №: 562



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

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

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

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

prototype
Про классическое представление Я вроде как сам и написал smile.gif Ну ничего, повторенье - мать. Только если Я правильно понял, то при реализации в ПЛИС, пуск автомата приемника возникает НЕ по спаду сигнала в линии (т.к. воспринимать это событие как 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
Ага, посмотрел, спасибо.


--------------------
Лень - это не врожденное чувство русского человека, а средство борьбы с неуемной, но бестолковой энергией начальника.
Go to the top of the page
 
+Quote Post
rezident
сообщение May 19 2006, 19:39
Сообщение #14


Гуру
******

Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882



Микроконтроллер нужно выбирать в соответствии с предполагаемым кругом задач. Если нет МК с требуемой периферией, то имеет смысл рассматирвать систему из отдельных CPU, RAM, и Flash, а всю необходимую периферию реализовать в FPGA. Делали несколько проектов для военных, дык там в FPGA было и 4 и даже 6 UARTов плюс еще пара MIL-STD, задача крутилась на DSP (совсем хиленьком, кстати) с внешней RAM и Flash. Готовый МК со столь развестистой периферией просто не найти.
Go to the top of the page
 
+Quote Post
Alexandr
сообщение May 19 2006, 20:01
Сообщение #15


Знающий
****

Группа: Модераторы
Сообщений: 804
Регистрация: 1-12-04
Пользователь №: 1 283



Цитата(ASN @ May 19 2006, 23:30) *
Alexandr
На МК удобно реализовать протокол обмена с ПЭВМ, сохранение настроек в ЭСППЗУ и т.п.
Зачем экономить - то?

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

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

Цитата(maksya @ May 19 2006, 23:39) *
Alexandr
Брать "какую попало" частоту... А ничего там с метастабильностью не возникнет? И вот еще - ошибка в данном случае (если фронт частоты выборки вдруг совпадет с перепадом на линии) отсеется за счет мажоритарности?


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

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


--------------------
Иван Сусанин - первый полупроводник
Go to the top of the page
 
+Quote Post
prototype
сообщение May 20 2006, 04:44
Сообщение #16


Знающий
****

Группа: Свой
Сообщений: 513
Регистрация: 1-02-05
Из: Харьков, СССР
Пользователь №: 2 334



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

Собственно я об этом и говорил. Именно так. Три и мажоритирование - для повышения помехоустойчивости. Я когда-то делал в ПЛИС именно со стартом по отрицательному фронту, поэтому так и написал. Хотя с точки зрения той же помехоустойчивости возможно искать несколько нулей подряд и более правильно. Просто меня в свое время результат устроил и я не стал заморачиваться. smile.gif
Go to the top of the page
 
+Quote Post
ASN
сообщение May 20 2006, 04:56
Сообщение #17


Местный
***

Группа: Свой
Сообщений: 459
Регистрация: 15-07-04
Из: g.Penza
Пользователь №: 326



Alexandr
А вот если адаптировать систему под любой интерфейс, протокол, даже тот которого не было на момент создания, то лучше всё же МК (ISP, EEPROM, ADC, DAC, Flash (как FSM - равный памяти программ)) заложить (например, для токового интерфейса).
Вообще, рекомендовать какое-то решение сложно. Могу предложить несколько на выбор (драйвер включаются во все решения):
1.PSOC (например, на основе PicoBlaze + UART ). Достоинство – всё в одном флаконе. Недостатки – надо обучиться работать с PicoBlaze.
2.Готовый UART Exar 16С554 + MK (типа PIC16,Mega16) для его управления. Достоинство – всё уже готово. Недостатки – жёсткое решение, место на плате, дорого.
3.Тоже Exar + FPGA для управления. Достоинства – простота реализации. Недостатки – избыточность.
4.Полностью софтовые UART в МК. Достоинство – всё в одном флаконе, очень дёшево. Недостатки – сложность реализации ПО, пониженная помехоустойчивость.
5. FPGA (XC3S400) для реализации UART + MK реализации высокоуровневых протокол обмена данными. Достоинства – гибкость + мощность. Недостатки – больше место на плате.
IMHO, всё зависит от стоимости, сроков и желания обучаться glare.gif
Go to the top of the page
 
+Quote Post
DeadMoroz
сообщение May 20 2006, 08:56
Сообщение #18


Местный
***

Группа: Свой
Сообщений: 211
Регистрация: 3-02-05
Пользователь №: 2 391



Если Вам необходим микроконтроллер с 3мя UARTами, то могу посоветовать Cygnal C8051F130, у него 2 аппаратных + 1(или несколько) можно забабахать программных, я такое делал. Но всеже советую сделать на FPGA, это насамом деле несложно. Посмотрите мою реализацию, это простенький UART с фиксированной скоростью и режимом (опять же ненапряжно переделывается под настраиваемый). Использовал его в 2х поектах + FIFO на прием и передачу.
Прикрепленные файлы
Прикрепленный файл  UARTv1.rar ( 1.73 килобайт ) Кол-во скачиваний: 255
 
Go to the top of the page
 
+Quote Post
maksya
сообщение May 20 2006, 10:07
Сообщение #19


Местный
***

Группа: Свой
Сообщений: 253
Регистрация: 28-08-04
Из: Ленинград
Пользователь №: 562



Цитата(Alexandr @ May 20 2006, 00:01) *
Да, частоту выборки можно брать любую, но большую бодовой скорости хотя бы раз в 8. Насчет того что "фронт частоты выборки совпадет с перепадом на линии" я вообще не понял как это может быть. Поясню, идея работы таже, по старт-биту запускаем генератор с частотой в N раз большей бодовой скорости и выборку производим на N/2-1, N/2, N/2+1 импульсах генератора. С метастабильностью полный порядок, ибо генератор получаем делением из частоты на которой работает ПЛИС.
Про "фронт частоты выборки совпадет с перепадом на линии" это Я погорячился. Просто сначала в голову залезла тупая идея - хранить все отсчеты сигнала в линии, записываемые с частотой N*бодовая. В таком случае возможно, что очередной отчет попадет на момент переключения в линии. Отсюда и метастабильность. Но теперь, переварив все сообщения в купе с бутылочкой пива, исправил свои заблуждения.


--------------------
Лень - это не врожденное чувство русского человека, а средство борьбы с неуемной, но бестолковой энергией начальника.
Go to the top of the page
 
+Quote Post
Kopart
сообщение May 20 2006, 19:49
Сообщение #20


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(Alexandr @ May 20 2006, 00:01) *
Да, частоту выборки можно брать любую, но большую бодовой скорости хотя бы раз в 8. Насчет того что "фронт частоты выборки совпадет с перепадом на линии" я вообще не понял как это может быть. Поясню, идея работы таже, по старт-биту запускаем генератор с частотой в N раз большей бодовой скорости и выборку производим на N/2-1, N/2, N/2+1 импульсах генератора. С метастабильностью полный порядок, ибо генератор получаем делением из частоты на которой работает ПЛИС.


Для чего брать частоту больше раз в 8, чем бодовая??? Я же писал, что нужна частота только в 3!!! раза больше, чем бодовая, один МЖФ, ну и второй МЖФ для фильтрации входа.

Могу привести код работающего проекта на Verilog’e (хотя он только для скорости 115.200, без проверки паритета и с одним стоповым)

Как это происходит (повторяюсь и уточняю).

При входе сигнала RX (UART’a) постоянно работающий входной МЖФ– для фильтрации коротких пичков на линии. Принцип работы МЖФ - из трех последовательных отсчетов он выбирает 2 совпадающих.

А дальше счетчик работающий от основной частоты 40 МГц считает до ‘d114 и сбрасывается – получается частота 3*бодовая (крутится постоянно без сброса по стартовому биту!)

А теперь, как счетчик == 114 я на один такт разрешаю продвинуть данные во втором МЖФ.
Мне без разнице, в какой части «бодового» бита, на МЖФ защелкнутся три значения (может даже одно значение попасть из другого «бодового» бита, а может попасть на перепад(в обычном RS-232 он пологий получается) – для такого подхода это «фиолетово») -> а второй счетчик считает, когда (первый счетчик==114) уже 3 раз и на выходе второго МЖФ получаю значение «бодового» бита, которой и вдвигаю.

Когда автомат, находясь в «idle», получил значение «бодового» бита «0» -> это стартовый -> задвигаю в регистр [9:0] (в «idle» инициализированный всеми «1») -> как стартовый «0» добрался до конца регистра [9:0] -> всё посылка принята!

И не нужна НИКАКАЯ синхронизация при стартовом бите, и внутри бита – просто по двум из трех значений определяется значение бита.

Дописал - посмотрел – слов много, а объяснил ли?
В общем, если что не понятно на буднях смогу привести код (это более универсальный язык =8) )


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sazh
сообщение May 21 2006, 10:56
Сообщение #21


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



To NIOS
Хороший подход. Можно пойти еще дальше. Отказаться от стопового бита. Ведь Вам он не нужен.
Экономия на лицо.
Go to the top of the page
 
+Quote Post
Kopart
сообщение May 22 2006, 10:26
Сообщение #22


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(sazh @ May 21 2006, 14:56) *
To NIOS
Хороший подход. Можно пойти еще дальше. Отказаться от стопового бита. Ведь Вам он не нужен.
Экономия на лицо.


Рад, что поняли мой проект smile.gif

А хорошее замечание! Только кто придумывал стандарт в то время, это не предусмотрели.
Видать тогда частоты работы были значительно меньше, поэтому нужно было переходное состояние для "отпускания" линии(стоповый бит) + определение, что дальше пошел новый стартовый (ИМХО).


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
Motorhead
сообщение May 22 2006, 10:59
Сообщение #23


Участник
*

Группа: Новичок
Сообщений: 22
Регистрация: 24-04-06
Пользователь №: 16 436



[quote name='NiOS' date='May 20 2006, 23:49' post='115298']
[quote name='Alexandr' post='115057' date='May 20 2006, 00:01']
При входе сигнала RX (UART’a) постоянно работающий входной МЖФ– для фильтрации коротких пичков на линии. Принцип работы МЖФ - из трех последовательных отсчетов он выбирает 2 совпадающих.
[/quote]

2 совпадающих должны быть рядом?
Go to the top of the page
 
+Quote Post
Gorby
сообщение May 22 2006, 12:20
Сообщение #24


Местный
***

Группа: Свой
Сообщений: 449
Регистрация: 28-10-04
Из: Украина
Пользователь №: 1 002



[quote name='Motorhead' date='May 22 2006, 14:59' post='115735']
[quote name='NiOS' date='May 20 2006, 23:49' post='115298']
[quote name='Alexandr' post='115057' date='May 20 2006, 00:01']
При входе сигнала RX (UART’a) постоянно работающий входной МЖФ– для фильтрации коротких пичков на линии. Принцип работы МЖФ - из трех последовательных отсчетов он выбирает 2 совпадающих.
[/quote]

2 совпадающих должны быть рядом?
[/quote]

Нет. Просто должно быть МИНИМУМ два одинаковых из трех.


--------------------
Умею молчать на 37 языках...
Go to the top of the page
 
+Quote Post
Kopart
сообщение May 22 2006, 12:22
Сообщение #25


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(Motorhead @ May 22 2006, 14:59) *
2 совпадающих должны быть рядом?


выходное значение учитывает предысторию из трех последовательных входных.

Если отвечать в лоб на Ваш вопрос, то они могут быть как подряд (1,2 и 2,3), так и через один(1,3) smile.gif

Привожу свой код МЖФ на Verilog'e
Код
wire ena;
reg [2:0] dd;
always @ (posedge rst or clk)
  if (rst)
      dd[2:0] <= #T 3'b111;  
  else if (ena)
           dd[2:0] <= #T {dd[1:0], in};

reg out;
always @ (posedge rst or clk)
  if (i_rst)
      out <= #T 1'b1;
  else if (ena)
           out <= #T (dd[0]&dd[1])|(dd[0]&dd[2])|(dd[1]&dd[2]);


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
Motorhead
сообщение May 22 2006, 12:43
Сообщение #26


Участник
*

Группа: Новичок
Сообщений: 22
Регистрация: 24-04-06
Пользователь №: 16 436



Цитата(NiOS @ May 22 2006, 16:22) *
Цитата(Motorhead @ May 22 2006, 14:59) *

2 совпадающих должны быть рядом?


выходное значение учитывает предысторию из трех последовательных входных.

Если отвечать в лоб на Ваш вопрос, то они могут быть как подряд (1,2 и 2,3), так и через один(1,3) smile.gif

Привожу свой код МЖФ на Verilog'e
Код
wire ena;
reg [2:0] dd;
always @ (posedge rst or clk)
  if (rst)
      dd[2:0] <= #T 3'b111;  
  else if (ena)
           dd[2:0] <= #T {dd[1:0], in};

reg out;
always @ (posedge rst or clk)
  if (i_rst)
      out <= #T 1'b1;
  else if (ena)
           out <= #T (dd[0]&dd[1])|(dd[0]&dd[2])|(dd[1]&dd[2]);



Все понятно, непонятно зачем ena сигнал.
Пусть всегда щелкает.
Go to the top of the page
 
+Quote Post
Kopart
сообщение May 22 2006, 12:52
Сообщение #27


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(Motorhead @ May 22 2006, 16:43) *
Все понятно, непонятно зачем ena сигнал.
Пусть всегда щелкает.


Не хотел удалять smile.gif Привел универсальный модуль.

По существу: во входном МЖФ можно без ena (или вставить как модул, и на него подать VCC), а вот во втором МЖФ он уже обязательно нужен (за период "бодовой" частоты должно быть только 3 входных воздействия)


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
Vital_100
сообщение May 27 2006, 04:34
Сообщение #28





Группа: Новичок
Сообщений: 12
Регистрация: 23-05-06
Пользователь №: 17 367



Никогда не писал кода для RS, но когда потребовалось, сделал. Если не считать времени на отладку, то задача по моему разумению вообще тривиальная. Преобразователь уровня и... все остальное в FPGA. Вкалывает за милую душу. Делаю четырехкратную проверку бита, но думаю что можно и меньше, наверное это может обезопасить при высоких скоростях передачи. А так проблем не было!
Go to the top of the page
 
+Quote Post
afsh
сообщение May 30 2006, 18:00
Сообщение #29


Участник
*

Группа: Новичок
Сообщений: 21
Регистрация: 30-05-06
Пользователь №: 17 574



С метастабильностью полный порядок, ибо генератор получаем делением из частоты на которой работает ПЛИС.
[/quote]

Внешний сигнал асинхронен, так что проблемы могут быть
Go to the top of the page
 
+Quote Post
grigorybold
сообщение Jul 3 2006, 10:58
Сообщение #30


Участник
*

Группа: Свой
Сообщений: 32
Регистрация: 8-01-05
Из: г. Воронеж
Пользователь №: 1 845



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

Можно сделать, что генератор скорости бод будет работать всегда. При приходе фронта сигнала (т.е. начала старт- импульса) запускается конечный автомат приёмника. После приёма формируется импульс, фиксирующийся в контроллере прерываний. После обработки данного запроса микроконтроллер сбрасывает этот бит в контроллере.
Таким образом промимо ядра RS-232 вам требуется ещё напмсить ядро контроллера прерываний.
RS-232 у меня занял 3 экрана verilog- кода, приоритетный контроллер прерываний - тоже 3 экрана.
Go to the top of the page
 
+Quote Post
Wild
сообщение Jul 3 2006, 15:41
Сообщение #31


Местный
***

Группа: Участник
Сообщений: 216
Регистрация: 26-05-06
Из: Коломна
Пользователь №: 17 479



Цитата(sazh @ May 21 2006, 14:56) *
To NIOS
Хороший подход. Можно пойти еще дальше. Отказаться от стопового бита. Ведь Вам он не нужен.
Экономия на лицо.


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

Если в схеме с делением битового интервала на 16 частей и выборке 3х средних значений, к моменту приема последнего бита такая выборка может "уплыть" от центра битового интервала к его краю, то есть на время, приблизительно равное половине битового интервала, то при предложенном NIOSом методе, искажение данных произойдет, если выборка "уплывет" хотя бы на треть.
Go to the top of the page
 
+Quote Post
sazh
сообщение Jul 3 2006, 18:38
Сообщение #32


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



Не надо вырывать эту фразу из контекста обсуждения. Иногда имеет смысл довести что то до обсурда, чтобы подчеркнуть ошибочность того или иного мнения.
Go to the top of the page
 
+Quote Post
Wild
сообщение Jul 4 2006, 10:10
Сообщение #33


Местный
***

Группа: Участник
Сообщений: 216
Регистрация: 26-05-06
Из: Коломна
Пользователь №: 17 479



Цитата(sazh @ Jul 3 2006, 22:38) *
Не надо вырывать эту фразу из контекста обсуждения. Иногда имеет смысл довести что то до обсурда, чтобы подчеркнуть ошибочность того или иного мнения.

sazh, простите, я может не совсем понял что вы имеете ввиду, но вы с чем не согласны: с утверждением о необходимости синхронизировать приемник с передатчиком, более плохим показателем устойчивости к рассинхронизации предложенной NIOSом схемы или про стоп бит вы пошутили а я не понял?
Go to the top of the page
 
+Quote Post
vikk
сообщение Jul 4 2006, 11:27
Сообщение #34


Частый гость
**

Группа: Свой
Сообщений: 98
Регистрация: 13-01-06
Пользователь №: 13 134



bb-offtopic.gif
круто! a14.gif
ну вы блин даете!
этож можно человека до самоубийства довести таким количеством советов! )))
по делу ничего сказать не могу - уже все сказали, разжевали и проглотили.
но с шутками надо осторожнее )))
разве что фильтр по-моему не обязателен вовсе.
Go to the top of the page
 
+Quote Post
sazh
сообщение Jul 4 2006, 16:56
Сообщение #35


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



To Wild. Вы все правильно говорили. А я не шутил. Просто когда по теме rs232 столько копий сломано, а воз и ныне там, уже нет мочи говорить прописные истины. Они просты. Не трогай технику, и она тебя не тронет. Есть старт, есть стоп, значит так надо. Мне вообще непонятно для чего в приемнике эта мажоритарность. Это же не МК. По большому счету и подход при работе с собственным клоком, позволяющий нащупать середину стартового бита, отрицает необходимость мажоритарности. Если Вы досчитали до середины стартового бита, попали в энегетический центр сигнала, зачем анализировать, что слева или справа. Разве это улучшит надежность приемника. Да только ухудшит, если рассогласования частот приемника и передатчика значимы. У меня подход прост.
При перепаде из 1 в 0 анализирую наличие этого нуля в интервале 1/2 длительности бита (меньше 1/2 это не старт, снова ждем перепад), если 0 значит это середина старта, открываю временной интервал работы и нарезаю фронтом по центру длительностью в период бита. На месте где должен быть стоп закрываю интервал и анализирую на наличие 1. Если 0 ошибка кадрирования и дальше принимаем решение, что игнорируем слово или массив.
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 6 2006, 08:13
Сообщение #36


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(Wild @ Jul 3 2006, 19:41) *
Позвольте с вами не согласиться. Стоповый бит необходим для того чтобы устанавливать синхронизацию приемника и передатчика, так как в общем случае два уарта работают на немного разных частотах необходимо более или менее точно определить момент начала передачи байта, чтобы даже после небольшой рассинхронизации можно было быть уверенным, что снимаемое с линии значение последнего бита, действительно соответствует последнему биту а не соседнему сним.

Если в схеме с делением битового интервала на 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 бита Вы получает удобство по компактности реализации и простоте алгоритма приема.

Цитата(sazh @ Jul 4 2006, 20:56) *
Мне вообще непонятно для чего в приемнике эта мажоритарность. Это же не МК. По большому счету и подход при работе с собственным клоком, позволяющий нащупать середину стартового бита, отрицает необходимость мажоритарности. Если Вы досчитали до середины стартового бита, попали в энегетический центр сигнала, зачем анализировать, что слева или справа. Разве это улучшит надежность приемника. Да только ухудшит, если рассогласования частот приемника и передатчика значимы. У меня подход прост.

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

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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
javalenok
сообщение Jul 10 2006, 08:57
Сообщение #37


Местный
***

Группа: Участник
Сообщений: 290
Регистрация: 18-02-06
Пользователь №: 14 469



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

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

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

Но вообще идея использовать сдвиг вместо подсчёта бит заслуживает рассмотрения. Парадоксально, но декодер на N адресов в FPGA занимает вдвое больше ресурсов, чем цепочка из N FF-ов.
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 10 2006, 10:20
Сообщение #38


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(javalenok @ Jul 10 2006, 12:57) *
Вы хоть обозначайте кому пишите! А лучше ставьте цитаты, того на что отвечаете.
Про комментирую то, что покажется обращено ко мне.

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

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

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

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

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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
javalenok
сообщение Jul 10 2006, 11:18
Сообщение #39


Местный
***

Группа: Участник
Сообщений: 290
Регистрация: 18-02-06
Пользователь №: 14 469



Цитата(NiOS @ Jul 10 2006, 13:20) *
Цитата

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

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

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


Да, ну и откуда ты узнаешь, что подступил новый байт? Выбирать надо в серёдке, для этого надо сделать отступ от переднего фронта старт-бита. Далее, как ты определишь, что пора сдвигать, если не по собственным часам? Ведь rs232 -- не манчестер и данные не несут синхроинформации в каждом инфобите. В довершение вы собирались отказаться от стопового. Представим, что стартовый и все данные -- нули. Ну и как без стопа узнать о начале нового кадра?

И в порядке любопытства, вы не ответили чем мажоритарный фильтр, манкирующий временную информацию, лучше обычного гистерезиса низких частот, пропускающего только те образцы, что похожи на соседей? Вам фильтрация нужна, как я догадываюсь, именно для предотвращения ложных срабатываний (сдвигов). Это связанно с вашей оригинальной схемой синхронизации (предполагающей, отсутствие синхронизации? -- извините, не понял до конца всей магии). Делаю вывод, что в схеме с центральной выборкой фильтровать нечего, если конечно вы не собираетесь докладывать пользователю об ошибках/подозрениях.

Цитата(NiOS @ Jul 10 2006, 13:20) *
Цитата

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

Поподробнее откуда такие циферки?


1/16 * 100%



Цитата(NiOS @ Jul 10 2006, 13:20) *
Цитата

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

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

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


Тут тоже какое-то досадное замешательство. Полагаю от того, что вопрос-ответ приводится в стековой последовательности и надо читать:
[1]
- Никто не сказал про метастабильность, ... автомат в полный беспорядок.
+ Из непонятного состояния всегда можно выйти по таймауту.


[2]
- идея использовать сдвиг вместо подсчёта бит заслуживает рассмотрения. декодер на [i]N адресов в FPGA занимает вдвое больше ресурсов, чем цепочка из N FF-ов.
+ если я правильно понял - то нужен еще счетчик битов([3:0] макс до 12)[/i]

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

Ну а что до подсчёта бит, разве мыслимо его вести без счётчика?

Сообщение отредактировал javalenok - Jul 10 2006, 11:26
Go to the top of the page
 
+Quote Post
Wild
сообщение Jul 10 2006, 12:10
Сообщение #40


Местный
***

Группа: Участник
Сообщений: 216
Регистрация: 26-05-06
Из: Коломна
Пользователь №: 17 479



http://www.xilinx.com/xlnx/xweb/xil_tx_dis...hX_ID=kc_srl16e

NIOS, решение предложенное вами безусловно имеет право на существование.
Кстати интересно, Ваш уарт занимал бы меньше вышеописанного, если бы у него была такая же функциональность?

Сообщение отредактировал Wild - Jul 10 2006, 12:11
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 11 2006, 08:35
Сообщение #41


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(javalenok @ Jul 10 2006, 15:18) *
Да, ну и откуда ты узнаешь, что подступил новый байт?

Есть "фильтр" на входе сигнала RX в ПЛИС
У меня это сделано с помощью МЖФ (фильтрует лучше), но можно и просто стробировать основной частотой проекта.
На выходе(когда автомат в idle) появился "0" - переходим в прием (STATE_RECEIVE)
Цитата
Выбирать надо в серёдке, для этого надо сделать отступ от переднего фронта старт-бита. Далее, как ты определишь, что пора сдвигать, если не по собственным часам?

ЕЩЕ раз - я не выбираю в середке!!!
У меня ВСЕГДА есть утроенная частота бодовой скорости (Я ее НЕ синхронизую со стартом!!!)
Далее (когда в состоянии STATE_RECEIVE) - считаю эту частоту и по каждому третьему фронту вдигаю в регистр выход МЖФ (его код уже приводил(там есть enable))

Для кого-то в коде понятней smile.gif
Код
if(STATE_RECEIVE & counter==2'h3)
           rx_reg[9:0] <= #T {out(MZHF),rx_reg[9:1]};

Цитата
В довершение вы собирались отказаться от стопового. Представим, что стартовый и все данные -- нули. Ну и как без стопа узнать о начале нового кадра?

ЕЩЕ раз повторяю - я знаю сколько битов в "бодовом байте" - те выбрал глубину сдвигового регистра.
!!!!!!!!!!!!!!!В "idle" я его устанавливаю всеми "1" и вдвигаю ВСЕ биты и СТАРТ!!!!!!!!!!!!!!!!!!!!!!!!
Стартовый ВСЕГДА "0" - на пример вдвигаю с "конца" - добрался "0" до "начала" регистра - значит стоповый уже вдвинулся.
Цитата
И в порядке любопытства, вы не ответили чем мажоритарный фильтр, манкирующий временную информацию, лучше обычного гистерезиса низких частот, пропускающего только те образцы, что похожи на соседей? Вам фильтрация нужна, как я догадываюсь, именно для предотвращения ложных срабатываний (сдвигов).

Я наверное не столь продвинут в фильтрации. Но о Вашем вопросе с умными словами нужно думать вместе с теорией фильтров и спектрами пропушенных сигналов. Да и вопрос зачем? Задача немного другая. Хотя (если сможете) приведите HDL описание "обычного гистерезиса низких частот, пропускающего только те образцы, что похожи на соседей?" - может вы о простых вещах по умному smile.gif

Опять повторяю - фильтрация нужна - чтобы не синхронизоватся и при этом ДВА отсчета будут около центра бита

Цитата
Ну а что до подсчёта бит, разве мыслимо его вести без счётчика?

Ваше сообщение "Парадоксально, но декодер на N адресов в FPGA занимает вдвое больше ресурсов, чем цепочка из N FF-ов."
Декодер на N адрессов можно реализовать и без счетчика smile.gif

Но учитывай, что прийдется дабовлять как минимум один лишний FF в цепочку - для старта smile.gif


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
javalenok
сообщение Jul 11 2006, 10:26
Сообщение #42


Местный
***

Группа: Участник
Сообщений: 290
Регистрация: 18-02-06
Пользователь №: 14 469



Цитата(NiOS @ Jul 11 2006, 11:35) *
Я наверное не столь продвинут в фильтрации. Но о Вашем вопросе с умными словами нужно думать вместе с теорией фильтров и спектрами пропушенных сигналов. Да и вопрос зачем? Задача немного другая. Хотя (если сможете) приведите HDL описание "обычного гистерезиса низких частот, пропускающего только те образцы, что похожи на соседей?" - может вы о простых вещах по умному smile.gif

Опять повторяю - фильтрация нужна - чтобы не синхронизоватся и при этом ДВА отсчета будут около центра бита


Я сам принцып FIR фильтра представляю лишь отдалённо, но фильтр низких частот (сглаживающий) должен пропускать только стабильный сигнал, убирая переменную составляющюю. Вы говорите, что мажоритарный подавляет случайные пички. Но каким же образом, если он у вас пропустит 10101010 -- сплошные пички? "Пропускать только те образцы, что похожи на соседей" -- это и есть фильтр низких частот, вам уже задвали вопрос о двух одниаковых значениях подряд. В чередующемся ряду 10101010 все соседние значения отличны. Фильтр низких частот должен сгладить ряд и получить среднее значение 0.5 -- где-то по-середине между 0 и 1. Имеет место неопределённость. 0 тянет "вниз", 1 -- "наверх", в среднем движения не происходит. ФНЧ с 2-значной историей решит эту задачу -- будет считать, что значение не меняется. Все пички отфильтруются. Так чем мажоритарный лучше? По-моему, пичков вообще быть не должно, самое точное значение в центре, а не на границе бита.



Цитата(NiOS @ Jul 11 2006, 11:35) *
ЕЩЕ раз - я не выбираю в середке!!! У меня ВСЕГДА есть утроенная частота бодовой скорости (Я ее НЕ синхронизую со стартом!!!) Далее (когда в состоянии STATE_RECEIVE) - считаю эту частоту и по каждому третьему фронту вдигаю в регистр выход МЖФ (его код уже приводил(там есть enable))

1-й и 3-й -- это как раз граничные обрызцы, они могут относится к другому биту. Вы же их цените на равне со средним. Может ну их, эти выборы -- баловство? Просто сдвигать в данные состояние среднего когда счётчик сэмплов переваливает через 2? И вообще от посреднечества сдвигового регистра отказаться, грузить Rx прямо в rx_reg[0]? У меня именно так сделано -- без детских игр в голосование. Так что я думаю вопрос Вильда: "NIOS, решение предложенное вами безусловно имеет право на существование. Кстати интересно, Ваш уарт занимал бы меньше вышеописанного, если бы у него была такая же функциональность?" имеет отницательный ответ. Ваша конструкция -- избыточна, она сложнее аналогов и не имеет права на существование.



И для чего вы выход своего mzf регистра дополнительно регистируете? Конвееризация biggrin.gif ?


Цитата(NiOS @ Jul 11 2006, 11:35) *
ЕЩЕ раз повторяю - я знаю сколько битов в "бодовом байте" - те выбрал глубину сдвигового регистра.
!!!!!!!!!!!!!!!В "idle" я его устанавливаю всеми "1" и вдвигаю ВСЕ биты и СТАРТ!!!!!!!!!!!!!!!!!!!!!!!!
Стартовый ВСЕГДА "0" - на пример вдвигаю с "конца" - добрался "0" до "начала" регистра - значит стоповый уже вдвинулся.

Я тоже знаю сколько бит в кадре (выражение "бодовый байт" слышу впервые, смысл не ясен). Но это не значит, что стоповый бит смысла не имеет. Он необходим для отделения начала нового кадра. Старт можно гарантированно увидеть только на фоне стопа.

Значит у вас вместо 10-битного счётчика принятых бит используется 10-битный сдвиговый регистр иль вы его как-то совмещаете с регистром принимаемых данных? Если первое, что что-то мне подсказывает, что счётчиком счетать биты эффективнее.



Цитата(NiOS @ Jul 11 2006, 11:35) *
Ваше сообщение "Парадоксально, но декодер на N адресов в FPGA занимает вдвое больше ресурсов, чем цепочка из N FF-ов."
Декодер на N адрессов можно реализовать и без счетчика smile.gif

Но учитывай, что прийдется дабовлять как минимум один лишний FF в цепочку - для старта smile.gif


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

Заменить счётчик + декодер на один сдвиговый регистр, пускай длины +1, не получится. Нужно два сдвиговых: первый 8 бит для приёма данных и другой -- круговая лента 10-ти состояний FSM приёмника (приём старт, данных, стопа). Так вот принимать данные мне кажется экономнее в сдвиговый регистр по сравнению с кодированными ячейками, а состояние машины всёж лучше держать в счётчике, благо полного декодирования для управления машиной не требуется, поскольку автомат должен вести себя одинаково для всех бит данных и синтезатор должен это здорово оптимизировать.

Сообщение отредактировал javalenok - Jul 11 2006, 10:44
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 12 2006, 07:03
Сообщение #43


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(javalenok @ Jul 11 2006, 14:26) *
Но каким же образом, если он у вас пропустит 10101010 -- сплошные пички?

Вы знаете что такое простое "стробирование по входу" - так вот МЖФ на входе это просто лучше.
При таком сигнале на входе Вам ни какой фильтр не позволит принять сигнал стандарта RS-232.
Речь шла о статистически случайных одиночных пичках сигнала на паде ПЛИС, которые МЖФ сглаживает лучше, чем стробирование.
Цитата
1-й и 3-й -- это как раз граничные обрызцы, они могут относится к другому биту. Вы же их цените на равне со средним. Может ну их, эти выборы -- баловство?
И вообще от посреднечества сдвигового регистра отказаться, грузить Rx прямо в rx_reg[0]? У меня именно так сделано -- без детских игр в голосование.


Нельзя ориентироватся по среднему - тк я не синхронизую отсчеты с началом бита и этот средний не будет в центре - в центре будет другой средний smile.gif smile.gif smile.gif

Так там Verilog'ом по белому и написано, что "грузится Rx прямо в rx_reg[0] "

Цитата
И для чего вы выход своего mzf регистра дополнительно регистируете? Конвееризация biggrin.gif ?

В каком месте (коде) я это написал????

Цитата
Но это не значит, что стоповый бит смысла не имеет. Он необходим для отделения начала нового кадра. Старт можно гарантированно увидеть только на фоне стопа.

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

Цитата
Значит у вас вместо 10-битного счётчика принятых бит используется 10-битный сдвиговый регистр иль вы его как-то совмещаете с регистром принимаемых данных?

У меня есть регистр, в который я сдвигаю данные, и откуда можо забирать информационый байт.
И помимо этого я его же использую при передаче - только в обратную сторону.
И вобщето сдвиговый регистр хранит то, что в него вдвинули.
Цитата
Ну декодер -- часть демукса, выбирает ячейку, которая будет грузится в следующий момент.

Понятие "декодер" - в оригинале это просто демукс, а счетчик это уже другое понятие smile.gif


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
javalenok
сообщение Jul 12 2006, 14:18
Сообщение #44


Местный
***

Группа: Участник
Сообщений: 290
Регистрация: 18-02-06
Пользователь №: 14 469



Цитата(NiOS @ Jul 12 2006, 10:03) *
Цитата(javalenok @ Jul 11 2006, 14:26) *

Но каким же образом, если он у вас пропустит 10101010 -- сплошные пички?

Вы знаете что такое простое "стробирование по входу" - так вот МЖФ на входе это просто лучше.
При таком сигнале на входе Вам ни какой фильтр не позволит принять сигнал стандарта RS-232.
Речь шла о статистически случайных одиночных пичках сигнала на паде ПЛИС, которые МЖФ сглаживает лучше, чем стробирование.

"Cтробирование по входу"? Не слышал. Это байда навроде "бодового байта"? Вообще я спрашивал о приемуществах мажоритарного против фильтра низких частот, а не против некоего "стробирования по какому-то входу". Последовательность 1010101 вполне реальна, если выборка делается не в середине битового интервала, а в моменты смены бит, как у вас -- две крайние выборки имеют силу наравне с центральной. Но если вам нечего ответить, кроме "МЖФ на входе это просто лучше", вопрос снимается. Лучше наверное пониженной надёжностью и повышенной громоздкостью чем ФНЧ, при условии что фильтр -- вообще не нужен.


Цитата(NiOS @ Jul 12 2006, 10:03) *
Цитата

1-й и 3-й -- это как раз граничные обрызцы, они могут относится к другому биту. Вы же их цените на равне со средним. Может ну их, эти выборы -- баловство?
И вообще от посреднечества сдвигового регистра отказаться, грузить Rx прямо в rx_reg[0]? У меня именно так сделано -- без детских игр в голосование.

Нельзя ориентироватся по среднему - тк я не синхронизую отсчеты с началом бита и этот средний не будет в центре - в центре будет другой средний smile.gif smile.gif smile.gif

Так там Verilog'ом по белому и написано, что "грузится Rx прямо в rx_reg[0] "


Вы регистрируете выборки для МЖФ в произвольные моменты времени? Тогда какой смысл вообще отлавливать начало кадра, вести счётчик сэмплов бита? Всё равно приёмник rs232 не будет работать, поскольку это -- синхронный протокол. У него битовые интервалы отстоят от начала кадра на фиксированное время. Следовательно надо синхронизироватся с началом кадра и следить за за временем для выборки бита. И мажоритарный фильтр тут не поможет, синхронный протокол -- требует большего, чем фильтрация пичков.

А последняя фраза означает: "данные со входа Rx грузятся в сдвиговый регистр в обход мажоритарного фильтра". В таком случае вопрос о целесообразности его привлечения должен бы решиться сам собой. Но это только если чехи доели мацу.


Цитата(NiOS @ Jul 12 2006, 10:03) *
Цитата

И для чего вы выход своего mzf регистра дополнительно регистируете? Конвееризация biggrin.gif ?

В каком месте (коде) я это написал????


Я, конечно не знаток верилога, но
Код
always @ (posedge rst or clk)
if (ena)
           out <= #T (dd[0]&dd[1])|(dd[0]&dd[2])|(dd[1]&dd[2]);



Цитата(NiOS @ Jul 12 2006, 10:03) *
Для асинхронных одиночных кадров совсем не обязателен стоповый бит, а вот для нескольких последовательных кадров - стоповый, скорее, нужен, чтобы на длином промежутке значительной не была рассинхронизация приемника и передатчика.

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


Цитата(NiOS @ Jul 12 2006, 10:03) *
Цитата

Значит у вас вместо 10-битного счётчика принятых бит используется 10-битный сдвиговый регистр иль вы его как-то совмещаете с регистром принимаемых данных?

У меня есть регистр, в который я сдвигаю данные, и откуда можо забирать информационый байт.
И помимо этого я его же использую при передаче - только в обратную сторону.

Снова на красной площади сидели чехи и ели мацу палочками. У вас счётчик бит хранит поступающие данные, чтоб его можно на сдвиговый регистр заменить? Допустим у меня вообще сдвигает в тот регистр контроллера, который надо загрузить, без всяких промежуточных регистров и в полнодуплексном режиме. Что я теперь, должен так гордиться, чтоб использовать это как универсальный ответ на все вопросы?

Цитата(NiOS @ Jul 12 2006, 10:03) *
И вобщето сдвиговый регистр хранит то, что в него вдвинули.

Правда, что ли? Никога бы ни подумал. Хорошо, что вы это написали, так бы и оставался в неведении. А если ничего не вдвигали -- ничего не хранит? glare.gif

Сообщение отредактировал javalenok - Jul 12 2006, 14:28
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 12 2006, 15:05
Сообщение #45


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



А есть ли смысл разговаривать с человеком, который даже не удосужился перед ответом "не слышал" попробовать посмотреть в любои поиске слово "стробирование". twak.gif
А особено который имеет дело с ПЛИС!!

На пару актуальных вопросиков отвечу:

1. Да согласен - есть лишний такт на выходе МЖФ, впесто простого assign <wire>=...
Но он ничего не меняет в алгоритме. Он нужен тк FPGA - "любит" синхронный дизайн.

2. Счетчик я использую только, чтобы считать отсчеты (до 3х) внутри бита. САМИ биты я не считаю!


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sazh
сообщение Jul 12 2006, 18:45
Сообщение #46


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



TO NIOS:
А не могли бы Вы привести схему Вашего приемника. Для ознакомления. Ведь она явно отлична от классического представления. И на словах ничего не понятно.
Go to the top of the page
 
+Quote Post
javalenok
сообщение Jul 13 2006, 00:42
Сообщение #47


Местный
***

Группа: Участник
Сообщений: 290
Регистрация: 18-02-06
Пользователь №: 14 469



Цитата(NiOS @ Jul 12 2006, 18:05) *
1. Да согласен - есть лишний такт на выходе МЖФ, впесто простого assign <wire>=...
Но он ничего не меняет в алгоритме. Он нужен тк FPGA - "любит" синхронный дизайн.


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


Цитата(NiOS @ Jul 12 2006, 18:05) *
2. Счетчик я использую только, чтобы считать отсчеты (до 3х) внутри бита.

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


Цитата(NiOS @ Jul 12 2006, 18:05) *
САМИ биты я не считаю!

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



Цитата(NiOS @ Jul 12 2006, 18:05) *
А есть ли смысл разговаривать с человеком, который даже не удосужился перед ответом "не слышал" попробовать посмотреть в любои поиске слово "стробирование". twak.gif
А особено который имеет дело с ПЛИС!!


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

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

Во-во, мозги всем запарил якобы оригинальной простотой своей схемы, магическим сдвигом, не требующим синхронизации и счётчиков, когда на самом деле она содержит лишние компоненты.
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 13 2006, 07:26
Сообщение #48


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



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

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

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

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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 13 2006, 08:01
Сообщение #49


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(sazh @ Jul 12 2006, 22:45) *
TO NIOS:
А не могли бы Вы привести схему Вашего приемника. Для ознакомления. Ведь она явно отлична от классического представления. И на словах ничего не понятно.


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

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

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


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


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

//Mj_filter bitov--------------------------------------------
wire en_bit;
reg [2:0] dd;
always @ (posedge i_rst or posedge i_clk)
  if (i_rst)
      dd[2:0] <= #T 3'b111;  
  else if (en_bit)
           dd[2:0] <= #T {dd[1:0], rx_filt};

reg rx_bit;
always @ (posedge i_rst or posedge i_clk)
  if (i_rst)
      rx_bit <= #T 1'b1;
  else if (en_bit)
           rx_bit <= #T (dd[0]&dd[1])|(dd[0]&dd[2])|(dd[1]&dd[2]);

//End Mj_filter bitov-----------------------------------------

//Counter clk - Из 40МГЦ получает утроенную 115200
reg [7:0] cnt;
always @ (posedge i_rst or posedge i_clk)
if (i_rst)
     cnt[7:0] <= #T 8'h0;  
else if (cnt[7:0] == 8'd144 ) cnt[7:0] <= #T 8'h0;  
      else
          cnt[7:0] <= #T cnt[7:0] + 8'h1;
//------------------------------------------------------------
//Counter 3x i_clk
reg [1:0] cnt_bit;        
always @ (posedge i_rst or posedge i_clk)
if (i_rst)
     cnt_bit[1:0] <= #T 2'h0;  
else if (cnt_bit[1:0] == 2'h3)  cnt_bit[1:0] <= #T 2'h0;  
else if ((st_rx | st_tx) & cnt==7'd114)  
            cnt_bit<=#1 cnt_bit + 1;
//----------------------------------------------------------------
// Main Block
reg [9:0]rx_tx;      // Типа общего сдвигового регистра для передачи и приема
reg [7:0] rx_reg;    // Регистр для хранения предыщего принятого значения, с которым симмирется нынешнее (циклически)  
  always @ (posedge i_rst or posedge i_clk)
   if (i_rst) begin
               rx_tx[9:0] <= #T 10'h0;
               rx_reg[7:0]<= #T 8'h0;         // Save RX data
              end
   else if(st_idle)
           rx_tx <= #T 10'h3ff;
   else if(st_rx & cnt_bit==2'h3)
           rx_tx[9:0] <= #T {rx_bit,rx_tx[9:1]};
   else if(st_ready)  begin
                       rx_reg[7:0]<= #T rx_tx[8:1] + rx_reg[7:0];
                       rx_tx[8:1] <= #T rx_reg[7:0];
                      end
   else if(st_tx & cnt_bit==2'h3)
           rx_tx[9:0] <= #T {1'b1,rx_tx[9:1]};
//---------------------------------------------------------------

//
assign en_bit = (st_rx & cnt==7'd114) ? 1'b1:1'b0;
assign end_rx = (st_rx & rx_tx[0]==1'b0 & rx_tx[9])?1'b1:1'b0;
assign end_tx = (rx_tx[9:0] == 10'h3ff & st_tx) ? 1'b1:1'b0;
assign o_tx   = (st_tx)?rx_tx[0]:1'b1;
//---------------------------------------------------------------

assign o_data[3:0] = rx_reg[3:0];


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



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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sazh
сообщение Jul 13 2006, 09:46
Сообщение #50


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



Сам текст понятен. А вот идея всегда будет вызывать споры. Да и кто, когда будет 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
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 13 2006, 10:02
Сообщение #51


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(sazh @ Jul 13 2006, 13:46) *
Сам текст понятен. А вот идея всегда будет вызывать споры. Да и кто, когда будет reset нажимать.

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

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

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

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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sazh
сообщение Jul 13 2006, 10:13
Сообщение #52


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



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

Да и раасогласование в скорости приемника и передатчика может быть как сплюсом, так и с минусом
Go to the top of the page
 
+Quote Post
javalenok
сообщение Jul 13 2006, 12:32
Сообщение #53


Местный
***

Группа: Участник
Сообщений: 290
Регистрация: 18-02-06
Пользователь №: 14 469



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

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

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


Цитата
идейку подкинули про МЖФ -> и получилось


А они не объяснили -- на фига МЖФ, если без него работает идеально надёжно?
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 13 2006, 14:48
Сообщение #54


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(sazh @ Jul 13 2006, 14:13) *
Reset не обязателен.

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


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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sazh
сообщение Jul 13 2006, 16:49
Сообщение #55


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



Этот ресет нужен обязательно при включении питания ПЛИС, а не для проекта. (я же говорю это НЕ SRAM-ПЛИС, а флеш)
Подается от простого монитора питания, когда установилось./////
А вот это уже интересно. Причем тут включение плис, и тем более его структура. Это работает на любой структуре Альтеры, у Xilinx работал только на FPGA 3000 тысячнике без всяких там прммитивов установки сетапов.
Если речь об Эктел, снимаю шляпу. Такой хоккей нам не нужен.
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 18 2006, 09:08
Сообщение #56


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



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

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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sazh
сообщение Jul 18 2006, 18:57
Сообщение #57


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



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

Я не стал догадываться. Еще раз повторю. Нет необходимости в цепях сброса. Не имеет значения в каком состоянии все триггеры по включению. Дались Вам эти нули. Система сама должна переходить в начальное состояние при наличии в линии 1. И при этом подстраивать свои внутренние часы по каждому стопу. Иначе грош цена такой схеме.
Go to the top of the page
 
+Quote Post
Kopart
сообщение Jul 19 2006, 06:52
Сообщение #58


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(sazh @ Jul 18 2006, 22:57) *
Что-то вы не сразу догадались про определение не SRAM-ПЛИС
Не сталкивались видать... Там просто нет цепей сброса по причине того, что универсальная ячейка может быть как тригером так и логической функцией./////

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


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

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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sanek78
сообщение Sep 26 2006, 09:15
Сообщение #59


Участник
*

Группа: Новичок
Сообщений: 20
Регистрация: 31-08-06
Пользователь №: 19 985



Цитата(NiOS @ May 20 2006, 21:49) *
Для чего брать частоту больше раз в 8, чем бодовая??? Я же писал, что нужна частота только в 3!!! раза больше, чем бодовая, один МЖФ, ну и второй МЖФ для фильтрации входа.

Могу привести код работающего проекта на Verilog’e (хотя он только для скорости 115.200, без проверки паритета и с одним стоповым)

Как это происходит (повторяюсь и уточняю).

При входе сигнала RX (UART’a) постоянно работающий входной МЖФ– для фильтрации коротких пичков на линии. Принцип работы МЖФ - из трех последовательных отсчетов он выбирает 2 совпадающих.

А дальше счетчик работающий от основной частоты 40 МГц считает до ‘d114 и сбрасывается – получается частота 3*бодовая (крутится постоянно без сброса по стартовому биту!)

А теперь, как счетчик == 114 я на один такт разрешаю продвинуть данные во втором МЖФ.
Мне без разнице, в какой части «бодового» бита, на МЖФ защелкнутся три значения (может даже одно значение попасть из другого «бодового» бита, а может попасть на перепад(в обычном RS-232 он пологий получается) – для такого подхода это «фиолетово») -> а второй счетчик считает, когда (первый счетчик==114) уже 3 раз и на выходе второго МЖФ получаю значение «бодового» бита, которой и вдвигаю.

Когда автомат, находясь в «idle», получил значение «бодового» бита «0» -> это стартовый -> задвигаю в регистр [9:0] (в «idle» инициализированный всеми «1») -> как стартовый «0» добрался до конца регистра [9:0] -> всё посылка принята!

И не нужна НИКАКАЯ синхронизация при стартовом бите, и внутри бита – просто по двум из трех значений определяется значение бита.

Дописал - посмотрел – слов много, а объяснил ли?
В общем, если что не понятно на буднях смогу привести код (это более универсальный язык =8) )



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

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

Сообщение отредактировал sanek78 - Sep 26 2006, 09:27
Go to the top of the page
 
+Quote Post
Kopart
сообщение Sep 27 2006, 18:01
Сообщение #60


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(sanek78 @ Sep 26 2006, 13:15) *
Спасибо большое за идею(или даже за решение). Сделал как Вы советуете - работает как часы. a14.gif


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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sanek78
сообщение Sep 28 2006, 12:14
Сообщение #61


Участник
*

Группа: Новичок
Сообщений: 20
Регистрация: 31-08-06
Пользователь №: 19 985



Я диплом пишу, поэтому результат может быть только на уровне прототипа(пока). Но соединить DSP с FPGA(Starter Kit) получилось, данные передаются по SCI на 115к. Соединил двумя проводами на 15см. Интересно правда посмотреть что получится, когда рядом преобразователь частоты начнет долбить. Где-то через месяц напишу, как алгоритм с помехами справляется.
Go to the top of the page
 
+Quote Post
Леха
сообщение Nov 22 2006, 10:58
Сообщение #62


Участник
*

Группа: Свой
Сообщений: 73
Регистрация: 18-06-04
Из: Минск
Пользователь №: 55



Товарищи, а если FPGA (ACEX) висит на PCI, то чем лучше тактировать
UART (использовать PCI клок или внешний завести) ?
Go to the top of the page
 
+Quote Post
klop
сообщение Nov 22 2006, 12:17
Сообщение #63


Местный
***

Группа: Свой
Сообщений: 433
Регистрация: 28-02-06
Пользователь №: 14 788



Цитата(Леха @ Nov 22 2006, 10:58) *
Товарищи, а если FPGA (ACEX) висит на PCI, то чем лучше тактировать
UART (использовать PCI клок или внешний завести) ?

А посчитать влом? А со вторым тактовым - Вы готовы к работе с двумя клоковыми доменами?
Go to the top of the page
 
+Quote Post
Леха
сообщение Nov 22 2006, 12:27
Сообщение #64


Участник
*

Группа: Свой
Сообщений: 73
Регистрация: 18-06-04
Из: Минск
Пользователь №: 55



Посчитать не влом. Вопрос про корректность и надёжность работы при использовании PCI клока.
Говорят, что этот клок не шибко стабилен и на некоторых материнках может заметно отличаться
от 33 МГц. Кто-нибудь в серийных изделиях использовал его для UART-ов ?

А двух клоковых доменов боюсь как огня, так как никогда не сталкивался с такой ситуацией.
Но если надо - освоим.
Go to the top of the page
 
+Quote Post
klop
сообщение Nov 22 2006, 13:03
Сообщение #65


Местный
***

Группа: Свой
Сообщений: 433
Регистрация: 28-02-06
Пользователь №: 14 788



Цитата(Леха @ Nov 22 2006, 12:27) *
Посчитать не влом. Вопрос про корректность и надёжность работы при использовании PCI клока.
Говорят, что этот клок не шибко стабилен и на некоторых материнках может заметно отличаться
от 33 МГц. Кто-нибудь в серийных изделиях использовал его для UART-ов ?

А двух клоковых доменов боюсь как огня, так как никогда не сталкивался с такой ситуацией.
Но если надо - освоим.


Тогда может лучше внешний генератор + ресинхронизатор внутри FPGA.
Go to the top of the page
 
+Quote Post
oval
сообщение Nov 22 2006, 13:09
Сообщение #66


Местный
***

Группа: Свой
Сообщений: 265
Регистрация: 15-03-05
Из: Москва
Пользователь №: 3 367



Цитата(Леха @ Nov 22 2006, 10:58) *
Товарищи, а если FPGA (ACEX) висит на PCI, то чем лучше тактировать
UART (использовать PCI клок или внешний завести) ?


Практика показывает, что в таком случае лучше использовать отдельный генератор.
Насчет нескольких тактовых доменов, ничего страшного там нет, просто нужно внимательно и правильно реализовывать переход между ними.
Go to the top of the page
 
+Quote Post
sazh
сообщение Nov 22 2006, 13:23
Сообщение #67


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



Проще Для Вас От PCI клок взять. А вообще все равно, сколько там генераторов на плате. А UART и подавно все равно. Обмен асинхронный (не путать с синхронным проектом).
Go to the top of the page
 
+Quote Post
Леха
сообщение Nov 22 2006, 13:45
Сообщение #68


Участник
*

Группа: Свой
Сообщений: 73
Регистрация: 18-06-04
Из: Минск
Пользователь №: 55



to sazh:

Не совсем понял. Например, я рассчитаю свой UART для работы с 33 МГц, а на какой-нить мамке частота
окажется больше или меньше или вовсе прыгать будет. Разве устройство на другом конце провода сможет
корректно принимать мои данные (а моё устройство его данные, соответственно) ?

to oval:

Отдельный клок имеется. Может знаете где почитать про работу с несколькими доменами (ссылки, книги...).
Go to the top of the page
 
+Quote Post
sazh
сообщение Nov 22 2006, 14:12
Сообщение #69


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



Не совсем понял. Например, я рассчитаю свой UART для работы с 33 МГц, а на какой-нить мамке частота
окажется больше или меньше или вовсе прыгать будет. Разве устройство на другом конце провода сможет
корректно принимать мои данные (а моё устройство его данные, соответственно) ?
///////////////////////////////////////////////////
Если верить Гуку, сравнивают скорость передачи. Рассогласование не более 1%.
Вот и считайте.
Go to the top of the page
 
+Quote Post
oval
сообщение Nov 22 2006, 14:52
Сообщение #70


Местный
***

Группа: Свой
Сообщений: 265
Регистрация: 15-03-05
Из: Москва
Пользователь №: 3 367



Цитата(Леха @ Nov 22 2006, 13:45) *
to oval:

Отдельный клок имеется. Может знаете где почитать про работу с несколькими доменами (ссылки, книги...).


Попробуйте здесь на форуме поискать. Были ссылки, посмотрите здесь, основная информация правда на английском.
Go to the top of the page
 
+Quote Post
Леха
сообщение Nov 22 2006, 15:13
Сообщение #71


Участник
*

Группа: Свой
Сообщений: 73
Регистрация: 18-06-04
Из: Минск
Пользователь №: 55



Цитата(sazh @ Nov 22 2006, 15:12) *
Если верить Гуку, сравнивают скорость передачи. Рассогласование не более 1%.
Вот и считайте.


Так ведь при серьёзном изменении PCI клока поплывёт скорость передачи.
Или я не прав ?
Go to the top of the page
 
+Quote Post
sazh
сообщение Nov 22 2006, 15:32
Сообщение #72


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



Вы правы. всегда найдутся любители журнала Upgrade. Любители разгона. При котором и шину PCI можно задрать до неприличия. У Вас АСЕХ. С градацией 2 у него выше 34 мГц врядли что выйдет.
Решайте сами. Или под Вашу частоту PCI, или под 33 мГц проект подстраивать или внешний генератор.
Go to the top of the page
 
+Quote Post
Oldring
сообщение Nov 22 2006, 16:23
Сообщение #73


Гуру
******

Группа: Свой
Сообщений: 3 041
Регистрация: 10-01-05
Из: Москва
Пользователь №: 1 874



Цитата(sazh @ Nov 22 2006, 15:32) *
Вы правы. всегда найдутся любители журнала Upgrade. Любители разгона. При котором и шину PCI можно задрать до неприличия. У Вас АСЕХ. С градацией 2 у него выше 34 мГц врядли что выйдет.
Решайте сами. Или под Вашу частоту PCI, или под 33 мГц проект подстраивать или внешний генератор.


PCI Specification 3.0

Цитата
In general, all PCI components must work with any clock frequency between nominal DC and 33 MHz.


То есть, использовать клок PCI для применений, в которых важен точный тайминг, по спецификации PCI недопустимо.

И, кстати,

Цитата
The clock frequency may be changed at any time during the operation of the system so long as the clock edges remain "clean" (monotonic) and the minimum cycle and high and low times are not violated.


--------------------
Пишите в личку.
Go to the top of the page
 
+Quote Post
DeadMoroz
сообщение Nov 23 2006, 02:40
Сообщение #74


Местный
***

Группа: Свой
Сообщений: 211
Регистрация: 3-02-05
Пользователь №: 2 391



я использовал PCI клок для UART в двух проектах, работает. Но нюансов с разгоном не учитывал
Go to the top of the page
 
+Quote Post
rv3dll(lex)
сообщение Oct 22 2007, 11:11
Сообщение #75


Полное ничтожество
*****

Группа: Banned
Сообщений: 1 991
Регистрация: 20-03-07
Из: Коломна
Пользователь №: 26 354



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

И всётаки из всего вышеперечисленного не могу понять как обеспечить приём в том случае , если длина стоп бита равна длине бита данных и идёт непрерывный поток? .
Go to the top of the page
 
+Quote Post
sazh
сообщение Oct 22 2007, 13:07
Сообщение #76


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



Цитата(rv3dll(lex) @ Oct 22 2007, 15:11) *
насчёт того, что не должно быть сбросов полностью согласен. Передатчик должен каждый раз полностью сбрасываться по записи в SBUF передаваемого байта, а приёмник как внешнетактируемое устройство должен иметь нециклящийся алгоритм.

И всётаки из всего вышеперечисленного не могу понять как обеспечить приём в том случае , если длина стоп бита равна длине бита данных и идёт непрерывный поток? .


Здесь уже давно рассмотрели все возможные реализации асинхроного обмена. О каком внешнетактируемом приемнике идет речь.
Go to the top of the page
 
+Quote Post
Kopart
сообщение Oct 22 2007, 13:28
Сообщение #77


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(rv3dll(lex) @ Oct 22 2007, 15:11) *
И всётаки из всего вышеперечисленного не могу понять как обеспечить приём в том случае , если длина стоп бита равна длине бита данных и идёт непрерывный поток? .

Стандартная ситуация. Нужно обработать в конце стопового перед новым стартовым.


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
rv3dll(lex)
сообщение Oct 23 2007, 10:17
Сообщение #78


Полное ничтожество
*****

Группа: Banned
Сообщений: 1 991
Регистрация: 20-03-07
Из: Коломна
Пользователь №: 26 354



Цитата(NiOS @ Oct 22 2007, 17:28) *
Стандартная ситуация. Нужно обработать в конце стопового перед новым стартовым.


ага найди тут информацию 01010101011101010101011101010101010101010101? - это уже после мажоритирования

тут есть старт стоп и 8 бит данных без чётностей
Go to the top of the page
 
+Quote Post
Kopart
сообщение Oct 23 2007, 10:38
Сообщение #79


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(rv3dll(lex) @ Oct 23 2007, 14:17) *
ага найди тут информацию 01010101011101010101011101010101010101010101? - это уже после мажоритирования

тут есть старт стоп и 8 бит данных без чётностей

На этом физическом уровне он примет правильно - всё что после первого распознаного нуля - посылка. Стандарт выполнен. А целостность данный должна проверятся уже на уровень выше. Есть модель OSI.


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
rv3dll(lex)
сообщение Oct 23 2007, 12:40
Сообщение #80


Полное ничтожество
*****

Группа: Banned
Сообщений: 1 991
Регистрация: 20-03-07
Из: Коломна
Пользователь №: 26 354



Цитата(NiOS @ Oct 23 2007, 14:38) *
На этом физическом уровне он примет правильно - всё что после первого распознаного нуля - посылка. Стандарт выполнен. А целостность данный должна проверятся уже на уровень выше. Есть модель OSI.


я не случайно говорил про удлиннённые стоповые биты
в данный момент я специально написал такую последовательность из которой нельзя выделить байты - на самом деле приписав к тому что несёт информацию пустые поля из 0101..

01010101 0_11101010_1 0_10111010_1 0_10101010_1 010101
биты чётности специально не показаны

так вот вопрос и стоит так, что модули уартов (я об этом могу судить по довольно длительному использованию 8051) такую последовательность разгребёт так как он формирует её с паузами - удлиннённым стопом про которые знает. Ради интереса коротили кратковременно телеметрию и имели только пропуски отдельных байтов.
Go to the top of the page
 
+Quote Post
Kopart
сообщение Oct 23 2007, 12:51
Сообщение #81


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(rv3dll(lex) @ Oct 23 2007, 16:40) *
так вот вопрос и стоит так, что модули уартов (я об этом могу судить по довольно длительному использованию 8051) такую последовательность разгребёт так как он формирует её с паузами - удлиннённым стопом про которые знает. Ради интереса коротили кратковременно телеметрию и имели только пропуски отдельных байтов.

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


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
sazh
сообщение Oct 23 2007, 14:04
Сообщение #82


Гуру
******

Группа: Свой
Сообщений: 2 435
Регистрация: 6-10-04
Из: Петербург
Пользователь №: 804



Цитата(rv3dll(lex) @ Oct 23 2007, 16:40) *
я не случайно говорил про удлиннённые стоповые биты
в данный момент я специально написал такую последовательность из которой нельзя выделить байты - на самом деле приписав к тому что несёт информацию пустые поля из 0101..

01010101 0_11101010_1 0_10111010_1 0_10101010_1 010101
биты чётности специально не показаны

так вот вопрос и стоит так, что модули уартов (я об этом могу судить по довольно длительному использованию 8051) такую последовательность разгребёт так как он формирует её с паузами - удлиннённым стопом про которые знает. Ради интереса коротили кратковременно телеметрию и имели только пропуски отдельных байтов.


А почему не удлиненный старт? А если анализировать удлиненный стоп, значит осознано игнорировать первый байт данных. И почему пустые поля 0101 а не 1111.
Если речь идет о UART, то можно дополнить обмен управляющими сигналами для "рукопожатия".
Если используется тольколиния данных, то в линию данных как минимум должны подавться в данном случает 10 единичных битов перед массивом данных для установки приемника в начальное состояние
(ожидание перепада из 1 в 0).
Go to the top of the page
 
+Quote Post
Kopart
сообщение Oct 23 2007, 14:35
Сообщение #83


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(sazh @ Oct 23 2007, 18:04) *
А если анализировать удлиненный стоп, значит осознано игнорировать первый байт данных.
К слову, не обязательно - можно и не игнорировать, если принимать решение после приема удлиненного стопа (если байт целый) yeah.gif


Если подытожить, то в конце все равно будет вывод, который в общем формулирается так:
У любого стандарта/протокола есть своя область применения.

А по умному: Решение задачи оптимизации верно при заданных условиях beer.gif


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post
rv3dll(lex)
сообщение Oct 24 2007, 06:28
Сообщение #84


Полное ничтожество
*****

Группа: Banned
Сообщений: 1 991
Регистрация: 20-03-07
Из: Коломна
Пользователь №: 26 354



Цитата(NiOS @ Oct 23 2007, 18:35) *
К слову, не обязательно - можно и не игнорировать, если принимать решение после приема удлиненного стопа (если байт целый) yeah.gif
Если подытожить, то в конце все равно будет вывод, который в общем формулирается так:
У любого стандарта/протокола есть своя область применения.

А по умному: Решение задачи оптимизации верно при заданных условиях beer.gif


вот я и пришёл к такому выводу, что сделал свой протокол где на байты не делится и подрят передаётся 128 бит
Go to the top of the page
 
+Quote Post
mse
сообщение Oct 24 2007, 07:38
Сообщение #85


Знающий
****

Группа: Свой
Сообщений: 709
Регистрация: 3-05-05
Пользователь №: 4 693



Цитата(rv3dll(lex) @ Oct 23 2007, 14:17) *
ага найди тут информацию...

Это ерунда. Часто и густо сваливал с одного УАРТа в другой потоки с одним стопом. Всё прекрасно разгребалось.
По одной простой причине: принимался первый байт и поток самосинхронизировался. Два стоп-бита, в случае чего, не помогут никак, бо это просто 2 единицы в потоке. И при приёме могут быть сплошные ошибки фрейма, а синхронизироваться не получится. Бо первый-же спад будет опознан как старт и приёмник честно зацепится за середину передаваемого байта. Т.е. в случае рассинхронизации, восстановление - процесс вероятностный. Спасёт только зазор между пакетами на величину, большую байтовой посылки.
Go to the top of the page
 
+Quote Post
rv3dll(lex)
сообщение Oct 24 2007, 11:09
Сообщение #86


Полное ничтожество
*****

Группа: Banned
Сообщений: 1 991
Регистрация: 20-03-07
Из: Коломна
Пользователь №: 26 354



Цитата(mse @ Oct 24 2007, 11:38) *
Это ерунда. Часто и густо сваливал с одного УАРТа в другой потоки с одним стопом. Всё прекрасно разгребалось.
По одной простой причине: принимался первый байт и поток самосинхронизировался. Два стоп-бита, в случае чего, не помогут никак, бо это просто 2 единицы в потоке. И при приёме могут быть сплошные ошибки фрейма, а синхронизироваться не получится. Бо первый-же спад будет опознан как старт и приёмник честно зацепится за середину передаваемого байта. Т.е. в случае рассинхронизации, восстановление - процесс вероятностный. Спасёт только зазор между пакетами на величину, большую байтовой посылки.


2 не спасут а полтора могут - если при передаче не наискажать скважность конечно - то можно найти этот удлинненный стоп
Go to the top of the page
 
+Quote Post
mse
сообщение Oct 24 2007, 11:10
Сообщение #87


Знающий
****

Группа: Свой
Сообщений: 709
Регистрация: 3-05-05
Пользователь №: 4 693



Цитата(rv3dll(lex) @ Oct 24 2007, 14:56) *
2 не спасут а полтора могут - если при передаче не наискажать скважность конечно - то можно найти этот удлинненный стоп

маловероятно. Старт будет от любого перепада, только принимать будет не только с ФЕ по "0" в стопе, но и "честную" ересь по пресловутым "3 мажоритарным выборкам".
Закладываться на такое, что "само рассосётся когда-нить" - себе дороже.
Go to the top of the page
 
+Quote Post
Stas
сообщение Feb 16 2008, 06:44
Сообщение #88


Местный
***

Группа: Свой
Сообщений: 464
Регистрация: 1-10-04
Из: Челябинск
Пользователь №: 751



To NIOS:
1. Спору нет, вроде схема рабочая но для дома и оффиса . Для температур (и резких перепадов температур) -60...+120 когда частота генераторов приемника и передатчика начинает гулять, более надежна классическая реализация, с определением середины битового интервала. А это значит лучше сразу делать надежно, чем потом в законченном устройстве при эксплуатации появятся непонятные редкие сбои...

2. Есче один классический вопрос о надежности. Триггера имеют так называемые времена Tsetup / Thold (помоему так называют), те минимально возможное время м/у установкой данных и прохождением тактового и м/у прохождением тактового и временем удержания данных при котором гарантируется его переключение в одно из определенных рабочих состояний. Если времена не выдерживаются, то возможно сваливание выхода триггера в неопределенное состояние (между 0 и 1). Теоретически триггер может долго находится в этом состоянии. Это то, что называют метастабильностью. Для снижения MTBF используют последовательно 2 триггера, на которых прощелкивают все входные сигналы. Если не изменяет память, то у TI в логических сериях есть подобные законченные устройства (те 2 последовательно соединенных триггера).Известный мне специалист высокого уровня, после расчета MTBF ставит 3 последовательно соединенных триггера на каждый вход от различных тактовых доменов. Это я к тому, что ваш МЖ фильтр работает напрямую с сигналом rxd...
Go to the top of the page
 
+Quote Post
Kopart
сообщение Feb 16 2008, 19:39
Сообщение #89


Знающий
****

Группа: Свой
Сообщений: 601
Регистрация: 1-03-05
Из: Spb
Пользователь №: 2 972



Цитата(Stas @ Feb 16 2008, 09:44) *
To NIOS:
1. А это значит лучше сразу делать надежно, чем потом в законченном устройстве при эксплуатации появятся непонятные редкие сбои...

2. Это я к тому, что ваш МЖ фильтр работает напрямую с сигналом rxd...

1.Для фиксированного количества битов можно заранее вычислить критический набег фазы генератора.
И его уже сравнить с температурным уходом в генераторе. Те в хорошей моделе генератора это все можно просчитать и учесть.

2. Я уже упоминал, что там есть два можаритарных фильтра работающих на разный частотах.
На входе сигнала rxd сразу стоит можаритарный фильтр на тактовой частоте проекта. Он и представляет собой те три последовательных триггера о которых вы упоминали + можаритарность (она фильтрует короткие пички не больше 2-ух периодов тактовой частоты). Можно сказать улучшенная версия с "цифровым фильтром".


--------------------
Насколько проще была бы жизнь, если бы она была в исходниках
Go to the top of the page
 
+Quote Post

6 страниц V   1 2 3 > » 
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 12th August 2025 - 12:26
Рейтинг@Mail.ru


Страница сгенерированна за 0.0261 секунд с 7
ELECTRONIX ©2004-2016