Вот такой пост:
http://electronix.ru/forum/index.php?s=&showtopic=14342&view=findpost&p=99317
И вот его текст:
Добрый день!
Подскажите в чем может быть дело?
ПЛИС MAX EPM 7160STC 100-6 используется в качестве делителя частоы,
внутри счетчик на ЛПМ функции.
Тактовая частота 10 Мгц.
Входная частота 10 кГц.
Входной сигнал синус проходит через оптопару потом
идет в виде меандра в ПЛИС
На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те
что нужно, зависит от амплитуды входного сигнала, если подать меандр то все
нормально.
Какие существуют ограничения на фронты входных сигналов ?
Как можно выйти из ситуации без использования триггера шмита?
Высказывания относительно триггеров вне и кривых вариантах при
использовании вентилей из ПЛИС не привожу. Более –
менее правильный ответ дал Krys:
нафига вам
"внешний" триггер Шмидта?
Это же как "дребезг" в механическом контакте. И поступать с ним надо
соответственно. Завести на селектор переднего фронта, с него передний фронт на
RS-триггер, на вход установки, например. На вход сброса завести задний фронт,
но не напрямую с селектора заднего фронта, а через цепь "мёртвого
времени", которая бы блокировала прохождение сигнала сброса на время,
большее, чем "дребезг". Это время, думаю, вам уже известно из
экспериментов.
Возможно, я выступил
резко, но:
Скажу Вам так - ответов
много и все неправильные!
Делается все гораздо проще цифровым методом. Внутри ставите сдвиговый регистр
на частоте 10 Мгц. Его глубина определяется
длительностью импульсов помехи, которые могут быть на фронтах. Далее ставится
RS-триггер. Если в сдвиговом регистре N нулей подряд, то это значит что сигнал
идет на R
вход триггера, если N единиц подряд - то на S.
Можно сделать и "круче". Т.е. реверсивный счетчик и схему сравнения с
порогом. Выше верхнего порога - 1, ниже нижнего - 0. При таком варианте из
входных данных будут фильтроваться одиночные импульсы помехи.
Итог: в программируемой логике надо все делать цифровое, синхронное и не
"жалеть патронов".
Удачи!
Shamil привел текст интегрирующего
фильтра на счетчике, а вот Krys – обиделся.
Не надо делать столь
категоричные оценки своих коллег, претендуя на роль... кого-то свыше...
Лично я считаю, что мой
ответ также является правильным, поскольку:
поскольку также делается
цифровым путём, и можно ещё поспорить, какой из методов лучше. Например, мой
метод не имеет задержки включения и выключения, а срабатывает сразу по первому
импульсу. Ещё можно подумать, где будет меньше ячеек занято...
Мой ответ:
Да срабатывает по первому
же фронту ЛЮБОЙ помехи. И не подавляет ее. А для счетчика задержка на 3-5
тактов 10МГц - значения не имеет. А вот лишняя "просечка" в сигнале -
это вполне может быть.
Для проверки включите UART с тактовой 1:1 и 1:16, погоняйте файлы в сотни
килобайт, а потом порассуждаем о том
что и как...
Я не претендую на всезнайство...
Просто уже "нагулялся по граблям", вот и рассказываю
как этого избежать.
А что касается - где ячеек меньше - так сопоставьте разницу в цене, если она
будет, и неделю оплаты Вашего труда, ну, или выкинутые неправильно работающие
платы из первой партии приборов.
Поэтому и написал "патронов не жалеть". Практика показывает, что это
самый дешевый способ разработки.
Удачи Вам господа!
И после возражения Krys,
... предварительно с высока своего опыта всех негативно оценив...
Есть объективный факт, что
у моего метода ячеек меньше (если меньше), но Вы спорите не с этим, а с тем,
что этот параметр неважен. А между тем, это ещё одно
ОБЪЕКТИВНОЕ и НЕОСПОРИМОЕ достоинство (если оно есть - надо проверять)
Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! -
подавление "дребезга", а не передача данных по длинным линиям в
условиях помех), и у первого из них есть для данного случая 2 достоинства, а у
второго - лишь универсальность и мифическая надёжность в условиях обобщённой
задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод
неправильным.
мне пришлось еще
добавить:
2 Krys Вот что Вы пишете:
"Если сравниваются 2 метода, решающих одну и ту же задачу (конкретную! - подавление "дребезга", а не передача данных по длинным линиям в условиях помех), и у первого из них есть для данного случая 2 достоинства, а у второго - лишь универсальность и мифическая надёжность в условиях обобщённой задачи (а не конкретной!), то, мягко говоря, неверно называть первый метод неправильным."
А вот что было сказано: "На выходе ПЛИС наблюдаем дрожание сигнала и различные частоты но не те что нужно, зависит от амплитуды входного сигнала, если подать меандр то все нормально."
И именно поэтому я акцентировал внимание на том, что устранять дребезг надо не только между оптроном и ПЛИС, но еще необходимо учитывать и входной сигнал.
То, что Вы пишете об Устранении дребезга - верно для кнопки. Верно, что ячеек это будет занимать меньше. И здесь спорить бесполезно и не нужно.
Речь на самом деле о другом. Речь идет о стиле разработок. То, что я предлагаю, возможно, да возможно в конкретном этом случае будет избыточно. Но оно будет работать ВСЕГДА и вне зависимости от того, хороший входной сигнал или плохой. То, что предлагаете Вы - действительно уберет дребезг от оптрона, НО НЕ уберет дребезг из входного сигнала.
Любая разработка - это риск. Ошибки в ТЗ, в схеме, в конструкции, задержки с комплектацией и тд. И все это Вы наверное знаете. Задача разработчика - уменьшить риски. Если Вы заложили избыточность, но сделали проект в срок - Вы можете лишиться только части прибыли из за более дорогих комплектующих. Но если Вы где-то решили "сильно" экономить и закладывать решения, "которые не всегда", то возможно весь проект не заработает. Но только Вы об этом узнаете в тот самый злополучный последний день. И вот представьте, что проект НЕ работает. Фирма - банкрот! Как Вам такая альтернатива? Поэтому всегда можно и нужно для первого изделия заложить избыточность. Проверить, что работает все остальное, а я уверен, что проблема с оптроном не самая сложная.
И уже потом, переходя к серии, можно и нужно оптимизировать проект. Но, повторяю, проект при этом УЖЕ будет работать и у Вас будет финансирование для продолжения проекта. Вот об этом я стараюсь написать. Надо уменьшать риск! Надо применять проверенные решения, которые помогут избежать каких - либо проблем. Экономить вентили - это очень неправильно.
А что касается моего опыта, то к моему сожалению я уже прошел через описанную здесь ситуацию, когда руководитель проекта мне заявлял: "Здесь у нас инофирма и Ваш советский опыт мне не нужен...". Вот поэтому и предостерегаю... Поэтому постарайтесь меня понять, и не обижайтесь.
Спасибо всем и удачи!
Вот здесь изложена
моя позиция на то, как надо вести разработку. И все остальные препирательства и
т.д. я здесь не привожу – это уже неинтересно…. Ссылка дана.