Счётчик десятинаносекундных импульсов на STM32F4 Опции

[uu5jkb]

Приветствую всех.
Стоит задача вести счёт импульсов, приходящих по пяти каналам. Импульсы уже прямоугольные, сформированные, длительность 10 нс, интервал между импульсами скачет случайным образом, в худшем случае два импульса "слипаются в один". Измерять надо в течение 20 мс, за это время может набежать до 500 тыс. импульсов. По прикидкам, STM32F4 может таткировать свои таймеры 168 МГц и регистрировать импульсы такой длительности. Два 32-разрядных таймеров запустить напрямую, ещё три 16-битных - по прерываниям увеличивать програмный счётчик, чтобы вместилось 500 тыс. импульсов.
Собственно, вопрос: может кто возился с подобным и есть ли какие противопоказания для такого использования СТМ?
Спасибо.

[SasaVitebsk]

Непосредственно по вопросу, если это спасёт, то делитель на ETR МК асинхронный. То есть, предельная частота поступающая на вход может быть выше чем CLK/2.
Но есть и ещё один вопрос. При подключении цепочки таймеров, если нет механизма включения/ отключения входной частоты (счёт на лету), сложно контролировать точность счёта, при переполнении, так как нет механизма параллельной фиксации значений нескольких таймеров.
Короче лучше такую вещь сделать внешей, по отношению к МК. По крайней мере, за минусом последнего таймера в цепочке.

[jcxz]

Но есть и ещё один вопрос. При подключении цепочки таймеров, если нет механизма включения/ отключения входной частоты (счёт на лету), сложно контролировать точность счёта, при переполнении, так как нет механизма параллельной фиксации значений нескольких таймеров.

В чём сложность-то?

Код

uint i, i1, i2 = timerLow;
do {
  i1 = i2;
  i = timerHigh;
  i2 = timerLow;
} while (i1 > i2);
return i << N | i2;

Запустить ДМА по первому событию на чтение порта, складывать всё в буфер (да, его размер должен быть достаточным) по прошествии пачки импульсов уже не в реальном времени проводить пост-обработку данных.

Не хватит быстродействия. Тем более для 5-и каналов работающих на частоте близкой к тактовой CPU.

[demiurg_spb]

Не хватит быстродействия. Тем более для 5-и каналов работающих на частоте близкой к тактовой CPU.

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

[jcxz]

Как это не важно? А как вы их потом разбирать на отдельные счётчики будете если не побитно?

[demiurg_spb]

Как это не важно? А как вы их потом разбирать на отдельные счётчики будете если не побитно?

Вы наверное не понимаете суть идеи.
При ПОСТ обработке весь разбор происходит.
А при накоплении данных никакой обработки - только чтение состояния параллельного порта ввода и сохранение в массив.
Ведь ТС ясно говорит, что длительность пачки импульсов не превышает 20мс...
При этом, благодаря ДМА и большому объёму ОЗУ, пост обработку можно проводить параллельно с накоплением второго (теневого) буфера...

[jcxz]

При ПОСТ обработке весь разбор происходит.
А при накоплении данных никакой обработки - только чтение состояния параллельного порта ввода и сохранение в массив.

Вы считаете что DMA работает на частоте, превышающей частоту CPU?
Для регистрациии 10нс-импульсов потребуется считывать с GPIO с частотой как минимум ==200МГц.
CPU выбранный ТС имеет макс. частоту 168МГц.
И это не учитывая что GPIO обычно работает на частоте в разы ниже частоты ядра; не учитывая скорости памяти
(которая к тому-же внешняя понадобится).

Ведь ТС ясно говорит, что длительность пачки импульсов не превышает 20мс...
При этом, благодаря ДМА и большому объёму ОЗУ, пост обработку можно проводить параллельно с накоплением второго (теневого) буфера...

Где это он такое говорит? Вот его слова:

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

И какая тут ещё может быть параллельная обработка процессором?

Во! если уж так хочется, то я придумал как можно DMA задействовать
ТСу не хвататет таймеров в CPU? Не беда! Заводим один источник импульсов на вход SCLK SPI-порта, переводим его в Slave, максимальная разрядность, настраиваем DMA
на приём с него в одно слово ОЗУ (без инкремента/декремента адреса).
И всё! По окончании интервала счёта считываем содержимое числа оставшихся пересылок DMA-канала, умножаем на разрядность SPI, делим на 2 - получаем число импульсов.
Хотя тут тоже - нужна разрядность SPI хотя-бы 16 (лучше - больше), и желательно - FIFO в SPI. И не забываем про счётчики-делители на входе перед CPU!

[demiurg_spb]

Вы считаете что DMA работает на частоте, превышающей частоту CPU?

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

Где это он такое говорит?

В первом сообщении ТС.

И какая тут ещё может быть параллельная обработка процессором?

Такая, о которой я уже три раза вам говорил.

[adnega]

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

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

[jcxz]

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

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