Тогда уже одновибратор.

otest, раз срабатывание происходит по фронту, а не по уровню, то какая разница? Если, конечено, делать на дискретных элементах, как в прошлом тысячелетии, то разница еще есть, а если ставить IC - то уже совершенно монопенисуально.

ПростоНуб, И что вам даст триггер Шмидта, если дребезг будет Rail-to-Rail ?
Он честно весь этот хлам передаст на вход контроллера.

RC на входе прекрасно работает, он сгладит весь мусор дребезга.
А триггер Шмидта есть в самой меге, на каждом цифровом входе. Посмотрите схему порта в любом ДШ - I/O Ports - Ports as General
Digital I/O (в ДШ для меги 8 - стр.52). Сначала ТШ, потом синхронизатор.

ХОРОШО ТОГДА МОЖЕТ И СДЕЛАТЬ ДО 62000 ПО ЧАСТОТЕ?

рокки1945, вопрос не понят.

Напишите сначала основную программу, постарайтесь добиться ее работоспособности. Хотя бы в том же протеусе.

Потом уже играйтесь улучшениями.

Я сделал так (https://radiokot.ru/forum/viewtopic.php ... &start=711):
1 прерывание (по таймеру) - опрашиваем датчик (датчик Холла) с высокой частотой (у меня 16 кГц).
1 раз в секунду считаем импульсы которые накопились за секунду, полученные данные пропускаем через фильтр - гистерезис (что бы показания на индикаторе не "прыгали") и умножает их на 60 (получаем обороты в минуту), а потом сброс переменной подсчёта импульсов. И так частота обновления каждую секунду. Можно сделать опрос датчика чаще, тогда разрешающая способность будет выше (всё зависит от тактовой частоты МК).
Далее вывод на LCD или OLED индикатор.

Можно добавить программный дифференциальный фильтр для устранения дребезга...

Но думаю это лишнее. Достаточно просто опрашиваем датчик (датчик Холла) с высокой частотой (у меня 16 кГц).

goldenandy, - ПРОТЕСТИРОВАЛ В ПРОТЕУСЕ - ВСЁ НОРМАЛЬНО ДО МАКСИМУМА 16 БИТНОГО СЧЁТЧИКА. сТАВЛЮ ФИЛЬТР - СИГНАЛ НЕ СЧИТЫВАЕТСЯ! фИЛЬТР НИЗКОЙ ЧАСТОТЫ

рокки1945, схему в студию, полный код в студию. А то мой персональный телепат в отпуск уехал.... И КРИЧАТЬ НЕ НАДО.

Читать надо внимательно:

Дребезг частотой выше среза ФНЧ на вход триггера Шмитта просто не попадет.

ПростоНуб, да, не дочитал. Но тогда ваше предложение вообще не нужно, триггер Шмидта есть в самой меге.

goldenandy, ну тут уже у меня профессиональная деформация - перестраховываюсь )

ПростоНуб, вот для реального изделия я, скорее всего, делал бы более частый опрос и программный антидребезг. (вот, кстати, пересмотрел свои проекты - нигде нет даже RC-фильтров. Кругом программная обработка на высокой частоте дискретизации).
Ибо в разовом устройстве - пофиг, а в промышленном каждая точка пайки и каждая деталька денег стоят. И если можно их сэкономить парой десятков строчек кода - то правильней делать программно.

А тут - сферическая лабораторная работа в вакууме. тут либо прямой счет, либо измерение периода. На указанном диапазоне 0..999 мне больше период нравится.

И да, для перестраховки надо иногда в ДШ заглядывать

А я бы для начал посмотрел схему заводского тахометра.

И особенно блок цифровой обработки сигнала.

И почитал бы описание...



Как видим, никаких ФНЧ и триггера Шмитта в заводских контроллерах нет. Там всё программно. Частота дискретизации от 100 кГц и выше...

В моей программе нет только фильтра скользящего среднего...

Но при необходимости добавим.

roman.com, Нигде не говорится про отсутствие триггера Шмидта. Это может быть часть входного формирователя.
А ФНЧ там есть. Программный. Без него никак.
И у вас ФНЧ программный, когда вы делаете оверсемплинг, а потом смотрите, чего больше начиталось, ноликов или единичек.
Я для обработки кнопок и энкодеров тоже использую своеобразный ФНЧ - короткие импульсы дребезга через него не прорываются.
Но опять же - есть реальные задачи и области применения реальных частотомеров.
Но там есть и внятное ТЗ, и живые характеристики примененных датчиков.
Ибо Холл, например, дребезга не должен давать, оптопара с открытым каналом вроде бы тоже. Но желателен триггер шмидта с достаточно большим гистерезисом. А вот сухой контакт звенит по чёрному, но ТШ не нужен, там звон от нуля и до питания.
И я скажу по секрету, при наличии достаточных ресурсов МК фильтрующие цепи на входе МК, по большому счету, вообще не нужны. Только защитные, что бы вход не убить.
Да, цифре можно помочь, поставив простейший ФНЧ на частоту среза в 10 раз выше макс. частоты сигнала.
А все остальное прекрасно разруливается цифровой обработкой сигнала.

