otest, раз срабатывание происходит по фронту, а не по уровню, то какая разница? Если, конечено, делать на дискретных элементах, как в прошлом тысячелетии, то разница еще есть, а если ставить IC - то уже совершенно монопенисуально.
ПростоНуб, И что вам даст триггер Шмидта, если дребезг будет Rail-to-Rail ? Он честно весь этот хлам передаст на вход контроллера.
RC на входе прекрасно работает, он сгладит весь мусор дребезга. А триггер Шмидта есть в самой меге, на каждом цифровом входе. Посмотрите схему порта в любом ДШ - I/O Ports - Ports as General Digital I/O (в ДШ для меги 8 - стр.52). Сначала ТШ, потом синхронизатор.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Вводные - 1000 оборотов максимум, датчик пока не придумал, мк - атмега8. Достаточно ли будет для самодельного тахометра такого алгоритма работы: 2 прерывания первое прерывание INT0 - считывает импульсы с датчика второе прерывание с частотой 1 раз в секунду перемножает импульсы которые накопились за секунду на INT0 и умножает их на 60, а потом сброс переменной подсчёта импульсов. И так частота обновления каждую секунду? Вывод на 3 разряда семисегментника.............
Я сделал так (https://radiokot.ru/forum/viewtopic.php ... &start=711): 1 прерывание (по таймеру) - опрашиваем датчик (датчик Холла) с высокой частотой (у меня 16 кГц). 1 раз в секунду считаем импульсы которые накопились за секунду, полученные данные пропускаем через фильтр - гистерезис (что бы показания на индикаторе не "прыгали") и умножает их на 60 (получаем обороты в минуту), а потом сброс переменной подсчёта импульсов. И так частота обновления каждую секунду. Можно сделать опрос датчика чаще, тогда разрешающая способность будет выше (всё зависит от тактовой частоты МК). Далее вывод на LCD или OLED индикатор.
ПростоНуб, вот для реального изделия я, скорее всего, делал бы более частый опрос и программный антидребезг. (вот, кстати, пересмотрел свои проекты - нигде нет даже RC-фильтров. Кругом программная обработка на высокой частоте дискретизации). Ибо в разовом устройстве - пофиг, а в промышленном каждая точка пайки и каждая деталька денег стоят. И если можно их сэкономить парой десятков строчек кода - то правильней делать программно.
А тут - сферическая лабораторная работа в вакууме. тут либо прямой счет, либо измерение периода. На указанном диапазоне 0..999 мне больше период нравится.
И да, для перестраховки надо иногда в ДШ заглядывать
я, скорее всего, делал бы более частый опрос и программный антидребезг. (вот, кстати, пересмотрел свои проекты - нигде нет даже RC-фильтров. Кругом программная обработка на высокой частоте дискретизации).
А я бы для начал посмотрел схему заводского тахометра.
roman.com, Нигде не говорится про отсутствие триггера Шмидта. Это может быть часть входного формирователя. А ФНЧ там есть. Программный. Без него никак. И у вас ФНЧ программный, когда вы делаете оверсемплинг, а потом смотрите, чего больше начиталось, ноликов или единичек. Я для обработки кнопок и энкодеров тоже использую своеобразный ФНЧ - короткие импульсы дребезга через него не прорываются. Но опять же - есть реальные задачи и области применения реальных частотомеров. Но там есть и внятное ТЗ, и живые характеристики примененных датчиков. Ибо Холл, например, дребезга не должен давать, оптопара с открытым каналом вроде бы тоже. Но желателен триггер шмидта с достаточно большим гистерезисом. А вот сухой контакт звенит по чёрному, но ТШ не нужен, там звон от нуля и до питания. И я скажу по секрету, при наличии достаточных ресурсов МК фильтрующие цепи на входе МК, по большому счету, вообще не нужны. Только защитные, что бы вход не убить. Да, цифре можно помочь, поставив простейший ФНЧ на частоту среза в 10 раз выше макс. частоты сигнала. А все остальное прекрасно разруливается цифровой обработкой сигнала.
Так, стоп. Причем тут АЦП ? Там ФНЧ нужен, что бы во время семплирования сигнал не поплыл. У нас цифровой вход. или ноль, или единица. Читается за время одного такта проца. при 8 мгц это 125 наносекунд. Тут ФНЧ нужен для убирания коротких иголок, которые заведомо помехи. А вот в случае отказа от цифровой обработки сигнала, как того хочет топикстартер, дребезг фильтровать мона и даже нуна. Принцип выбора параметров ФНЧ - через него должно пройти 999/60=16,65 Гц. а все что выше 30-40-50 Гц - уже должно подавляться.
Вводные - 1000 оборотов максимум, датчик пока не придумал, мк - атмега8.
1000 оборотов в секунду или в минуту ? 1000 оборотов в минуту ? Очень медленно... От паровоза... поршневой. )) 1000 оборотов в секунду ? Очень быстро... От самолёта... турбореактивный.))
Откуда там короткие иголки? Сигнал никто не видел. Часто в цифровых схемах (с крутыми фронтами) наблюдаются переходные процессы...
roman.com, Мне почему то кажется, что от механического таходатчика с сухим контактом может прилетать что то вот такого типа
(картинка из дружественной темы про обработчик энкодера) И тут без интегратора (ФНЧ) явно не обойтись. Причем неважно, что это будет - программная обработка или железная. Теоретически, тут должно хватить правильно подобранной RC-цепочки.
А вот это
больше присуще криво настроенным аналоговым каскадам усиления. Или недостаточной ширине полосы пропускания усилительного каскада. А с точки зрения цифровой логики это вполне пристойный меандр. Кстати, вот тут есть интересные визуализации преобразований Фурье - построения сигналов из суммы гармоник.
roman.com писал(а):
Я не знаю что хочет ТС.
С высокой вероятностью - сделать лабораторку и забыть.
goldenandy, есть более примитивный путь. Делаем обработчик прерывания по переднему фронту и запускаем циклически таймер. Если между двумя последующими прерываниями по фронту проходит время меньше Т, то выходим из обработчика ничего не делая, кроме фиксации времени прерывания. Если больше Т - засчитывает фронт и время прошедшее после последнего засчитанного фронта, что и составляет длину периода в наших попугаях (частоте таймера). Зная длительность N последовательных периодов, производим фильтрацию (медианную, линейную или ещё какую на выбор) и вычисляем частоту.
ПростоНуб, можно и так. Но мне жалко тратить целое прерывание и целый таймер под такую обработку. А если надо будет обрабатывать 2 таходатчика? Три ? А еще 4 кнопки и энкодер? При реальной разработке сидишь и думаешь - один таймер на SysClock, второй - на многотональный звук.... прерывание - одно на все кнопки (через диодное И), второе - на сигналы подключения зарядного устройства и флагов зарядки/готовности зарядки... Один канал АЦП - на батарейку, второй - на каой то аналоговый датчик... А проснуться из глубокого сна мега может только по низкому уровню на int0-int1.... А источников пробуждения - кнопки, зарядник и, вполне возможно, что и внешние события.... И это все в одной восьмой меге...
Я в таких случаях предпочитаю оверсемплинг и программную фильтрацию. Под это дело себе даже когда то библиотечку рисовал.
Условно говоря имеем флаг состояния и знаковую переменную-счетчик. Каждую миллисекунду читаем вход. Если вход - единичка и счетчик не достиг верхнего порога - увеличиваем счетчик, если нолик и счетчик не достиг нижнего порога - уменьшаем. Если счетчик достиг верхнего порогового значения, допустим 8 - поднимаем флаг состояния в 1. Момент поднятия флага - это наш нарастающий фронт фильтрованного сигнала. Если счетчик достиг нижнего порогового значения - -8, сбрасываем флаг. Момент сброса флага - это спадающий фронт отфильтрованного сигнала. И получается, что состояние на выходе фильтра изменится только если на вход попадет не меньше 17 (от -8 до +8) отсчетов одного состояния. И что б переключить в другое состояние - нужно получить так же не меньше 17 значений противоположного состояния подряд. Ну а свистопляска дребезга будет дергать счетчик туда-сюда, не изменяя флаг, пока не устаканится противоположный уровень. Т.е. такой себе программный "временнОй триггер Шмидта" с гистерезисом.
Плюс такого алгоритма - нужен один таймер, тикающий с определенной периодичностью. И всё. И по 2 переменных на один счетный вход/вход кнопки/энкодера или еще какого то датчика. Если этот алгоритм оформить в виде функции, на вход которой будет идти состояние входа и ссылка на переменные счетчика и флага, а на выходе будет отдаваться значение флага, то обработка N входов будет выглядеть как вызов N раз этой функции + N наборов переменных флаг+счетчик.
А таймер, кроме опроса входов, может еще заниматься выводом инфы на динамическую индикацию и крутить какой то системный счетчик, к которому основная программа может привязываться - допустим, отсчитывать секундный интервал.
Вобщем, алгоритмов цифровой обработки сигнала вагон и тележка. Но для этого нужно знать постановку задачи. А она пока простая - тахометр 0-999об/мин с каким то виртуальным таходатчиком. 2 решения выше предложены - подсчет частоты или измерение периода. Всё остальное, как мне кажется, выходит за рамки постановки задачи топикстартером. Хотя обмен опытом еще никогда никому не мешал.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 28
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения