STM32. Быстрый частотомер. Reciprocal counter.

[HHIMERA]

wait mode это грустно... это ограничить себя во всём...

[alexf58]

Я позволил себе сделать предположение что Вы не поняли и расписал все с точностью до битов и алгоритмов.

Обижаться мне не на что - Вы меня не знаете и можете предположить что угодно. Хотя вроде идею CCR = CNT + 2 высказал именно я. Но оказалось что это не было оригинально

Что до битов и алгоритмов, я с большим удовольствием обсужу до того как делать. STM32 для меня относительно новая игрушка и все что я знаю - исключительно из чтения datasheet'ов.

Более того: я не все понял из вашего поста:
>>>Предсказание срабатывания уже нужно будет записывать в CCR а не в ARR.

По моемУ методу, пока не проверенному, как раз предсказанное значение записывать в ARR. Если входная частота (относительно) постоянна, то можно ничего не переписывать заново. Пусть на входе около 1 МГц. Запишем один раз в ARR скажем 10000 и будем получать update event каждые 10 мсек. По ним делаем capture опорной частоты. Набрали скажем 10 (или 100) отсчетов - считаем наименьшие квадраты и т.д. Если есть графийеский LCD, можно и график с дисперсией нарисовать. Если же на каком то из отсчетов оказалось, что время на переполнение сильно отличается от рассчетного, поменяем ARR. Естественно по системному таймеру следим за тем чтобы переполнения наступали. Если скажем за 50 мсек не было переполнения, либо сигнал пропал совсем, либо частота сильно поменялась.

При этом методе индивидуальные захваты могут заметно отличаться от идеальных (например 10 мсек), но при усреднении это не важно - если частота увеличилась и захваты раз в 5 мсек, наберем их 20 а не 10 и все равно получим "большой" gate time те же 0.1 (или 1) сек.

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

[Galizin]

вроде идею CCR = CNT + 2

HHIMERA показал что это безосновательно и приводит к лишнему ожиданию.

каждые 10 мсек.

Вот это можно улучшить Нужно делать захват как позволяет процессор и сигнал, чем чаще тем лучше. Чем больше захватов тем точнее посчитается частота. Так что как только сохранили данные нужно сразу же делать следующий захват, вернее подготавливаться к следующему захвату. Потом начинать обсчитывать и т.д. А оно пусть захватывается в процессе расчета. Время расчета не постоянно. Но такой алгоритм обеспечит минимальный простой процессора и захват максимального количества точек, следовательно максимальную точность МНК.

[HHIMERA]

Хотя вроде идею CCR = CNT + 2 высказал именно я. Но оказалось что это не было оригинально

Ну и что??? Главное, что вы представляете как оно должно работать... У других всё ещё хуже... для них всё это вообще тёмный лес...

По моемУ методу, пока не проверенному, как раз предсказанное значение записывать в ARR. Если входная частота (относительно) постоянна, то можно ничего не переписывать заново. Пусть на входе около 1 МГц. Запишем один раз в ARR скажем 10000 и будем получать update event каждые 10 мсек.

Метод не нов... Для отладки алгоритма и прочего самое оно... Вот и сейчас на столе на STM8S103K3 юзается тоже самое... 100мС, потом домножается или меняется входной делитель... После этого тупо молотит в цикле... частота то не меняется... Важнее было проверить устойчивость измерений и вообще возможность реализации Reciprocal counter на STM8S... потому что полностью хардварно реализовать нет возможности... из-за особенностей STM8S...

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

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

================
Можно с уверенностью сказать, что частотомер с Reciprocal counter на STM8S состоялся... даже без хардварного вязания таймеров... Семь знаков получаем устойчиво, неадекватностей не выявлено... кроме причуд ИАРа... чтобы им там до рвоты икнулось...
Осталось прямой счёт попробовать... для полной картины...

UPD: В общем прямой счёт на STM8S тоже взлетел... Хотя... на таких частотах (в случае с STM8S)... юзать прямой счёт и особого смысла нет... ИМХО...

[Леонид Иванович]

