Полная версия этой страницы:
RS-232 + FPGA
Kopart
Jul 13 2006, 10:02
Цитата(sazh @ Jul 13 2006, 13:46)
Сам текст понятен. А вот идея всегда будет вызывать споры. Да и кто, когда будет reset нажимать.
reset должен быть, потомучто нету такого блока (для не SRAM ПЛИС проект)
Я для этого и опубликовал, предполагая, что со стороны Вы (в полной мере) сможет обозначить узкие моменты самого алгоритма тк я прикинул много сложных вариантов и всегда находил из них выход в моем алгоритме.
Мне он кажется проще - избавились от некоторых критичных элементов (хотя бы точность определения старта)
Кста на AHDL я (как и Вы) тоже прием кадра разворачивл временой диаграмой по счетчикам - мне тоже нравится так.
Но на Verilog'e решил попробовать по-другому - идейку подкинули про МЖФ -> и получилось
Reset не обязателен. Система сама должна переходить в начальное состояние по прошествии в нашем случае 11 тактов значения 1 в линии. Ваша идея не отличается простотой. Она выскальзывает как уж при попытке анализа. Да и невозможно при спорности самой идеи проверить досканально все частные возможные случаи. Например промоделируйте состояние 20 тактов 1, четверть такта 0, 20 тактов 1.
Да и раасогласование в скорости приемника и передатчика может быть как сплюсом, так и с минусом
javalenok
Jul 13 2006, 12:32
Теперь понял. Отслеживалка числа принятых битов совмещёна в сдвиговом регистре с данными. Прежде не доходило, как такое возможно, хотя протогол rs232 основан на этой идее. В таком случае отдельный счётчик бит действительно не нужен.
Но. Попробуте как я грузить битики данных с rs232 прямо в регистр контроллера (контроллер -- набор регистров команд с логикой для управления FPGA системой, команды принимаются по с компьютера по rs232). Придётся выход каждого регистра инициализировать единицами и снабжать выходной связью на rs232 приёмник, ведь стартовый бит будет путешествовать каждый раз по новому регистру. Куча регистров -- много нелокальных связей. Компактный счётчик возле rs232-автомата выйдет дешевле. К тому же совершенно не обязательно, что все загружаемые таким непосредственным образом регистры будут 8-битные.
Да и сам сброс в единицы как реализуется? 9 мультиплксоров подле каждой ячейки данных выбирают между 1 и shift_in. Может 3-битный счётчик принятых битов всё же экономнее?
Цитата
идейку подкинули про МЖФ -> и получилось
А они не объяснили -- на фига МЖФ, если без него работает идеально надёжно?
Kopart
Jul 13 2006, 14:48
Цитата(sazh @ Jul 13 2006, 14:13)
Reset не обязателен.
Этот ресет нужен обязательно при включении питания ПЛИС, а не для проекта. (я же говорю это НЕ SRAM-ПЛИС, а флеш)
Подается от простого монитора питания, когда установилось.
кста про четверть такта "0" - он и не поймет что был ноль - так и будет единица. А вот если >=2/3 такта "0", тогда есть вероятность что схватит "левый старт".
Но ваш метод тоже схватит "левый ноль" >=1/2 такта - он же проверит снова в середине -> и будет принимать ...
Этот ресет нужен обязательно при включении питания ПЛИС, а не для проекта. (я же говорю это НЕ SRAM-ПЛИС, а флеш)
Подается от простого монитора питания, когда установилось./////
А вот это уже интересно. Причем тут включение плис, и тем более его структура. Это работает на любой структуре Альтеры, у Xilinx работал только на FPGA 3000 тысячнике без всяких там прммитивов установки сетапов.
Если речь об Эктел, снимаю шляпу. Такой хоккей нам не нужен.
Kopart
Jul 18 2006, 09:08
Цитата(sazh @ Jul 13 2006, 20:49)
Этот ресет нужен обязательно при включении питания ПЛИС, а не для проекта. (я же говорю это НЕ SRAM-ПЛИС, а флеш)
Подается от простого монитора питания, когда установилось./////
А вот это уже интересно. Причем тут включение плис, и тем более его структура. Это работает на любой структуре Альтеры, у Xilinx работал только на FPGA 3000 тысячнике без всяких там прммитивов установки сетапов.
Если речь об Эктел, снимаю шляпу. Такой хоккей нам не нужен.
Что-то вы не сразу догадались про определение не SRAM-ПЛИС
Не сталкивались видать... Там просто нет цепей сброса по причине того, что универсальная ячейка может быть как тригером так и логической функцией.
Что-то вы не сразу догадались про определение не SRAM-ПЛИС
Не сталкивались видать... Там просто нет цепей сброса по причине того, что универсальная ячейка может быть как тригером так и логической функцией./////
Я не стал догадываться. Еще раз повторю. Нет необходимости в цепях сброса. Не имеет значения в каком состоянии все триггеры по включению. Дались Вам эти нули. Система сама должна переходить в начальное состояние при наличии в линии 1. И при этом подстраивать свои внутренние часы по каждому стопу. Иначе грош цена такой схеме.
Kopart
Jul 19 2006, 06:52
Цитата(sazh @ Jul 18 2006, 22:57)
Что-то вы не сразу догадались про определение не SRAM-ПЛИС
Не сталкивались видать... Там просто нет цепей сброса по причине того, что универсальная ячейка может быть как тригером так и логической функцией./////
Я не стал догадываться. Еще раз повторю. Нет необходимости в цепях сброса. Не имеет значения в каком состоянии все триггеры по включению. Дались Вам эти нули. Система сама должна переходить в начальное состояние при наличии в линии 1. И при этом подстраивать свои внутренние часы по каждому стопу. Иначе грош цена такой схеме.
Не думаю, что хорошая идея завязыватся на сигнал 1 на линии. От него ничего толового не сделать.
Я же написал, что Вы правильно предположили производителя ПЛИС - поэтому сигнал сброса нужен по-определению(поверьте!).
А по подстраивание по стопу я не понял - или, если это Вы совместно с начальным состоянием при наличие 1 на линии - то я про это уже написал.
sanek78
Sep 26 2006, 09:15
Цитата(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) )
Спасибо большое за идею(или даже за решение). Сделал как Вы советуете - работает как часы.
Упс. Тут уже даже код появился. Я правда все равно в VHDL писал
Kopart
Sep 27 2006, 18:01
Цитата(sanek78 @ Sep 26 2006, 13:15)
Спасибо большое за идею(или даже за решение). Сделал как Вы советуете - работает как часы.
О! Если это Вы будете и дальше эксплуатировать в устройстве, то можно будет получить реальную проверку работоспособности такой реализации...
Напишите здесь о результатах?!
sanek78
Sep 28 2006, 12:14
Я диплом пишу, поэтому результат может быть только на уровне прототипа(пока). Но соединить DSP с FPGA(Starter Kit) получилось, данные передаются по SCI на 115к. Соединил двумя проводами на 15см. Интересно правда посмотреть что получится, когда рядом преобразователь частоты начнет долбить. Где-то через месяц напишу, как алгоритм с помехами справляется.
Товарищи, а если FPGA (ACEX) висит на PCI, то чем лучше тактировать
UART (использовать PCI клок или внешний завести) ?
Цитата(Леха @ Nov 22 2006, 10:58)
Товарищи, а если FPGA (ACEX) висит на PCI, то чем лучше тактировать
UART (использовать PCI клок или внешний завести) ?
А посчитать влом? А со вторым тактовым - Вы готовы к работе с двумя клоковыми доменами?
Посчитать не влом. Вопрос про корректность и надёжность работы при использовании PCI клока.
Говорят, что этот клок не шибко стабилен и на некоторых материнках может заметно отличаться
от 33 МГц. Кто-нибудь в серийных изделиях использовал его для UART-ов ?
А двух клоковых доменов боюсь как огня, так как никогда не сталкивался с такой ситуацией.
Но если надо - освоим.
Цитата(Леха @ Nov 22 2006, 12:27)
Посчитать не влом. Вопрос про корректность и надёжность работы при использовании PCI клока.
Говорят, что этот клок не шибко стабилен и на некоторых материнках может заметно отличаться
от 33 МГц. Кто-нибудь в серийных изделиях использовал его для UART-ов ?
А двух клоковых доменов боюсь как огня, так как никогда не сталкивался с такой ситуацией.
Но если надо - освоим.
Тогда может лучше внешний генератор + ресинхронизатор внутри FPGA.
Цитата(Леха @ Nov 22 2006, 10:58)
Товарищи, а если FPGA (ACEX) висит на PCI, то чем лучше тактировать
UART (использовать PCI клок или внешний завести) ?
Практика показывает, что в таком случае лучше использовать отдельный генератор.
Насчет нескольких тактовых доменов, ничего страшного там нет, просто нужно внимательно и правильно реализовывать переход между ними.
Проще Для Вас От PCI клок взять. А вообще все равно, сколько там генераторов на плате. А UART и подавно все равно. Обмен асинхронный (не путать с синхронным проектом).
to sazh:
Не совсем понял. Например, я рассчитаю свой UART для работы с 33 МГц, а на какой-нить мамке частота
окажется больше или меньше или вовсе прыгать будет. Разве устройство на другом конце провода сможет
корректно принимать мои данные (а моё устройство его данные, соответственно) ?
to oval:
Отдельный клок имеется. Может знаете где почитать про работу с несколькими доменами (ссылки, книги...).
Не совсем понял. Например, я рассчитаю свой UART для работы с 33 МГц, а на какой-нить мамке частота
окажется больше или меньше или вовсе прыгать будет. Разве устройство на другом конце провода сможет
корректно принимать мои данные (а моё устройство его данные, соответственно) ?
///////////////////////////////////////////////////
Если верить Гуку, сравнивают скорость передачи. Рассогласование не более 1%.
Вот и считайте.
Цитата(Леха @ Nov 22 2006, 13:45)
to oval:
Отдельный клок имеется. Может знаете где почитать про работу с несколькими доменами (ссылки, книги...).
Попробуйте здесь на форуме поискать. Были ссылки, посмотрите
здесь, основная информация правда на английском.
Цитата(sazh @ Nov 22 2006, 15:12)
Если верить Гуку, сравнивают скорость передачи. Рассогласование не более 1%.
Вот и считайте.
Так ведь при серьёзном изменении PCI клока поплывёт скорость передачи.
Или я не прав ?
Вы правы. всегда найдутся любители журнала Upgrade. Любители разгона. При котором и шину PCI можно задрать до неприличия. У Вас АСЕХ. С градацией 2 у него выше 34 мГц врядли что выйдет.
Решайте сами. Или под Вашу частоту PCI, или под 33 мГц проект подстраивать или внешний генератор.
Oldring
Nov 22 2006, 16:23
Цитата(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.
DeadMoroz
Nov 23 2006, 02:40
я использовал PCI клок для UART в двух проектах, работает. Но нюансов с разгоном не учитывал
rv3dll(lex)
Oct 22 2007, 11:11
насчёт того, что не должно быть сбросов полностью согласен. Передатчик должен каждый раз полностью сбрасываться по записи в SBUF передаваемого байта, а приёмник как внешнетактируемое устройство должен иметь нециклящийся алгоритм.
И всётаки из всего вышеперечисленного не могу понять как обеспечить приём в том случае , если длина стоп бита равна длине бита данных и идёт непрерывный поток? .
Цитата(rv3dll(lex) @ Oct 22 2007, 15:11)
насчёт того, что не должно быть сбросов полностью согласен. Передатчик должен каждый раз полностью сбрасываться по записи в SBUF передаваемого байта, а приёмник как внешнетактируемое устройство должен иметь нециклящийся алгоритм.
И всётаки из всего вышеперечисленного не могу понять как обеспечить приём в том случае , если длина стоп бита равна длине бита данных и идёт непрерывный поток? .
Здесь уже давно рассмотрели все возможные реализации асинхроного обмена. О каком внешнетактируемом приемнике идет речь.
Kopart
Oct 22 2007, 13:28
Цитата(rv3dll(lex) @ Oct 22 2007, 15:11)
И всётаки из всего вышеперечисленного не могу понять как обеспечить приём в том случае , если длина стоп бита равна длине бита данных и идёт непрерывный поток? .
Стандартная ситуация. Нужно обработать в конце стопового перед новым стартовым.
rv3dll(lex)
Oct 23 2007, 10:17
Цитата(NiOS @ Oct 22 2007, 17:28)
Стандартная ситуация. Нужно обработать в конце стопового перед новым стартовым.
ага найди тут информацию 01010101011101010101011101010101010101010101? - это уже после мажоритирования
тут есть старт стоп и 8 бит данных без чётностей
Kopart
Oct 23 2007, 10:38
Цитата(rv3dll(lex) @ Oct 23 2007, 14:17)
ага найди тут информацию 01010101011101010101011101010101010101010101? - это уже после мажоритирования
тут есть старт стоп и 8 бит данных без чётностей
На этом физическом уровне он примет правильно - всё что после первого распознаного нуля - посылка. Стандарт выполнен. А целостность данный должна проверятся уже на уровень выше. Есть модель OSI.
rv3dll(lex)
Oct 23 2007, 12:40
Цитата(NiOS @ Oct 23 2007, 14:38)
На этом физическом уровне он примет правильно - всё что после первого распознаного нуля - посылка. Стандарт выполнен. А целостность данный должна проверятся уже на уровень выше. Есть модель OSI.
я не случайно говорил про удлиннённые стоповые биты
в данный момент я специально написал такую последовательность из которой нельзя выделить байты - на самом деле приписав к тому что несёт информацию пустые поля из 0101..
01010101 0_11101010_1 0_10111010_1 0_10101010_1 010101
биты чётности специально не показаны
так вот вопрос и стоит так, что модули уартов (я об этом могу судить по довольно длительному использованию 8051) такую последовательность разгребёт так как он формирует её с паузами - удлиннённым стопом про которые знает. Ради интереса коротили кратковременно телеметрию и имели только пропуски отдельных байтов.
Kopart
Oct 23 2007, 12:51
Цитата(rv3dll(lex) @ Oct 23 2007, 16:40)
так вот вопрос и стоит так, что модули уартов (я об этом могу судить по довольно длительному использованию 8051) такую последовательность разгребёт так как он формирует её с паузами - удлиннённым стопом про которые знает. Ради интереса коротили кратковременно телеметрию и имели только пропуски отдельных байтов.
Подайте на Ваш 8051 приведенный ранее поток данных - он их тоже не разберет (если в потоке нет специальных "меток" вроде удлиненного стопа). Я же говорю, что это задача уровня выше - вставлять в поток специальные синхронизующие символы (удлинненый стоп это частный случай синхронизации)
Цитата(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).
Kopart
Oct 23 2007, 14:35
Цитата(sazh @ Oct 23 2007, 18:04)
А если анализировать удлиненный стоп, значит осознано игнорировать первый байт данных.
К слову, не обязательно - можно и не игнорировать, если принимать решение после приема удлиненного стопа (если байт целый)
Если подытожить, то в конце все равно будет вывод, который в общем формулирается так:
У любого стандарта/протокола есть своя область применения.
А по умному: Решение задачи оптимизации верно при заданных условиях
rv3dll(lex)
Oct 24 2007, 06:28
Цитата(NiOS @ Oct 23 2007, 18:35)
К слову, не обязательно - можно и не игнорировать, если принимать решение после приема удлиненного стопа (если байт целый)
Если подытожить, то в конце все равно будет вывод, который в общем формулирается так:
У любого стандарта/протокола есть своя область применения.
А по умному: Решение задачи оптимизации верно при заданных условиях
вот я и пришёл к такому выводу, что сделал свой протокол где на байты не делится и подрят передаётся 128 бит
Цитата(rv3dll(lex) @ Oct 23 2007, 14:17)
ага найди тут информацию...
Это ерунда. Часто и густо сваливал с одного УАРТа в другой потоки с одним стопом. Всё прекрасно разгребалось.
По одной простой причине: принимался первый байт и поток самосинхронизировался. Два стоп-бита, в случае чего, не помогут никак, бо это просто 2 единицы в потоке. И при приёме могут быть сплошные ошибки фрейма, а синхронизироваться не получится. Бо первый-же спад будет опознан как старт и приёмник честно зацепится за середину передаваемого байта. Т.е. в случае рассинхронизации, восстановление - процесс вероятностный. Спасёт только зазор между пакетами на величину, большую байтовой посылки.
rv3dll(lex)
Oct 24 2007, 11:09
Цитата(mse @ Oct 24 2007, 11:38)
Это ерунда. Часто и густо сваливал с одного УАРТа в другой потоки с одним стопом. Всё прекрасно разгребалось.
По одной простой причине: принимался первый байт и поток самосинхронизировался. Два стоп-бита, в случае чего, не помогут никак, бо это просто 2 единицы в потоке. И при приёме могут быть сплошные ошибки фрейма, а синхронизироваться не получится. Бо первый-же спад будет опознан как старт и приёмник честно зацепится за середину передаваемого байта. Т.е. в случае рассинхронизации, восстановление - процесс вероятностный. Спасёт только зазор между пакетами на величину, большую байтовой посылки.
2 не спасут а полтора могут - если при передаче не наискажать скважность конечно - то можно найти этот удлинненный стоп
Цитата(rv3dll(lex) @ Oct 24 2007, 14:56)
2 не спасут а полтора могут - если при передаче не наискажать скважность конечно - то можно найти этот удлинненный стоп
маловероятно. Старт будет от любого перепада, только принимать будет не только с ФЕ по "0" в стопе, но и "честную" ересь по пресловутым "3 мажоритарным выборкам".
Закладываться на такое, что "само рассосётся когда-нить" - себе дороже.
To NIOS:
1. Спору нет, вроде схема рабочая но для дома и оффиса . Для температур (и резких перепадов температур) -60...+120 когда частота генераторов приемника и передатчика начинает гулять, более надежна классическая реализация, с определением середины битового интервала. А это значит лучше сразу делать надежно, чем потом в законченном устройстве при эксплуатации появятся непонятные редкие сбои...
2. Есче один классический вопрос о надежности. Триггера имеют так называемые времена Tsetup / Thold (помоему так называют), те минимально возможное время м/у установкой данных и прохождением тактового и м/у прохождением тактового и временем удержания данных при котором гарантируется его переключение в одно из определенных рабочих состояний. Если времена не выдерживаются, то возможно сваливание выхода триггера в неопределенное состояние (между 0 и 1). Теоретически триггер может долго находится в этом состоянии. Это то, что называют метастабильностью. Для снижения MTBF используют последовательно 2 триггера, на которых прощелкивают все входные сигналы. Если не изменяет память, то у TI в логических сериях есть подобные законченные устройства (те 2 последовательно соединенных триггера).Известный мне специалист высокого уровня, после расчета MTBF ставит 3 последовательно соединенных триггера на каждый вход от различных тактовых доменов. Это я к тому, что ваш МЖ фильтр работает напрямую с сигналом rxd...
Kopart
Feb 16 2008, 19:39
Цитата(Stas @ Feb 16 2008, 09:44)
To NIOS:
1. А это значит лучше сразу делать надежно, чем потом в законченном устройстве при эксплуатации появятся непонятные редкие сбои...
2. Это я к тому, что ваш МЖ фильтр работает напрямую с сигналом rxd...
1.Для фиксированного количества битов можно заранее вычислить критический набег фазы генератора.
И его уже сравнить с температурным уходом в генераторе. Те в хорошей моделе генератора это все можно просчитать и учесть.
2. Я уже упоминал, что там есть два можаритарных фильтра работающих на разный частотах.
На входе сигнала rxd сразу стоит можаритарный фильтр на тактовой частоте проекта. Он и представляет собой те три последовательных триггера о которых вы упоминали + можаритарность (она фильтрует короткие пички не больше 2-ух периодов тактовой частоты). Можно сказать улучшенная версия с "цифровым фильтром".
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.