Если мне память не изменяет... счет фотонов имеет преимущество перед аналоговым интегрированием при скорости импульсов меньше миллиона в секунду.
Или уже не так?

спасибо


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

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

К чему этот юмор? Конечно не считаю.
Я предварительно оценил максимальную синхронную частоту захвата до 16 каналов дискретного ввода, при использовании DMA в сообщении №19.
И я уверен, что есть ряд задач (например не слишком шустрый логический анализатор), где его можно использовать.
Увы не в этот раз.
В первом сообщении ТС.
Такая, о которой я уже три раза вам говорил.

Кажется, у модуля DCMI больше шансов быть задействованным в логическом анализаторе.
Тот вариант, который предлагаете Вы тоже имеет право на жизнь. Таким образом я успешно реализовал самодиагностику линии CAN (обрыв, КЗ, норма, доминанта), о чем года три назад писал на форуме. Связка TIM, DMA и GPIO на аппаратном уровне как раз в той задаче, когда, работая по прерываниям, уже не успеваешь.

Это здорово!
Любопытно... У Вас не сохранилось ссылочки на ту тему?

10 лет назад решал подобную задачу - делал двухканальный счетчик фотонов (http://www.spetspribor.info/products/laboratory/cnt-202.html). Для получения нулевого мертвого времени использовался метод двух счетчиков. Логика реализована на CPLD. Как мне кажется, использовать дляданной задачи таймеры процессора, это что топором бриться.

Тут только назначение. Кста, вы тоже были в той теме)
Тему с аппаратной реализацией пока найти не могу.

У меня в нескольких проектах на LPC17xx так реализован программный UART (аппаратных не хватает). Не только RX, но и TX.
С честным оверсэмплингом ==16.
И дело не в неуспевании. Зачем лишне грузить CPU?

В той задачке, которую решал я работало только на уровне оптимизации по скорости. Как правило нижняя частота на шине CAN некоторыми Phy ограничивается аппаратно. Поэтому тайминги жесткие. Суть проблемы в том, что было предложено решение (пост обработка захваченных данных), которое к данной задаче не очень подходит, но успешно используется в других задачах (мы с Вами привели по реальному примеру).

Теперь, если вернуться к исходной задаче - подсчет импульсов с максимальной пиковой частотой 100МГц (а лучше до 400МГц) при средней частоте (за 20мс) 25МГц без внешних компонентов средствами STM32F40x, то я решения не вижу.

По-моему - это уже даже ТСу ясно

Но если ТС согласится на внешнюю обвязку (придется сфомулировать некоторые критерии: цена, площадь, необходимость прошивки и т.п.), то обсуждение может выйти на новый виток)

Воспользуюсь случаем упомянутого всуе AVR поговорить про Х-Мегу. Понимаю, что это не совсем правильно в разделе, посвященном ARM, тем более что достичь заданной планки в 10 нс она не может. Тем не менее, здесь содержится идея, которая до сих пор не была упомянута, но могла бы оказаться в нашем деле полезной. Поэтому я сейчас изложу идею в приложении к Х-Меге (мне хорошо знакомой), а специалистов по STM32F попрошу прокомментировать мой пост на предмет возможности переноса этой идеи на STM32F.

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

Такая возможность зачастую имеется у МК, имеющих встроенный PLL-генератор частоты, синхронизируемый обычным осциллятором (внутренним или внешним). Для этих целей у Х-Меги существует программный множитель (до х31), позволяющий умножать частоту осциллятора. У STM32F, по-видимому, тоже есть такая же возможность, если он работает на частотах 168-180 МГц на кварце, у которого всего 8 МГц.

Помимо PLL-множителя, у Х-Меги есть еще три делителя (A, B и C), через которые частота PLL поступает в CPU и память. Абсолютное большинство пользователей этими делителями не пользуются, т.е. они остаются в положении 1:1 по умолчанию. Т.е. люди сразу умножают частоту кварца или внутреннего RC-осциллятора до рабочей частоты и на этой частоте работают. Однако частоту PLL можно задрать кверху гораздо выше, погасив избыток делителями, чтобы CPU и память по-прежнему получали привычную частоту. Причем это будет не интерлив, когда пропускаются такты, а самый обычный для ядра режим, поскольку ядро не знает, что по дороге частота была повышена в разы, а потом возвращена назад делителями.

А вот таймеры, порты и кое-что еще из периферии можно тактировать той самой высокой промежуточной частотой. При этом "разрешающая частота" таймера может быть увеличена в разы (2-4 раза) против частоты CPU. Ускоряет ли эта идея счет внешних импульсов, я доподлинно не знаю, но то что генерация ШИМ от этого возрастает, ясно написано в руководстве и сопровождается примером программы.

Осталось только выяснить у знающих людей, способен ли STM32F проделывать подобные вещи, т.е. заставить таймеры тактироваться частотой, превышающей номинальную. И если да, то возможно ли этим способом превзойти 180 МГц на таймерах, не занимаясь разгоном ядра?

При необходимости можно запускать часть кода из SRAM.

Таймеры в STM32F не могут тактироваться от промежуточных частот PLL, предельная частота равна частоте ядра. Можно посмотреть в сторону LPC43xx, там официально до 204 МГц и есть 16-канальный модуль SGPIO, возможно его можно использовать в данной задаче.

Например, в F3 таймеры TIM1 и TIM8 могут тактироваться от 144 МГц при частоте ядра 72 МГц.