[sazh 3]

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

[ChinasFanat 0]

:bb-offtopic:

круто! :a14:

ну вы блин даете!

этож можно человека до самоубийства довести таким количеством советов! )))

по делу ничего сказать не могу - уже все сказали, разжевали и проглотили.

но с шутками надо осторожнее )))

разве что фильтр по-моему не обязателен вовсе.

[sazh 3]

To Wild. Вы все правильно говорили. А я не шутил. Просто когда по теме rs232 столько копий сломано, а воз и ныне там, уже нет мочи говорить прописные истины. Они просты. Не трогай технику, и она тебя не тронет. Есть старт, есть стоп, значит так надо. Мне вообще непонятно для чего в приемнике эта мажоритарность. Это же не МК. По большому счету и подход при работе с собственным клоком, позволяющий нащупать середину стартового бита, отрицает необходимость мажоритарности. Если Вы досчитали до середины стартового бита, попали в энегетический центр сигнала, зачем анализировать, что слева или справа. Разве это улучшит надежность приемника. Да только ухудшит, если рассогласования частот приемника и передатчика значимы. У меня подход прост.

При перепаде из 1 в 0 анализирую наличие этого нуля в интервале 1/2 длительности бита (меньше 1/2 это не старт, снова ждем перепад), если 0 значит это середина старта, открываю временной интервал работы и нарезаю фронтом по центру длительностью в период бита. На месте где должен быть стоп закрываю интервал и анализирую на наличие 1. Если 0 ошибка кадрирования и дальше принимаем решение, что игнорируем слово или массив.

[Kopart 0]

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

 

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

 

Мне вообще непонятно для чего в приемнике эта мажоритарность. Это же не МК. По большому счету и подход при работе с собственным клоком, позволяющий нащупать середину стартового бита, отрицает необходимость мажоритарности. Если Вы досчитали до середины стартового бита, попали в энегетический центр сигнала, зачем анализировать, что слева или справа. Разве это улучшит надежность приемника. Да только ухудшит, если рассогласования частот приемника и передатчика значимы. У меня подход прост.

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

- к минимум задача фильтровать пички.

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

 

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

А определение начала и конца "посылки" в моем методы тоже присутствует - в КА, и не требует такой точности.

[javalenok 0]

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

 

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

 

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

 

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

[Kopart 0]

Вы хоть обозначайте кому пишите! А лучше ставьте цитаты, того на что отвечаете.

Про комментирую то, что покажется обращено ко мне.

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

Тут вопрос определения "середины битового интервала" (для этого "точно" надо знать начала стартового бита)

А с МЖФ не надо синхронизоватся - сам поймет "опосля" - вот уже стартовый "ноль" - надо бы начать вдвигать. Плюс фильтруются пологие фронты, спады.

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

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

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

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

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

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

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

 

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

[javalenok 0]

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

Тут вопрос определения "середины битового интервала" (для этого "точно" надо знать начала стартового бита)

А с МЖФ не надо синхронизоватся - сам поймет "опосля" - вот уже стартовый "ноль" - надо бы начать вдвигать. Плюс фильтруются пологие фронты, спады.

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

 

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

 

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

 

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

 

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

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

 

1/16 * 100%

 

 

 

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

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

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

 

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

 

Тут тоже какое-то досадное замешательство. Полагаю от того, что вопрос-ответ приводится в стековой последовательности и надо читать:

[1]

- Никто не сказал про метастабильность, ... автомат в полный беспорядок.

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

 

[2]

- идея использовать сдвиг вместо подсчёта бит заслуживает рассмотрения. декодер на N адресов в FPGA занимает вдвое больше ресурсов, чем цепочка из N FF-ов.

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

 

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

 

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

Изменено 10 июля, 2006 пользователем javalenok

[Kopart 0]

Да, ну и откуда ты узнаешь, что подступил новый байт?

Есть "фильтр" на входе сигнала RX в ПЛИС

У меня это сделано с помощью МЖФ (фильтрует лучше), но можно и просто стробировать основной частотой проекта.

На выходе(когда автомат в idle) появился "0" - переходим в прием (STATE_RECEIVE)

Выбирать надо в серёдке, для этого надо сделать отступ от переднего фронта старт-бита. Далее, как ты определишь, что пора сдвигать, если не по собственным часам?

ЕЩЕ раз - я не выбираю в середке!!!

У меня ВСЕГДА есть утроенная частота бодовой скорости (Я ее НЕ синхронизую со стартом!!!)

Далее (когда в состоянии STATE_RECEIVE) - считаю эту частоту и по каждому третьему фронту вдигаю в регистр выход МЖФ (его код уже приводил(там есть enable))

 