Любопытно, что за причуды ИАРа?

[HHIMERA]

ИАР под STM8...

Нет поддержки uint64_t...
float и double два сапога пара... на одну ногу...
Покоцанный sprintf...
Но самое интересное... pow()... 10 в степени 2 оказывается... 99 !!!

[alexf58]

Попробовал свою идею в железе. Частичный успех. Вариант выводить наружу события от таймера, тактируемого входной частотой и заводить внешним проводом обратно на вход захвата другого таймера работает. Входная частота 10 МГц прекрасно меряется практически без участия CPU. Пока частота сильно не меняется, я не переписываю период входного таймера.

Теперь плохие новости. Похоже я не разобрался до конца с таймерами. Хочу чтобы TIM2 генерировал события по переполнению (update)
MMS=010b

и чтобы TIM3 захватывал по внутреннему тригеру от TIM2 (ITR1)
CCMR1->CC1S=11
SMCR->TS=001

и ничего не работает. Что то видимо упускаю. Вот все регистры таймеров:

TIM2

CR1 = 0x1
CR2 = 0x20,
SMCR = 0x4000,
DIER = 0x0,
SR = 0x1f,
EGR = 0x0,
CCMR1 = 0x0
CCMR2 = 0x0
CCER = 0x0,
CNT = 0x1fb9
PSC = 0x0,
ARR = 0xffff,
RCR = 0x0,
CCR1 = 0x0,
CCR2 = 0x0,
CCR3 = 0x0,
CCR4 = 0x0,
BDTR = 0x0,
DCR = 0x0,
DMAR = 0x1,