Имелось ввиду отсутствие специальных RC-фильтров. Паразитные индуктивности и ёмкости монтажа обсуждать не будем.

Так же делают и промышленные контроллеры.

В идеале дребезга нет. Не считая шумов по соединительным проводам. Обсуждать не будем.

Во всех даташитах рекомендуют устанавливать простейший ФНЧ, для удаления высокочастотных составляющих из сигнала.

Это общее правило для всех схем с цифровой обработкой сигнала.

Так, стоп. Причем тут АЦП ? Там ФНЧ нужен, что бы во время семплирования сигнал не поплыл.
У нас цифровой вход. или ноль, или единица. Читается за время одного такта проца. при 8 мгц это 125 наносекунд.
Тут ФНЧ нужен для убирания коротких иголок, которые заведомо помехи.
А вот в случае отказа от цифровой обработки сигнала, как того хочет топикстартер, дребезг фильтровать мона и даже нуна. Принцип выбора параметров ФНЧ - через него должно пройти 999/60=16,65 Гц. а все что выше 30-40-50 Гц - уже должно подавляться.

Я не знаю что хочет ТС.

1000 оборотов в секунду или в минуту ?
1000 оборотов в минуту ? Очень медленно... От паровоза... поршневой. ))
1000 оборотов в секунду ? Очень быстро... От самолёта... турбореактивный.))

Откуда там короткие иголки? Сигнал никто не видел.
Часто в цифровых схемах (с крутыми фронтами) наблюдаются переходные процессы...


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

В любом случае обычный RC-фильтр на входе МК спасёт ситуацию. Если правильно подобрать фильтр (частоту среза).

roman.com, Мне почему то кажется, что от механического таходатчика с сухим контактом может прилетать что то вот такого типа

(картинка из дружественной темы про обработчик энкодера)
И тут без интегратора (ФНЧ) явно не обойтись. Причем неважно, что это будет - программная обработка или железная.
Теоретически, тут должно хватить правильно подобранной RC-цепочки.

А вот это

больше присуще криво настроенным аналоговым каскадам усиления. Или недостаточной ширине полосы пропускания усилительного каскада. А с точки зрения цифровой логики это вполне пристойный меандр.
Кстати, вот тут есть интересные визуализации преобразований Фурье - построения сигналов из суммы гармоник.

С высокой вероятностью - сделать лабораторку и забыть.

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

ПростоНуб, можно и так. Но мне жалко тратить целое прерывание и целый таймер под такую обработку. А если надо будет обрабатывать 2 таходатчика? Три ?
А еще 4 кнопки и энкодер?
При реальной разработке сидишь и думаешь - один таймер на SysClock, второй - на многотональный звук.... прерывание - одно на все кнопки (через диодное И), второе - на сигналы подключения зарядного устройства и флагов зарядки/готовности зарядки...
Один канал АЦП - на батарейку, второй - на каой то аналоговый датчик...
А проснуться из глубокого сна мега может только по низкому уровню на int0-int1.... А источников пробуждения - кнопки, зарядник и, вполне возможно, что и внешние события....
И это все в одной восьмой меге...

Я в таких случаях предпочитаю оверсемплинг и программную фильтрацию.
Под это дело себе даже когда то библиотечку рисовал.

Условно говоря имеем флаг состояния и знаковую переменную-счетчик.
Каждую миллисекунду читаем вход.
Если вход - единичка и счетчик не достиг верхнего порога - увеличиваем счетчик, если нолик и счетчик не достиг нижнего порога - уменьшаем.
Если счетчик достиг верхнего порогового значения, допустим 8 - поднимаем флаг состояния в 1. Момент поднятия флага - это наш нарастающий фронт фильтрованного сигнала.
Если счетчик достиг нижнего порогового значения - -8, сбрасываем флаг. Момент сброса флага - это спадающий фронт отфильтрованного сигнала.
И получается, что состояние на выходе фильтра изменится только если на вход попадет не меньше 17 (от -8 до +8) отсчетов одного состояния. И что б переключить в другое состояние - нужно получить так же не меньше 17 значений противоположного состояния подряд. Ну а свистопляска дребезга будет дергать счетчик туда-сюда, не изменяя флаг, пока не устаканится противоположный уровень.
Т.е. такой себе программный "временнОй триггер Шмидта" с гистерезисом.

Плюс такого алгоритма - нужен один таймер, тикающий с определенной периодичностью. И всё. И по 2 переменных на один счетный вход/вход кнопки/энкодера или еще какого то датчика.
Если этот алгоритм оформить в виде функции, на вход которой будет идти состояние входа и ссылка на переменные счетчика и флага, а на выходе будет отдаваться значение флага, то обработка N входов будет выглядеть как вызов N раз этой функции + N наборов переменных флаг+счетчик.

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

Вобщем, алгоритмов цифровой обработки сигнала вагон и тележка. Но для этого нужно знать постановку задачи.
А она пока простая - тахометр 0-999об/мин с каким то виртуальным таходатчиком. 2 решения выше предложены - подсчет частоты или измерение периода.
Всё остальное, как мне кажется, выходит за рамки постановки задачи топикстартером.
Хотя обмен опытом еще никогда никому не мешал.