Для кого-то в коде понятней :)

if(STATE_RECEIVE & counter==2'h3) 
           rx_reg[9:0] <= #T {out(MZHF),rx_reg[9:1]};

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

ЕЩЕ раз повторяю - я знаю сколько битов в "бодовом байте" - те выбрал глубину сдвигового регистра.

!!!!!!!!!!!!!!!В "idle" я его устанавливаю всеми "1" и вдвигаю ВСЕ биты и СТАРТ!!!!!!!!!!!!!!!!!!!!!!!!

Стартовый ВСЕГДА "0" - на пример вдвигаю с "конца" - добрался "0" до "начала" регистра - значит стоповый уже вдвинулся.

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

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

 

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

 

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

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

Декодер на N адрессов можно реализовать и без счетчика :)

 

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

[javalenok 0]

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

 

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

 

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

 

 

 

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

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

 

 

 

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

 

 

ЕЩЕ раз повторяю - я знаю сколько битов в "бодовом байте" - те выбрал глубину сдвигового регистра.

!!!!!!!!!!!!!!!В "idle" я его устанавливаю всеми "1" и вдвигаю ВСЕ биты и СТАРТ!!!!!!!!!!!!!!!!!!!!!!!!

Стартовый ВСЕГДА "0" - на пример вдвигаю с "конца" - добрался "0" до "начала" регистра - значит стоповый уже вдвинулся.

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

 

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

 

 

 

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

Декодер на N адрессов можно реализовать и без счетчика :)

 

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

 

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

 

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

Изменено 11 июля, 2006 пользователем javalenok

[Kopart 0]

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

Вы знаете что такое простое "стробирование по входу" - так вот МЖФ на входе это просто лучше.

При таком сигнале на входе Вам ни какой фильтр не позволит принять сигнал стандарта RS-232.

Речь шла о статистически случайных одиночных пичках сигнала на паде ПЛИС, которые МЖФ сглаживает лучше, чем стробирование.

1-й и 3-й -- это как раз граничные обрызцы, они могут относится к другому биту. Вы же их цените на равне со средним. Может ну их, эти выборы -- баловство?

И вообще от посреднечества сдвигового регистра отказаться, грузить Rx прямо в rx_reg[0]? У меня именно так сделано -- без детских игр в голосование.

 

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

 

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

 

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

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

 

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

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

 

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

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

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

И вобщето сдвиговый регистр хранит то, что в него вдвинули.

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

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

[javalenok 0]

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

Вы знаете что такое простое "стробирование по входу" - так вот МЖФ на входе это просто лучше.

При таком сигнале на входе Вам ни какой фильтр не позволит принять сигнал стандарта RS-232.

Речь шла о статистически случайных одиночных пичках сигнала на паде ПЛИС, которые МЖФ сглаживает лучше, чем стробирование.

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

 

 

1-й и 3-й -- это как раз граничные обрызцы, они могут относится к другому биту. Вы же их цените на равне со средним. Может ну их, эти выборы -- баловство?

И вообще от посреднечества сдвигового регистра отказаться, грузить Rx прямо в rx_reg[0]? У меня именно так сделано -- без детских игр в голосование.

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

 

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

 

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

 

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

 

 

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

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

 

Я, конечно не знаток верилога, но

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

 

 

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

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

 

 

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

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

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

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

 

И вобщето сдвиговый регистр хранит то, что в него вдвинули.

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

Изменено 12 июля, 2006 пользователем javalenok

[Kopart 0]

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

А особено который имеет дело с ПЛИС!!

 

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

 

1. Да согласен - есть лишний такт на выходе МЖФ, впесто простого assign <wire>=...

Но он ничего не меняет в алгоритме. Он нужен тк FPGA - "любит" синхронный дизайн.

 

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

[sazh 3]

TO NIOS:

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

[javalenok 0]

1. Да согласен - есть лишний такт на выходе МЖФ, впесто простого assign <wire>=...

Но он ничего не меняет в алгоритме. Он нужен тк FPGA - "любит" синхронный дизайн.

 

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

 

 

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

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

 

 

САМИ биты я не считаю!

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

 

 

 

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

А особено который имеет дело с ПЛИС!!

 

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

 

TO NIOS:

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

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

[Kopart 0]

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

 

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

 

под "бодовым байтом" я понимаю информационный "байт" + служебные биты(старт, стопы, четность).

В вашем понимании это кадр - что тоже не коректно,

тк кадром называют отдельный сегмент на более высоком уровне в транспортной моделе OSI.

Хотя Кто-то нам подскажет точное название, приведенное в стандарте.

 

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