p/x TIM3->SR
$5 = 0x19
p/x *TIM3
$6 = {
CR1 = 0x1
, CR2 = 0x20
SMCR = 0x10
DIER = 0x6
SR = 0x19
EGR = 0x0
CCMR1 = 0x103
CCMR2 = 0x0
CCER = 0x10
CNT = 0x3d95
PSC = 0x0
ARR = 0xffff
RCR = 0x0
CCR1 = 0x0
CCR2 = 0x0
CCR3 = 0x0
CCR4 = 0x0
BDTR = 0x0
DCR = 0x0
DMAR = 0x1

Не подскажете, люди добрые?

[Леонид Иванович]

Нет поддержки uint64_t...

Вообще нет типа long long, или только unsigned?

float и double два сапога пара... на одну ногу... Покоцанный sprintf...

Плавающую запятую и sprintf на микроконтроллерах ни разу не использовал. Но я пока начинающий программист, все еще впереди.

[HHIMERA]

Вообще нет типа long long, или только unsigned?

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

Плавающую запятую и sprintf на микроконтроллерах ни разу не использовал.

Запилил самостоятельно... "но осадочек остался"... Особенно... если оно нужно было только для проверки...

[HHIMERA]

и ничего не работает.

"Разделяй и властвуй!"(С)
Вывод наружу - одна задача... ввод-захват - другая... триггеры - третья... что не работает то???
Типичные примеры есть в референсе... в SPL... и в сниппетсе под F0... Их можно смело юзать под любой камень... с учётом различий таймеров... они там, в основном, обезличенные...

[alexf58]

Вывод наружу - одна задача... ввод-захват - другая... триггеры - третья... что не работает то???

Вывод наружу - работает
Захват с внешней ноги - тоже
Комбинация 1 и 2 тоже, т.е. идея работает через внешний провод.

Таймер 3 успешно захватывает с внешней ноги (РА7) на СС2. Не захватывает update event TIM2, хотя тот успешно переполняется. И генерирует PWM, когда включил.

Вопрос мой именно про связку TIM2 TRGO как сигнал для CC1 TIM3.

P.S. Snippets бегло смотрел, но нигде не видел capture по внутреннему тригеру. Может плохо искал.

P.P.S. Нашел! Бит в CCER разрешает работу capture, но не влияет на захват с внешнего пина (?).

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

[Леонид Иванович]

64-бит отсутствует как класс...

Да, странно. Для 8-битных AVR 64-битные типы в IAR есть, в частотомере их активно использую.

[Galizin]

http://electronix.ru/forum/index.php?sh ... 796&st=135 - вот тут еще была дискуссия по поводу увеличения разрешающей способности.

[Леонид Иванович]

Это старая тема, ничего нового.

[khach]

Кто-нибудь прикручивал к STM32 двойной интерполятор от PICTIC http://www.ko4bb.com/dokuwiki/doku.php?id=precision_timing:pictic Что то с синхронизацией АЦП и таймеров запутался.
Можно ли логику PICTIC (первой версии с дифференциальными ключами) запихать в CPLD? Как выровнять фронт для двух каналов управления ключами?
Ну и встроенный ЦАП STM32 интересно бы приспособить для автокалибрации тока интерполятора.

Вложения

PICTIC1_Interpolator.jpg

Интерполятор частотомера

(107.79 KiB) Скачиваний: 532

[pixar]

Интересно, интересно... Кто-то проверял... или это ОБС???

Это, наверное, я писал . У меня был проект датчика - меандр с таймера подавался через резистор на параллельный контур , частота меандра - на склоне характеристики контура, сигнал на контуре детектировался, напряжение пропорционально индуктивности и присутствию металла. Конденсатор пленочный. Кварцевый генератор внешний. STM32F051.
Вот в этой системе на выходе детектора были импульсные помехи с периодичностью от 1 сек до 10 минут , период зависел от температуры кристалла. Плата была оценочная, на ней стоял и ДДС генератор от того-же питания и того-же генератора. Если сигнал подавался от ДДС - скачков не было . Я смог предположить только срыв захвата clock PLL .

[Леонид Иванович]

первой версии с дифференциальными ключами

А почему именно первой версии? Диодный коммутатор второй версии лучше.

[khach]

Вторая версия не лучше, а проще. Время обратного восстановления примененных диодов 1n4448 4 нс, что ограничивает точность интерполятора. На паре дифференциальных транзисторов можно интерполятор с точностью 50 пс делать. Там ограничивающим фактором будет внутренний джиттер микросхем управления.
С другой стороны параметры коммутатора на диодах требуют достаточно высокого напряжения управления. Для 5В TTL это работать будет, а для современных CPLD c 3 вольтовым питанием- скорее всего нет. С другой стороны CPLD, не предназначенные для работы с дифференциальными сигналами, дадут разбег по времени между ключами в паре, придется или задержки подбирать, или ставить внешние драйвера, что усложняет схему. В идеале вся логика интерполятора делается на дискретных ЭСЛ или ПЭСЛ схемах, но где их достать за вменяемую цену, да и по питанию потребности будут высокие.
Так что пока хочу сделать модель первого интерполятора на xilinx coolrunner (он с диффсигналами вроде умеет работать) и посмотреть, что получится, ну и написать софт для STM32.

[Леонид Иванович]

Ничего подобного. Переключатель тока на диодах - самый быстрый. И у него значительно меньшая инжекция заряда. Совсем не обязательно ставить 1N4148, можно взять и что-то побыстрее. Но даже с ними можно получить порядка 50 пс. Сам лично получал с ними примерно 250 пс, но я особо за разрешением не гнался. Время восстановления диода и апертурное время переключателя тока - не одно и то же.

[khach]

Ничего подобного.

Вы тут самый большой эксперт по любительским интерполяторам. Вот думаю как сравнить объективно разные конструкции. Может что посоветуете по методике проверки точности интерполяторов. Что то типа гистограмм. Ведь еще надо учитывать внутренний джиттер ПЛИС, а он весьма большой, до 300 пс. С интерполятором на 5 вольтовой внешней логике трудно согласовать логические уровни STM32.
Попросили вот к этой конструкции http://radiokot.ru/forum/viewtopic.php?f=10&t=110984 добавить НЧ канал вот и хочется втиснуть интерполятор для повышения точности.
ЗЫ. Планируется, что программировать CPLD будет сам STM32, так что при повторении конструкции проблема с программатором отпадет.