Думаю использовать Mega 168 или 328, у меня их больше всего, да и опыт на аврах больше.

Да, так пойдёт. Но дополню:
Я бы мерял не просто "от фронта до фронта", а согласно периоду индикации: до последнего фронта сигнала в каждом периоде индикации. И с подсчётом фронтов внутри периода индикации. А потом - делим измеренный интервал времени на количество фронтов за период индикации и выводим. При таком способе точность не будет ухудшаться с ростом частоты сигналов. Будет усреднение по множеству периодов сигнала.

Я вот думаю все-таки задействовать аппаратный щ0ччик и в его прерывании делать предварительную обработку и переключать мультиплексор. Конечно можно будет выкроить целый порт под это, но это не очень будет удобно, т.к. еще нужно 2 ШИМа вывести, датчики температуры, UART вместо дисплея.

Всем спасибо за советы, если что-то годное получится - результат запощу. Пока буду экпериментировать.

В такую жару как сейчас - самое то!

Добавлено after 54 seconds:
И зря! При нынешних-то ценах на ARM-ы... Вот и освоили бы их на такой простой задаче.

Добавлено after 5 minutes 31 second:
Вижу у автора настойчивое желание потратить некий мультиплексор.

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

а можнож на аппаратных счетчиках сделать, зачем ваще mcu

еще хороший вариант взять завалявшуюся fpga , загнать в нее опенсорсный стековый процессор
https://github.com/IamMaxim/OurCPU
и уже на нем писануть алгоритм. можно прямо на языке forth

Всё хорошо, осталось дело за малым - чтобы fpga завалялась.

PS: Окучивать подкроватные пропеллеры при помощи FPGA - это сильно!

хорошо.
у них можно назначить прерывание на любой вывод.
т.е. количество датчиков ограничено только количеством выводом самого МК.


но тут другая проблема - прерывания непредсказуемые ))

поэтому например в радиоуправлении мы опрашивали датчики с высокой частотой (в прерывании таймера 0).



а потом передавали по радио... на комп... и т.д.



может показаться что опрашивать датчики с высокой частотой это пустая трата ресурсов... но в нашем случае это оправдано.
зато у нас высокая стабильность (таймер работает от кварца)... высокая точность... и т.д.

и главное что мы знаем точно когда сработает таймер. и значит можем рассчитать все тайминги.



2 ШИМа вывести, UART - не проблема.

датчики температуры - у нас была проблема... на время опроса датчика температуры желательно отключать все прерывания.
иначе будут ошибки.

а остальном всё замечательно работает))

Интересно, а что, так "смертельно необходимо" знать обороты вентилятора с точностью до одного оборота в минуту (или в секунду)?
2 импульса на оборот, при частоте вращения 1500 оборотов в минуту- это 50 оборотов в секунду, или 15 оборотов за 0,3 секунды. Программируете измерительный интервал не 1 секунду, а 0,3 секунды, и имеете на выходе число и "х100 оборотов в минуту"

Не совсем так. 1500/60=25/[сек]*0,3=(100)*7,5[об/мин]???
Если измерительный интервал взять длительностью 0,6 секунды, получается более правильно 1500/60=25/[сек]*0,6=(100)*15[об/мин]

Управление мультиплексором потребует 4 лапы контроллера. Можно подключиться к входу захвата таймера Т1 через встроенный аналоговый мультиплексор

Спойлер

https://radiokot.ru/forum/download/file.php?mode=view&id=419447&sid=4996caad8af767aed4ee064cd97f9612

Где-то в начале ветки написано, что, таходатчик вентилятора выдаёт ДВА импульса на оборот.

Управление 8-и канальным мультиплексором потребует 3 лапы контроллера.

Можно... но зачем ? ))
-не у всех МК есть 8-и канальным мультиплексор.
-если использовать 8-и канальным мультиплексор то мы потеряем АЦП. который нам ещё пригодится))

Я такой "тахометр" делал на ESP32 + графический дисплей.

Все пины сигналов заводил на аналоговый ключ (74HC4051). Логика максимально тупая.
Сигналы с пинов вентиляторов идут через схему защиты, компараторы (8) на аналоговый ключ. Контроллер выбирает желаемый канал, и уходит в сон на 0,2 секунды. Это максимальное время опроса канала.
Сам сигнал после компараторов и аналогового ключа заводится на пин с прерыванием, который считает импульсы. Если получено 20 импульсов - будет основной поток. После этого переключаемся на следующий канал и продолжаем.

Я не очень заморачивался с причёсыванием кода, но оно работает в пределах 50об/мин ... 9999 об/мин (я оставил 4 разряда под скорость, да и где такие кулеры встречаются?).

Тайминги получаются из внутреннего счётчика времени. На малых оборотах показания плавают, но высокие измеряются более-менее достоверно.

там же речь о очень низких скоростях, нет никакого разумного смысла дополнять gpio порты какимито аппаратными коммутаторами. для защиты gpio там нужны резисторы последовательно входам ~1..10k и все!

это на любой mcu из конца прошлого тысячалетия сделать без доп компанентов. а на esp32 это будет еще и с BT интерфейсом

а все попытки довесить подобное железом чтоб все стало "понятно" - исключительно от отсутствия опыта программирования (сложнее чем демо-скетчи готовые чуть допиливать под себя). ... и с таким подходом этого опыта никогда и не появится

Ой-ли? Уверены?
На electronix-е один человечек жаловался, что енти самые "народные" ESP32 при работе с эфиром периодически запрещают прерывания на несколько мсек! И никто так и не поведал - как победить сей блуд с прерываниями.
Может вы поведаете?

тоже читал про это. сам esp не использовал, кроме как отдельный bt/wifi-uart мост в паре некритичных к задержкам мест

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

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

Кроме того - предположим, что она будет также == "несколько мсек", но повторяться через каждые 100 мсек. И пропеллер вращается с такой же частотой. Что в этом случае увидим? Падающего Карлсона! Так как пропеллер остановился!
Возможно конечно, что хоть прерывания и запрещаются, но не теряются. И срабатывают после конца запрета. Тогда даже при частых запретах в пару мсек проблем быть не должно. Но это всё - вилами по воде. Китайскими вилами из китайского железа.

Вобщем - ESP32 с чёрным ящиком BT-стека для такой задачи - это хождение по минному полю, покрытому слоем грабель. Али его знает - может будет работать, может - нет. А может - иногда будет, иногда - нет.

Т.е. - предлагаете сразу точить костыли?
Зачем? Лучше взять обычный нормальный МК. Без всяких кривых блюпупов. А ESP пусть лучше рядом постоит, коль сильно нужен.