Добрый день !
Подскажите в чем может быть дело ?
ПЛИС MAX EPM 7160STC 100-6 используется в качестве делителя частоы, внутри счетчик на ЛПМ функции.
Тактовая частота 10 Мгц.
Входная частота 10 кГц.
Входной сигнал синус проходит через оптопару потом идет в виде меандра в ПЛИС
На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально.
Какие существуют ограничения на фронты входных сигналов ?
Как можно выйти из ситуации без использования триггера шмита?

Как мне кажется, выша проблема в том,что вы фронт 10 кГц сигнала ловите на 10 МГц. При этом,из-за того, что фронт 10 кГц развален, то некоторое количество тактов 10МГц попадает на фронт - из-за этого ложные срабатывания.Я прав?

Ставьте оптопару с цифровым выходом - дрожания не будет. Там ставится тр.Шм., которого Вы так не любите.

а подскажите тогда тип оптопары ?
сейчас стоит HCPL0630 ....это какая ? обычная ?

а триггер шмитта начальник ставить не хочет (запрещает).

посмотри HCPL2231 - выход тр. Шм, может быть подойдет даже по распиновке, хотя у
HCPL0630 выход тоже цифровой ( Dual Channel, High CMR, High Speed, TTL Compatible Optocouplers 8 Pin DIP and SOIC-8)

Сообщение отредактировал AlHakim - Apr 4 2006, 17:36

Поскольку там оптрон - транзистор с открытым коллектором, то можно сделать имитатор триггера Шмитта из свободного выхода 7160 и резистора.

можно еще попробовать сделать тригер шмита внутри ПЛИС. выход оптапары заводим на in1 затем ставим диод с in1 на in2 (допустим защелкуть надо передний фронт) в результате во время фронта ждем когда входы сравняются и генеририм выходной импульс, если не хватает одного диода ставим еще один.... дешево т сердито

нафига вам "внешний" триггер Шмидта?
Это же как "дребезг" в механическом контакте. И поступать с ним надо соответственно. Завести на селектор переднего фронта, с него передний фронт на RS-триггер, на вход установки, например. На вход сброса завести задний фронт, но не напрямую с селектора заднего фронта, а через цепь "мёртвого времени", которая бы блокировала прохождение сигнала сброса на время, большее, чем "дребезг". Это время, думаю, вам уже известно из экспериментов.

Скажу Вам так - ответов много и все неправильные!
Делается все гораздо проще цифровым методом. Внутри ставите сдвиговый регистр на частоте 10 Мгц. Его глубина определяется длительностью импульсов помехи, которые могут быть на фронтах. Далее ставится RS-триггер. Если в сдвиговом регистре N нулей подряд, то это значит что сигнал идет на R
вход триггера, если N единиц подряд - то на S.
Можно сделать и "круче". Т.е. реверсивный счетчик и схему сравнения с порогом. Выше верхнего порога - 1, ниже нижнего - 0. При таком варианте из входных данных будут фильтроваться одиночные импульы помехи.
Итог: в программируемой логике надо все делать цифровое, синхронное и не "жалеть патронов".
Удачи!

В дополнение:
Пример реализации такого фильтра:

Спасибо, Верно! И если вывести дополнительные сигналы от состояний "выше-ниже", то сможете оценивать сигнал, попадает ли он как положено в норму, нет ли пропаданий сигнала и тд.
Удачи!

Не надо делать столь категоричные оценки своих коллег, претендуя на роль... кого-то свыше... Лично я считаю, что мой ответ также является правильным, поскольку:

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

Да срабатывает по первому же фронту ЛЮБОЙ помехи. И не подавляет ее. А для счетчика задержка на 3-5 тактов 10МГц - значения не имеет. А вот лишняя "просечка" в сигнале - это вполне может быть.

Для проверки включите UART с тактовой 1:1 и 1:16, погоняйте файлы в сотни килобайт, а потом порассуждаем о том что и как...
Я не претендую на всезнайство...
Просто уже "нагулялся по граблям", вот и рассказываю как этого избежать.
А что касается - где ячеек меньше - так сопоставьте разницу в цене, если она будет, и неделю оплаты Вашего труда, ну, или выкинутые неправильно работающие платы из первой партии приборов.
Поэтому и написал "патронов не жалеть". Практика показывает, что это самый дешевый способ разработки.
Удачи Вам господа!

