Решается... но ЛИ её почему-то забраковал... ввиду ейной некрасивости... Два таймера... TIM2 и TIM3... как частный случай...

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

Если решается то гуд. По идее надо три таймера - один счетчик считает периоды входной частоты (переполнения считать тут, в принципе, не нужно, хватит разрядности и одного) и осуществляет захват измерительного таймера по фронту в начале измерения и в конце (чтоб получалось целое число периодов входной частоты). Т.е. на цикл измерения имеем два захвата. Потом измерительный таймер, счетчик которого будет захватываться первым таймером. И еще нужен счетчик переполнений измерительного таймера. Обязательно. Тогда работа будет по такой схеме (примерно):
- состояние на начало измернения:
*измерительный таймер свободно тикает, его переполнения считаются другим таймеров
*счетчик периодов входной частоты обнулен
*захват запрещен
-старт измерения:
*разрешаем захват
*как только приходит первый фронт происходит аппаратный (!) захват измерительного счетчика и счетчика его переполнений
*захват запрещается
*считываются захваченные значения
*ждем некоторое не строго определенное время (но так чтобы счетчик периодов входной частоты не успел переполнится, либо контролировать переполнение) и разрешаем захват
*по приходу очередного фронта изм. счетчик и счетчик переполнений снова захватываются
*запрещаем захват
*считаем результат и приводим все к исходному состоянию.
Единственный критичный программный момент - это запрет захвата - нужно успеть запретить его раньше чем произойдет второй захват. Если можно сконфигурировать его аппаратно то вообще хорошо.
Такая схема возможна?

Еще один таймер и все дела ))

Вот я и написал
Goodefine, о чем вы говорите. Код уже написан. Все работает на ура. 2 таймера и минимум нагрузки на ядро (2 строки)
Я специально выложил исходник, чтоб можно было поиграться. А разрабатывать теории можно бесконечно.

PS. Могу выложить проект если это интересно

Как считаются переполнения счетчика измерительной частоты (168 МГц)?

Так TIM4_CNT по TIM1_Update обнуляется. Надо считывать его раньше.



А как узнать impCount? Где это значение должно считываться из таймера? Разве что в прерывании по захвату. И то это работоспособно только для низких частот. Для высоких входных частот нельзя просто взять и считать TIM4_CNT в прерывании по захвату TIM1, его значение уже может быть другим.



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

Разумеется нужно захватывать и счетчик входной частоты, все правильно, не написал... Внешние соединения ног, ИМХО, не самая большая проблема, если все нужные величины можно захватывать аппаратно. В идеале - включили однократный захват, подождали и еще раз включили. Все.

Дык... здесь, пожалуй, я поддержу ЛИ...
Теория и есть основа практики... У вас TIM1 рулит TIM4... а должно быть наоборот... По количеству полных периодов пришедших на TIM4 (их количество и определяет измерительный интервал) считывается количество референс-импульсов в TIM1...
Может оно и работает... слава богу... и как частный случай прокатывает... но в широком смысле и по теории - никак... это не Reciprocal counter...

у меня никак. зачем?
Это да. Но в моей задаче и этого достаточно. Но я все-таки перепишу на аппаратный захват.
согласен
Наконец-то вменяемая критика. Конкретно. Я вас изначально как спеца более высокой квалификации воспринимаю. Но есть вопрос:
TIM1 задает окно - максимальный интервал измерения (для меня это критично!). Как это сделать с помощью TIM4 который считает импульсы? частота которых меняется в 10 раз

Потому что:

Чтоб получилось полное число периодов входной частоты - это и определяет Reciprocal counter. А все аппаратные фичи нужны чтоб не терять время на программную обработку в цикле измерений. Думал догадаетесь.

Выше я описал примерную схему словами. Перечитайте еще раз, вы неправильно понимаете суть Reciprocal counter

Подскажите, как проверить влияние синхронности таймеров STM32 на возможность реализации Reciprocal counter? Ведь сигнал на каждый таймер проходит через синхронизатор, который работает на частоте одного из синтезаторов ФАПЧ STM32 а потом еще и делится на некий коэффициент. Сигналы ФАПЧ имеют довольно посредственный спектр фазовых шумов, с широким пьедесталом. На них еще накладываются сигналы от импульсных преобразователей. Не убьет ли такое тактирование саму идею Reciprocal counter? Или на сколько снизит точность измерения?
Я честно говоря в этом вопросе запутался, поэтому пытаюсь реализовать прямой счет с двумя аналоговыми интерполяторами (стартовым и стоповым) используя два канала АЦП STM32 и полностью внешнюю схему синхронизации или на мелкой Альтере или на рассыпухе PECL для случая сверхмалого джиттера. У Альтеры он все-таки великоват - около 200-300 пс в зависимости от схемы.

Здесь речь идет о частотомере без интерполятора. У него погрешность измерения интервалов равна периоду тактовой частоты, джиттер PLL в любом случае меньше. Так что заметного влияния он оказывать не будет. Если же речь идет о качественном частотомере с интерполятором, то строить его на периферии STM32 вряд ли является уместным, нужно брать FPGA + CPLD (или дискретную логику) для чувствительных к джиттеру частей схемы.

Вроде и не каждый сигнал через это проходит.. Обсуждалось.

Каждый... По ETR входной делитель без синхронизатора... а так... каждый...

Ну да, после входного делителя все равно синхронизируется. Но ведь по триггерам входного делителя нет никакой синхронизации. Она наступает уже после N деления.

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

Для начала... ИМХО... добиться результатов на внутреннем сигнале... там уже всё сихронизированно...
Пример приводил... При Тизм 1сек., 0,1сек., и 0,01сек. ... показания должны быть одни и те же и стоять как вкопанные...

2087133.913043 Hz в отладчике...
2087133,9130434782608695652173913 Hz при ручном счёте...

Тогда при внешнем сигнале всё будет в пределах допустимого...

А думал кто о калибровке частотомера по сигналам GPS навигатора? Вроде как там метки времени самые точные. Недорого и эффективно

Можно. Только надо учитывать, что сигнал 1PPS на выходе GPS-приемника имеет довольно большой джиттер (может быть до 1 мкс). Есть специальные тайминговые GPS-модули, джиттер у которых намного меньше (порядка 20 нс). Вообще, тема обсуждалась здесь: http://www.cqham.ru/forum/showthread.php?t=21028

Даже если джиттер 1 мкс... например, при измерении длинного периода, за 1000 секунд джиттер 1 мкс это исчезающе малая величина, обычный кварц уплывет намного сильнее, в тысячи раз.
В той теме действительно все хорошо описано.

Единственное - частотомер должен уметь измерять с высоким разрешением малые частоты порядка 1 Гц с интервалом измерения 1000 сек. Вообще, практичнее сделать генератор образцовой частоты 10 МГц с синхронизацией от GPS. Это будет более универсальный прибор. Такие существуют готовые, а есть и любительские проекты.