Добрый день !
Подскажите в чем может быть дело ?
ПЛИС MAX EPM 7160STC 100-6 используется в качестве делителя частоы, внутри счетчик на ЛПМ функции.
Тактовая частота 10 Мгц.
Входная частота 10 кГц.
Входной сигнал синус проходит через оптопару потом идет в виде меандра в ПЛИС
На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально.
Какие существуют ограничения на фронты входных сигналов ?
Как можно выйти из ситуации без использования триггера шмита?
Полная версия этой страницы: Фронты входного сигнала в EPM7160STC-6
Форум разработчиков электроники ELECTRONIX.ru > Программируемая логика ПЛИС (FPGA,CPLD, PLD) > Работаем с ПЛИС, области применения, выбор
Как мне кажется, выша проблема в том,что вы фронт 10 кГц сигнала ловите на 10 МГц. При этом,из-за того, что фронт 10 кГц развален, то некоторое количество тактов 10МГц попадает на фронт - из-за этого ложные срабатывания.Я прав?
Ставьте оптопару с цифровым выходом - дрожания не будет. Там ставится тр.Шм., которого Вы так не любите.
а подскажите тогда тип оптопары ?
сейчас стоит HCPL0630 ....это какая ? обычная ?
а триггер шмитта начальник ставить не хочет (запрещает).
сейчас стоит HCPL0630 ....это какая ? обычная ?
а триггер шмитта начальник ставить не хочет (запрещает).
посмотри HCPL2231 - выход тр. Шм, может быть подойдет даже по распиновке, хотя у
HCPL0630 выход тоже цифровой ( Dual Channel, High CMR, High Speed, TTL Compatible Optocouplers 8 Pin DIP and SOIC-8)
HCPL0630 выход тоже цифровой ( Dual Channel, High CMR, High Speed, TTL Compatible Optocouplers 8 Pin DIP and SOIC-8)
Поскольку там оптрон - транзистор с открытым коллектором, то можно сделать имитатор триггера Шмитта из свободного выхода 7160 и резистора.
можно еще попробовать сделать тригер шмита внутри ПЛИС. выход оптапары заводим на in1 затем ставим диод с in1 на in2 (допустим защелкуть надо передний фронт) в результате во время фронта ждем когда входы сравняются и генеририм выходной импульс, если не хватает одного диода ставим еще один.... дешево т сердито
нафига вам "внешний" триггер Шмидта?
Это же как "дребезг" в механическом контакте. И поступать с ним надо соответственно. Завести на селектор переднего фронта, с него передний фронт на RS-триггер, на вход установки, например. На вход сброса завести задний фронт, но не напрямую с селектора заднего фронта, а через цепь "мёртвого времени", которая бы блокировала прохождение сигнала сброса на время, большее, чем "дребезг". Это время, думаю, вам уже известно из экспериментов.
Это же как "дребезг" в механическом контакте. И поступать с ним надо соответственно. Завести на селектор переднего фронта, с него передний фронт на RS-триггер, на вход установки, например. На вход сброса завести задний фронт, но не напрямую с селектора заднего фронта, а через цепь "мёртвого времени", которая бы блокировала прохождение сигнала сброса на время, большее, чем "дребезг". Это время, думаю, вам уже известно из экспериментов.
Цитата(vikrus @ Mar 30 2006, 12:28) 
Добрый день !
Подскажите в чем может быть дело ?
ПЛИС MAX EPM 7160STC 100-6 используется в качестве делителя частоы, внутри счетчик на ЛПМ функции.
Тактовая частота 10 Мгц.
Входная частота 10 кГц.
Входной сигнал синус проходит через оптопару потом идет в виде меандра в ПЛИС
На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально.
Какие существуют ограничения на фронты входных сигналов ?
Как можно выйти из ситуации без использования триггера шмита?
Подскажите в чем может быть дело ?
ПЛИС MAX EPM 7160STC 100-6 используется в качестве делителя частоы, внутри счетчик на ЛПМ функции.
Тактовая частота 10 Мгц.
Входная частота 10 кГц.
Входной сигнал синус проходит через оптопару потом идет в виде меандра в ПЛИС
На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально.
Какие существуют ограничения на фронты входных сигналов ?
Как можно выйти из ситуации без использования триггера шмита?
Скажу Вам так - ответов много и все неправильные!
Делается все гораздо проще цифровым методом. Внутри ставите сдвиговый регистр на частоте 10 Мгц. Его глубина определяется длительностью импульсов помехи, которые могут быть на фронтах. Далее ставится RS-триггер. Если в сдвиговом регистре N нулей подряд, то это значит что сигнал идет на R
вход триггера, если N единиц подряд - то на S.
Можно сделать и "круче". Т.е. реверсивный счетчик и схему сравнения с порогом. Выше верхнего порога - 1, ниже нижнего - 0. При таком варианте из входных данных будут фильтроваться одиночные импульы помехи.
Итог: в программируемой логике надо все делать цифровое, синхронное и не "жалеть патронов".
Удачи!
Цитата(iosifk @ Apr 5 2006, 11:14)
Можно сделать и "круче". Т.е. реверсивный счетчик и схему сравнения с порогом. Выше верхнего порога - 1, ниже нижнего - 0. При таком варианте из входных данных будут фильтроваться одиночные импульы помехи.
В дополнение:
Пример реализации такого фильтра:
Код
//
// Схема фильтрации сигнала с линии, и выделения фронтов.
//
// Представляет собой реверсивный счетчик, с заданной разрядностью (параметр Width),
// который считает в сторону увеличения при единице на InData до достижения
// максимального значения, и блокируется.
// При нуле на InData считает в сторону уменьшения, с заданным шагом (DecrementStep),
// до достижения состояния 0, и блокируется.
//
// При максимальном значение, если выходные данные равны нулю, выдается единица
// на eDataFront (при единице на eClk), и происходит изменение выходных данных на единицу.
//
// В состоянии 0, если выходные данные равны единице, выдается единица
// на eDataFront (при единице на eClk), и происходит изменение выходных данных на ноль.
//
module DataFilter(
input Clk, /* Системная высокочастотная тактовая (например 10 МГц) */
input nInit, /* Асинхронный сброс */
input eClk, /* Разрешение тактирования по Clk (если устраивает работа на частоте Clk, то поставить в единицу) */
input InData, /* Входной сигнал */
output eDataFront, /* Признак изменения выходного сигнала по ближайшему фронту Clk, с eClk=1 */
output reg OutData /* Выходной сигнал, привязанный к фронту Clk, с eClk=1 */
);
parameter Width = 5;
parameter DecrementStep = 1;
wire [Width-1:0]CntMax = (1<<Width)-1;
reg [Width-1:0]Cnt; // Реверсивный счетчик.
assign eDataFront = ((Cnt < DecrementStep && OutData != 0) ||
(Cnt == CntMax && OutData == 0)) && eClk; // Импульсы фронтов входного сигнала
always @(negedge nInit or posedge Clk)
if(!nInit)
begin
OutData <= 1;
Cnt <= 0;
end
else
if(eClk)
begin
if(Cnt < CntMax && InData) // Условие для инкремента
Cnt <= Cnt + 1;
if(Cnt >= DecrementStep && !InData) // Условие для декремента
Cnt <= Cnt - DecrementStep;
if(eDataFront)
OutData <= (Cnt == CntMax? 1 : 0); // Изменение текущего значения
end
endmodule
// Схема фильтрации сигнала с линии, и выделения фронтов.
//
// Представляет собой реверсивный счетчик, с заданной разрядностью (параметр Width),
// который считает в сторону увеличения при единице на InData до достижения
// максимального значения, и блокируется.
// При нуле на InData считает в сторону уменьшения, с заданным шагом (DecrementStep),
// до достижения состояния 0, и блокируется.
//
// При максимальном значение, если выходные данные равны нулю, выдается единица
// на eDataFront (при единице на eClk), и происходит изменение выходных данных на единицу.
//
// В состоянии 0, если выходные данные равны единице, выдается единица
// на eDataFront (при единице на eClk), и происходит изменение выходных данных на ноль.
//
module DataFilter(
input Clk, /* Системная высокочастотная тактовая (например 10 МГц) */
input nInit, /* Асинхронный сброс */
input eClk, /* Разрешение тактирования по Clk (если устраивает работа на частоте Clk, то поставить в единицу) */
input InData, /* Входной сигнал */
output eDataFront, /* Признак изменения выходного сигнала по ближайшему фронту Clk, с eClk=1 */
output reg OutData /* Выходной сигнал, привязанный к фронту Clk, с eClk=1 */
);
parameter Width = 5;
parameter DecrementStep = 1;
wire [Width-1:0]CntMax = (1<<Width)-1;
reg [Width-1:0]Cnt; // Реверсивный счетчик.
assign eDataFront = ((Cnt < DecrementStep && OutData != 0) ||
(Cnt == CntMax && OutData == 0)) && eClk; // Импульсы фронтов входного сигнала
always @(negedge nInit or posedge Clk)
if(!nInit)
begin
OutData <= 1;
Cnt <= 0;
end
else
if(eClk)
begin
if(Cnt < CntMax && InData) // Условие для инкремента
Cnt <= Cnt + 1;
if(Cnt >= DecrementStep && !InData) // Условие для декремента
Cnt <= Cnt - DecrementStep;
if(eDataFront)
OutData <= (Cnt == CntMax? 1 : 0); // Изменение текущего значения
end
endmodule
Цитата(Shamil @ Apr 5 2006, 12:03)
Цитата(iosifk @ Apr 5 2006, 11:14)
Можно сделать и "круче". Т.е. реверсивный счетчик и схему сравнения с порогом. Выше верхнего порога - 1, ниже нижнего - 0. При таком варианте из входных данных будут фильтроваться одиночные импульы помехи.
В дополнение:
Пример реализации такого фильтра:
Код
// Схема фильтрации сигнала с линии, и выделения фронтов.
Спасибо, Верно! И если вывести дополнительные сигналы от состояний "выше-ниже", то сможете оценивать сигнал, попадает ли он как положено в норму, нет ли пропаданий сигнала и тд.
Удачи!
Цитата(iosifk @ Apr 5 2006, 12:14)
Скажу Вам так - ответов много и все неправильные!
Не надо делать столь категоричные оценки своих коллег, претендуя на роль... кого-то свыше... Лично я считаю, что мой ответ также является правильным, поскольку:Цитата(iosifk @ Apr 5 2006, 12:14)
Делается все гораздо проще цифровым методом.
поскольку также делается цифровым путём, и можно ещё поспорить, какой из методов лучше. Например, мой метод не имеет задержки включения и выключения, а срабатывает сразу по первому импульсу. Ещё можно подумать, где будет меньше ячеек занято...
Цитата(Krys @ Apr 6 2006, 06:44)
Цитата(iosifk @ Apr 5 2006, 12:14)
Скажу Вам так - ответов много и все неправильные!
Не надо делать столь категоричные оценки своих коллег, претендуя на роль... кого-то свыше... Лично я считаю, что мой ответ также является правильным, поскольку:Цитата(iosifk @ Apr 5 2006, 12:14)
Делается все гораздо проще цифровым методом.
поскольку также делается цифровым путём, и можно ещё поспорить, какой из методов лучше. Например, мой метод не имеет задержки включения и выключения, а срабатывает сразу по первому импульсу. Ещё можно подумать, где будет меньше ячеек занято...Да срабатывает по первому же фронту ЛЮБОЙ помехи. И не подавляет ее. А для счетчика задержка на 3-5 тактов 10МГц - значения не имеет. А вот лишняя "просечка" в сигнале - это вполне может быть.
Для проверки включите UART с тактовой 1:1 и 1:16, погоняйте файлы в сотни килобайт, а потом порассуждаем о том что и как...
Я не претендую на всезнайство...
Просто уже "нагулялся по граблям", вот и рассказываю как этого избежать.
А что касается - где ячеек меньше - так сопоставьте разницу в цене, если она будет, и неделю оплаты Вашего труда, ну, или выкинутые неправильно работающие платы из первой партии приборов.
Поэтому и написал "патронов не жалеть". Практика показывает, что это самый дешевый способ разработки.
Удачи Вам господа!
Цитата(iosifk @ Apr 6 2006, 12:48)
Цитата(Krys @ Apr 6 2006, 06:44)
Например, мой метод не имеет задержки включения и выключения, а срабатывает сразу по первому импульсу. Ещё можно подумать, где будет меньше ячеек занято...
Да срабатывает по первому же фронту ЛЮБОЙ помехи. И не подавляет ее. Для проверки включите UART с тактовой 1:1 и 1:16, погоняйте файлы в сотни килобайтЦитата(iosifk @ Apr 6 2006, 12:48)
А вот лишняя "просечка" в сигнале - это вполне может быть.
Если оптопара находится близко ко входу ПЛИС, то никаких просечек при грамотном исполнении быть не должно. Да, есть шум, но он слабый, и, чтобы он кардинально повлиял на воспринятый входным буфером ПЛИС сигнал так, как будто это сигнал высокой частоты, необходимо "подвести" постоянный уровень до порога переключения входа ПЛИС. А если этот постоянный уровень уже подведён, значит, сигнал с выхода оптопары (читай: сигнал с кнопки при "дребезге") уже "собирается" переходить в другое состояние (по аналогии: контакты кнопки "собираются" переходить в противоположное положение).Цитата(iosifk @ Apr 6 2006, 12:48)
А для счетчика задержка на 3-5 тактов 10МГц - значения не имеет.
Совершенно не факт. Формально, можно найти такие задачи, в которых дорога каждая микросекунда, может, где-то требуется принять решение как можно быстрее. Почему бы и не воспользоваться в таком случае данным достоинством моего метода.То, что мой метод имеет меньшую по сравнению с Вашим методом задержку (в условии отсутствия длинных линий между оптопарой и входом ПЛИС, отсутствия помех, но при наличии "дребезга") - это объективный факт, и с ним спорить бесполезно.
Цитата(iosifk @ Apr 6 2006, 12:48)
Я не претендую на всезнайство...
Просто уже "нагулялся по граблям", вот и рассказываю как этого избежать.
... предварительно с высока своего опыта всех негативно оценив...Просто уже "нагулялся по граблям", вот и рассказываю как этого избежать.
Цитата(iosifk @ Apr 6 2006, 12:48)
А что касается - где ячеек меньше - так сопоставьте разницу в цене, если она будет, и неделю оплаты Вашего труда, ну, или выкинутые неправильно работающие платы из первой партии приборов.
Есть объективный факт, что у моего метода ячеек меньше (если меньше), но Вы спорите не с этим, а с тем, что этот параметр неважен. А между тем, это ещё одно ОБЪЕКТИВНОЕ и НЕОСПОРИМОЕ достоинство (если оно есть - надо проверять)Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! - подавление "дребезга", а не передача данных по длинным линиям в условиях помех), и у первого из них есть для данного случая 2 достоинства, а у второго - лишь универсальность и мифическая надёжность в условиях обобщённой задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод неправильным.
2 Krys Вот что Вы пишете:
"Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! - подавление "дребезга", а не передача данных по длинным линиям в условиях помех), и у первого из них есть для данного случая 2 достоинства, а у второго - лишь универсальность и мифическая надёжность в условиях обобщённой задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод неправильным."
А вот что было сказано: "На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально."
И именно поэтому я акцентировал внимание на том, что устранять дребезг надо не только между оптроном и ПЛИС, но еще необходимо учитывать и входной сигнал.
То, что Вы пишете об Устранении дребезга - верно для кнопки. Верно, что ячеек это будет занимать меньше. И здесь спорить бесполезно и не нужно.
Речь на самом деле о другом. Речь идет о стиле разработок. То, что я предлагаю, возможно, да возможно в конкретном этом случае будет избыточно. Но оно будет работать ВСЕГДА и вне зависимости от того, хороший входной сигнал или плохой. То, что предлагаете Вы - действительно уберет дребезг от оптрона, НО НЕ уберет дребезг из входного сигнала.
Любая разработка - это риск. Ошибки в ТЗ, в схеме, в конструкции, задержки с комплектацией и тд. И все это Вы наверное знаете. Задача разработчика - уменьшить риски. Если Вы заложили избыточность, но сделали проект в срок - Вы можете лишиться только части прибыли из за более дорогих комплектующих. Но если Вы где-то решили "сильно" экономить и закладывать решения, "которые не всегда", то возможно весь проект не заработает. Но только Вы об этом узнаете в тот самый злополучный последний день. И вот представьте, что проект НЕ работает. Фирма - банкрот! Как Вам такая альтернатива? Поэтому всегда можно и нужно для первого изделия заложить избыточность. Проверить, что работает все остальное, а я уверен, что проблема с оптроном не самая сложная.
И уже потом, переходя к серии, можно и нужно оптимизировать проект. Но, повторяю, проект при этом УЖЕ будет работать и у Вас будет финансирование для продолжения проекта. Вот об этом я стараюсь написать. Надо уменьшать риск! Надо применять проверенные решения, которые помогут избежать каких - либо проблем. Экономить вентили - это очень неправильно.
А что касается моего опыта, то к моему сожалению я уже прошел через описанную здесь ситуацию, когда руководитель проекта мне заявлял: "Здесь у нас инофирма и Ваш советский опыт мне не нужен...". Вот поэтому и предостерегаю... Поэтоу постарайтесь меня понять, и не обижайтесь.
Спасибо всем и удачи!
"Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! - подавление "дребезга", а не передача данных по длинным линиям в условиях помех), и у первого из них есть для данного случая 2 достоинства, а у второго - лишь универсальность и мифическая надёжность в условиях обобщённой задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод неправильным."
А вот что было сказано: "На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально."
И именно поэтому я акцентировал внимание на том, что устранять дребезг надо не только между оптроном и ПЛИС, но еще необходимо учитывать и входной сигнал.
То, что Вы пишете об Устранении дребезга - верно для кнопки. Верно, что ячеек это будет занимать меньше. И здесь спорить бесполезно и не нужно.
Речь на самом деле о другом. Речь идет о стиле разработок. То, что я предлагаю, возможно, да возможно в конкретном этом случае будет избыточно. Но оно будет работать ВСЕГДА и вне зависимости от того, хороший входной сигнал или плохой. То, что предлагаете Вы - действительно уберет дребезг от оптрона, НО НЕ уберет дребезг из входного сигнала.
Любая разработка - это риск. Ошибки в ТЗ, в схеме, в конструкции, задержки с комплектацией и тд. И все это Вы наверное знаете. Задача разработчика - уменьшить риски. Если Вы заложили избыточность, но сделали проект в срок - Вы можете лишиться только части прибыли из за более дорогих комплектующих. Но если Вы где-то решили "сильно" экономить и закладывать решения, "которые не всегда", то возможно весь проект не заработает. Но только Вы об этом узнаете в тот самый злополучный последний день. И вот представьте, что проект НЕ работает. Фирма - банкрот! Как Вам такая альтернатива? Поэтому всегда можно и нужно для первого изделия заложить избыточность. Проверить, что работает все остальное, а я уверен, что проблема с оптроном не самая сложная.
И уже потом, переходя к серии, можно и нужно оптимизировать проект. Но, повторяю, проект при этом УЖЕ будет работать и у Вас будет финансирование для продолжения проекта. Вот об этом я стараюсь написать. Надо уменьшать риск! Надо применять проверенные решения, которые помогут избежать каких - либо проблем. Экономить вентили - это очень неправильно.
А что касается моего опыта, то к моему сожалению я уже прошел через описанную здесь ситуацию, когда руководитель проекта мне заявлял: "Здесь у нас инофирма и Ваш советский опыт мне не нужен...". Вот поэтому и предостерегаю... Поэтоу постарайтесь меня понять, и не обижайтесь.
Спасибо всем и удачи!
Исходя из своего советского опыта
В очередной раз убеждаюсь, "цифровая " фильтрация любого вида - это от лукавого. Потому что все эти схемы работают по фронту внутреннего клока.
Если длительность помехи меньше периода этого клока и эта длительность не попадает на фронт этого клока, изменения счетчика не происходит на провоположное (Что была помеха, что нет мы не знаем), а если эта длительность помехи постоянно больше периода клока, то можно просто зависнуть в счете то в плюс, то в минус, не прийти к граничному значению и значит потерять входной сигнал большой длительности. (схема некорректно работает при удержании сигнала начальной установки)
А ссылки на UART в данном случае тоже некорректны. (Если под 1:1 или 1:16 подразумевается отношение несущей UART частоты и внутренней системной).
Ведь принцип приема по UART основан на детектировании стартового бита. Чем выше системная. тем ближе к середине стартового бита, тем меньше вероятность напороться на ошибку кадрирования. Здесь работает другой критерий надежности. Например как в микроконтроллерах эта мажоритарность.
Что интересно, никто и не знает как это делалось например в электронике 60, (Экономили каждый вентиль. Что, хуже работало?)
А вывод прост. Чистить надо линию. Следовать всем требованиям и рекомендациям по использованию тех же драйверов 232.
В цифре наоборот ужесточать требования по приему. (Например в интервале от начала старта до его середины никаких единиц при отсчете внутренним клоком,
иначе игнорировать посылку)
В очередной раз убеждаюсь, "цифровая " фильтрация любого вида - это от лукавого. Потому что все эти схемы работают по фронту внутреннего клока.
Если длительность помехи меньше периода этого клока и эта длительность не попадает на фронт этого клока, изменения счетчика не происходит на провоположное (Что была помеха, что нет мы не знаем), а если эта длительность помехи постоянно больше периода клока, то можно просто зависнуть в счете то в плюс, то в минус, не прийти к граничному значению и значит потерять входной сигнал большой длительности. (схема некорректно работает при удержании сигнала начальной установки)
А ссылки на UART в данном случае тоже некорректны. (Если под 1:1 или 1:16 подразумевается отношение несущей UART частоты и внутренней системной).
Ведь принцип приема по UART основан на детектировании стартового бита. Чем выше системная. тем ближе к середине стартового бита, тем меньше вероятность напороться на ошибку кадрирования. Здесь работает другой критерий надежности. Например как в микроконтроллерах эта мажоритарность.
Что интересно, никто и не знает как это делалось например в электронике 60, (Экономили каждый вентиль. Что, хуже работало?)
А вывод прост. Чистить надо линию. Следовать всем требованиям и рекомендациям по использованию тех же драйверов 232.
В цифре наоборот ужесточать требования по приему. (Например в интервале от начала старта до его середины никаких единиц при отсчете внутренним клоком,
иначе игнорировать посылку)
Цитата(sazh @ Apr 6 2006, 12:18)
Исходя из своего советского опыта
В очередной раз убеждаюсь, "цифровая " фильтрация любого вида - это от лукавого. Потому что все
А ссылки на UART в данном случае тоже некорректны. (Если под 1:1 или 1:16 подразумевается отношение несущей UART частоты и внутренней системной).
А вывод прост. Чистить надо линию. Следовать всем требованиям и рекомендациям по использованию тех же драйверов 232.
В цифре наоборот ужесточать требования по приему. (Например в интервале от начала старта до его середины никаких единиц при отсчете внутренним клоком,
иначе игнорировать посылку)
В очередной раз убеждаюсь, "цифровая " фильтрация любого вида - это от лукавого. Потому что все
А ссылки на UART в данном случае тоже некорректны. (Если под 1:1 или 1:16 подразумевается отношение несущей UART частоты и внутренней системной).
А вывод прост. Чистить надо линию. Следовать всем требованиям и рекомендациям по использованию тех же драйверов 232.
В цифре наоборот ужесточать требования по приему. (Например в интервале от начала старта до его середины никаких единиц при отсчете внутренним клоком,
иначе игнорировать посылку)
Пример с UARTом абсолютно корректный. При тактовой 1:1 из входного сигнала захватывается только один бит, соответствующий середине битового интервала входной частоты. При 1:16 захватываются 3 бита и производится мажоритирование. Таким образом производится некоторая фильтрация.
Привязка асинхронного сигнала к синхронному - тоже вещь известная.
Поскольку не известны реальные режимы работы разрабатываемого прибора, то копья ломать бесполезно. На этом я дискуссию здесь заканчиваю.
Удачи!
Цитата(sazh @ Apr 6 2006, 14:18)
Исходя из своего советского опыта
В очередной раз убеждаюсь, "цифровая " фильтрация любого вида - это от лукавого.
В очередной раз убеждаюсь, "цифровая " фильтрация любого вида - это от лукавого.
Неверный вывод.
Цитата(sazh @ Apr 6 2006, 14:18)
Потому что все эти схемы работают по фронту внутреннего клока.
Если длительность помехи меньше периода этого клока и эта длительность не попадает на фронт этого клока, изменения счетчика не происходит на провоположное (Что была помеха, что нет мы не знаем),
Если длительность помехи меньше периода этого клока и эта длительность не попадает на фронт этого клока, изменения счетчика не происходит на провоположное (Что была помеха, что нет мы не знаем),
Для того эта схема и сделана, чтобы устранять помехи,
спектр которых лежит выше спектра
основного сигнала.
Цитата(sazh @ Apr 6 2006, 14:18)
а если эта длительность помехи постоянно больше периода клока, то можно просто зависнуть в счете то в плюс, то в минус, не прийти к граничному значению и значит потерять входной сигнал большой длительности.
Если длительность импульсов помехи превышает половину
длительности битового интервала, то схема естественно работать
не будет, т.к. вообще не остается критерия для отличия помехи от сигнала.
Эта простенькая схемка для устранения коротких импульсных помех,
она эквивалентна RС-фильтру, за которым стоит тригер Шмидта.
Цитата(sazh @ Apr 6 2006, 14:18)
(схема некорректно работает при удержании сигнала начальной установки)
Это Вы о чем? Если о сигнале nInit, то схема вообще не работает,
пока сигнал Init не снимется. Это же сигнал начального сброса, в реальной схеме
он вообще не используется, он нужен только для моделирования.
Цитата(sazh @ Apr 6 2006, 14:18)
Что интересно, никто и не знает как это делалось например в электронике 60, (Экономили каждый вентиль. Что, хуже работало?)
Я знаю как это делалось в "Электронике 60". Сначала, в этой машине
вообще не было стыка UART, а вывод шел на печатающее устройство "Консул".
Плату стыка ИРПС (UART c токовой петлей) мы делали сами,
на обычной логике 155-й серии, там конечно мажоритарить было лень,
но тактовую все равно использовали 1:16.
Потом стали делать эти платы на 1002ХЛ1(или 1002ХЛ2 не помню),
эта микруха уже имела встроенный мажоритар, правда в этом режиме
требовала тактовую в четыре раза выше, т.е. 1:64.
Насчет того что "хуже работало?":
Если с точки зрения пользователя работающего на дисплее,
подключенном по стыку ИРПС на скорости 9600,
то работало не хуже.
А вот когда этот стык использовался на растояние около 800 метров
на скорости 19200 для обмена между машинами,
то достоверность передачи с мажоритаром была выше.
Все правильно. Чем дальше обсуждаем, тем больше ограничений на горизонте. Вот и триггер Шмидта появился. Единственно с чем не соглашусь: схемы для моделирования и синтеза должны быть идентичны. А схемная реализация имеет право на существование. Вель это соответствует принятым Вами критериям.
Люди !!! Инженеры !!!!
Не ссорьтесь !
каждое мнение имеет право на существование...
Меня больше интересовала именно работа с ПЛИС EPM7160:
-Ограничения на фронт сигнала ?
-И ваша рекомендация по применению триггера Шмитта (Обязательно ли в таких системах ставить его на входе, т.е. формировать "нормальные" фронты или нет ? )
А Оптопара дает фронт 75 нс, при наблюдении на осциллографе фронта более 100 нс, начинались ложные переключения. А входной сигнал частотой 10 КГц проходит по витой паре, l=300м. Фронт сигнала (По ТЗ) не более 100 нс. (100н +75н уже больше 100н) Вот отсюда и был вопрос.
С уважением, Руслан.
Не ссорьтесь !
каждое мнение имеет право на существование...
Меня больше интересовала именно работа с ПЛИС EPM7160:
-Ограничения на фронт сигнала ?
-И ваша рекомендация по применению триггера Шмитта (Обязательно ли в таких системах ставить его на входе, т.е. формировать "нормальные" фронты или нет ? )
А Оптопара дает фронт 75 нс, при наблюдении на осциллографе фронта более 100 нс, начинались ложные переключения. А входной сигнал частотой 10 КГц проходит по витой паре, l=300м. Фронт сигнала (По ТЗ) не более 100 нс. (100н +75н уже больше 100н) Вот отсюда и был вопрос.
С уважением, Руслан.
Если отвечать конкретно по теме:
1. Насколько я помню, ограничение на фронт 40 нс. Это написано либо в даташите, либо в knowledge base на сайте альтеры.
2. Если у Вас есть плавный аналоговый сигнал, то надо ставить тр.Шмидта. Имхо обязательно - я на считаю правильным убирать пилу на выходе цифровым фильтром.
3. Если у Вас в канале есть помехи, амплитуда которых такова, что может перебросить логический уровень - ставьте цифр. фильтр, как и рекомендовали.
Советую обратить внимание также на драйвера, которые работают на 300 метров. Я на такую дальность не делал, максимум был несколько десятков метров -ставил драйвера rs485 и оптроны - марки на помню.
1. Насколько я помню, ограничение на фронт 40 нс. Это написано либо в даташите, либо в knowledge base на сайте альтеры.
2. Если у Вас есть плавный аналоговый сигнал, то надо ставить тр.Шмидта. Имхо обязательно - я на считаю правильным убирать пилу на выходе цифровым фильтром.
3. Если у Вас в канале есть помехи, амплитуда которых такова, что может перебросить логический уровень - ставьте цифр. фильтр, как и рекомендовали.
Советую обратить внимание также на драйвера, которые работают на 300 метров. Я на такую дальность не делал, максимум был несколько десятков метров -ставил драйвера rs485 и оптроны - марки на помню.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.