Какие помехи? Мы говорим о конкретной задаче, о стыковке оптопары с входом ПЛИС, а не о помехоустойчивой передаче данных по длинным линиям; говорим о конкретном явлении, и явление это не наведение помех из эфира на длинную линию передачи, а явление "дребезга". И для дребезга мой метод подходит на 100% и имеет описанные ранее ОБЪЕКТИВНЫЕ и НЕОСПОРИМЫЕ преимущества перед более универсальным, описанным Вами. Преимущества эти имеют место только в данном конкретном случае - борбы с дребезгом. Но имеют место. Неужели не известна истина, что более универсальные решения не всегда полностью оптимальны для кокнретной задачи?...



Если оптопара находится близко ко входу ПЛИС, то никаких просечек при грамотном исполнении быть не должно. Да, есть шум, но он слабый, и, чтобы он кардинально повлиял на воспринятый входным буфером ПЛИС сигнал так, как будто это сигнал высокой частоты, необходимо "подвести" постоянный уровень до порога переключения входа ПЛИС. А если этот постоянный уровень уже подведён, значит, сигнал с выхода оптопары (читай: сигнал с кнопки при "дребезге") уже "собирается" переходить в другое состояние (по аналогии: контакты кнопки "собираются" переходить в противоположное положение).



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

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



... предварительно с высока своего опыта всех негативно оценив...



Есть объективный факт, что у моего метода ячеек меньше (если меньше), но Вы спорите не с этим, а с тем, что этот параметр неважен. А между тем, это ещё одно ОБЪЕКТИВНОЕ и НЕОСПОРИМОЕ достоинство (если оно есть - надо проверять)

Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! - подавление "дребезга", а не передача данных по длинным линиям в условиях помех), и у первого из них есть для данного случая 2 достоинства, а у второго - лишь универсальность и мифическая надёжность в условиях обобщённой задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод неправильным.

2 Krys Вот что Вы пишете:
"Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! - подавление "дребезга", а не передача данных по длинным линиям в условиях помех), и у первого из них есть для данного случая 2 достоинства, а у второго - лишь универсальность и мифическая надёжность в условиях обобщённой задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод неправильным."


А вот что было сказано: "На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально."

И именно поэтому я акцентировал внимание на том, что устранять дребезг надо не только между оптроном и ПЛИС, но еще необходимо учитывать и входной сигнал.
То, что Вы пишете об Устранении дребезга - верно для кнопки. Верно, что ячеек это будет занимать меньше. И здесь спорить бесполезно и не нужно.
Речь на самом деле о другом. Речь идет о стиле разработок. То, что я предлагаю, возможно, да возможно в конкретном этом случае будет избыточно. Но оно будет работать ВСЕГДА и вне зависимости от того, хороший входной сигнал или плохой. То, что предлагаете Вы - действительно уберет дребезг от оптрона, НО НЕ уберет дребезг из входного сигнала.

Любая разработка - это риск. Ошибки в ТЗ, в схеме, в конструкции, задержки с комплектацией и тд. И все это Вы наверное знаете. Задача разработчика - уменьшить риски. Если Вы заложили избыточность, но сделали проект в срок - Вы можете лишиться только части прибыли из за более дорогих комплектующих. Но если Вы где-то решили "сильно" экономить и закладывать решения, "которые не всегда", то возможно весь проект не заработает. Но только Вы об этом узнаете в тот самый злополучный последний день. И вот представьте, что проект НЕ работает. Фирма - банкрот! Как Вам такая альтернатива? Поэтому всегда можно и нужно для первого изделия заложить избыточность. Проверить, что работает все остальное, а я уверен, что проблема с оптроном не самая сложная.
И уже потом, переходя к серии, можно и нужно оптимизировать проект. Но, повторяю, проект при этом УЖЕ будет работать и у Вас будет финансирование для продолжения проекта. Вот об этом я стараюсь написать. Надо уменьшать риск! Надо применять проверенные решения, которые помогут избежать каких - либо проблем. Экономить вентили - это очень неправильно.
А что касается моего опыта, то к моему сожалению я уже прошел через описанную здесь ситуацию, когда руководитель проекта мне заявлял: "Здесь у нас инофирма и Ваш советский опыт мне не нужен...". Вот поэтому и предостерегаю... Поэтоу постарайтесь меня понять, и не обижайтесь.
Спасибо всем и удачи!