Измерение скокрости врашения вентилятора

[Foxhound]

Доброго времени суток.
Пытаюсь реализовать на STM32 измерение скорости вращения вентилятора.
Идея очень простая на вход таймера в режиме Input Capture direct mode подаем сигнал с датчика хола вентилятора.
Дальше обрабатываем прерывание по нарастающему фрону сигнала. Сбрасываем счетчик и оставляем его считать до следующего наростающего фронта.
Соответственно смотри до скольки досчитал тайме и снова его сбрасываем.
Собственно получаем количество счетов за период. Ну и дальше считаем скорост.

Код:

volatile uint32_t fanCount = 0;
uint8_t changed=0;

void HAL_TIM_IC_CaptureCallback(TIM_HandleTypeDef *htim)
{
    if (htim->Instance == TIM3)
    {
        if(htim->Channel == HAL_TIM_ACTIVE_CHANNEL_1)
        {
            TIM3->CNT = 0;

            fanCount = HAL_TIM_ReadCapturedValue(&htim3, TIM_CHANNEL_1);
            changed=1;
        }
    }
}



Ну и дальше в main в цикле выводим получившееся значение в виртуальный com порт

Код:

 while (1) {

        if(changed) {
            uint32_t tmp = fanCount;
            changed=0;
            printf("%u\n", tmp);
        }
    }


В результате видим вот такую картину:

Код:

57
56
0
56
57
57
57
0
57
56
57
57
57
56
57
0
57
56


значение 56 и 57 соответствуют расчетному, а вот откуда берется 0?

[BigallS]

у вас объявлено volatile uint32_t fanCount = 0;
если HAL_TIM_ReadCapturedValue(&htim3, TIM_CHANNEL_1) не срабатывает
то у вас же fanCount = 0

[Foxhound]

Ну судя по выводу HAL_TIM_ReadCapturedValue(&htim3, TIM_CHANNEL_1) успешно срабатывет, устанавливается правильное значение 56 или 57
Но иногда проскакивает значение 0

Вот почему не понятно

[BigallS]

Вы уверены на 100% что у вас она всегда срабатывает? поставьте "volatile uint32_t fanCount = 1;"
и проверьте повторно .. что там будет?

[КРАМ]

Foxhound писал(а):

Ну судя по выводу HAL_TIM_ReadCapturedValue(&htim3, TIM_CHANNEL_1) успешно срабатывет, устанавливается правильное значение 56 или 57

А с чего вы решили, что 56 или 57 являются правильными значениями?
Дайте расклад по частотам таймера и сигнала, включая форму сигнала с Холла.
С чего вдруг результат шестиразрядный в 32-разрядном контроллере?
Все это смахивает на медленно меняющийся входной сигнал без корректного его формирования по входу, что приводит к дребезгу. А бездумный выбор частот дает нулевой результат вместо хаотичного значения.
Вообще то в таких случаях применяют осциллограф, наблюдая за ногой МК с сигналом и дергая любой ногой в обработчике по таймеру.
Ну и доставляет применение HAL в столь простой задаче. Вы не в состоянии обработать прерывание без колбэка?

[Foxhound]

А с чего вы решили, что 56 или 57 являются правильными значениями?
Дайте расклад по частотам таймера и сигнала, включая форму сигнала с Холла.

Судя по осциллографу сигнал с датчика холла меандр с частотой 87-89 герц.
т.е. период 11,2 - 11,5 мс.

Таймер тактируется от 72МГц. Prescaler 14399.
т.е. таймер считает с частотой 5 кГц или периодом 0,2 мс
соответственно за 11,2-11,5 таймер успевает досчитать до 56 - 57.

Так что цифры вроде правильные. Вечером доберусь до стенда осциллограмму выложу

С чего вдруг результат шестиразрядный в 32-разрядном контроллере?

почему результат 6ти разрядный?

[КРАМ]

Потому что у вас 56 и 57 укладываются в 6 разрядов.
Из каких соображений вы выбирали предделитель таймера?

[Foxhound]

Из каких соображений вы выбирали предделитель таймера?

Исходил из того что у вентиляторов с которыми я экспериментирую скорость вращения 20 - 200 оборотов в секунду.
Соответственно периоды сигналов которые я буду измерять 5 - 50 мс.

Излишняя точность мне не нужна, грубо значений от 0 до 255 мне хватит (8 бит).
Ну собственно обратным счетом и посчитал предделитель.

[Foxhound]

Ну и собственно осцилограмм с сенсора, вроде все норм....

[КРАМ]

Ну тогда в прерывании или колбэке дергаете (делаете тоггл - смену состояния) свободной ногой и смотрите на осциллографе два сигнала - входной и с этой ноги.

[>TEHb<]

Внесу ещё версию: из-за помехи или каких-то особенностей сигнала прерывание срабатывает два раза подряд. Соответственнно, первый раз успел насчитать 57, а второй раз сразу за ним и будет 0.

[КРАМ]

>TEHb< писал(а):

Внесу ещё версию

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

[Foxhound]

Парам.... Парам... Памп....

Проблема решена ))
Для борьбы с дребезгом схема включения была вот такая


С точки зрения осцилограммы полченной на ножке микропроцессора вроде все норм


Но если посмотреть поближе, то это выглядит вот так


Длительность наростающего фронта примерно 1,3 мс, примерно 10% периода.

Убрал конденсатор 0.1uF на землю и все стало замечательно. Никаких выбросов нет.
Правда осцилограмма стала вот такой.... С иголками.... Видимо из за ШИМ


Зато измерения скорости без ошибок. Показания счетчика вот такие

Код:

57
57
57
57
57
57
57
57
57
57
57
57
57
57
57
57
57
57


[jcxz]

КРАМ писал(а):

А бездумный выбор частот дает нулевой результат вместо хаотичного значения.

0 там из-за того, что чел зачем-то обнуляет CNT в ISR. И при наличии дребезга во входном сигнале (с которым он тоже не борется никак) как раз и будут иногда появляться нули.

Добавлено after 6 minutes 38 seconds:
Re: Измерение скокрости врашения вентилятора

Foxhound писал(а):

Проблема решена ))
Для борьбы с дребезгом схема включения была вот такая

Для борьбы с дребезгом следует внести задержку в работу алгоритма после срабатывания прерывания. Т.е. - после получения прерывания захвата (от фронта), переключить таймер в режим выдержки небольшой паузы (режим MATCH), после истечения которой вернуть его обратно в режим CAPTURE. Т.е. - создать небольшую мёртвую зону после срабатывания. Всё.

А манипуляциями с внешними цепями вы проблему не решили, а просто снизили вероятность её проявления.

Foxhound писал(а):

Правда осцилограмма стала вот такой.... С иголками.... Видимо из за ШИМ

Попадёт такая иголка близко к моменту фронта и получите ложное срабатывание снова.

И обнуление CNT - плохая идея. Лучше вычислять разницу между текущим и старым значением счётчика.
Переменная changed тоже должна быть volatile.

[КРАМ]

jcxz писал(а):

КРАМ писал(а):

А бездумный выбор частот дает нулевой результат вместо хаотичного значения.

0 там из-за того, что чел зачем-то обнуляет CNT в ISR. И при наличии дребезга во входном сигнале (с которым он тоже не борется никак) как раз и будут иногда появляться нули.

Если бы делитель был выбран с максимальным динамическим диапазоном скоростей, то нулей бы не было. Патамушта дребезг приводил бы к ненулевому захвату. Маленькому и хаотичному, но ненулевому.
А так, да, нужно копить данные захватов в кольцевом буфере вычислять разницу соседних значений и слегка их фильтровать прямоугольным окном.
ЗЫ. Нет у него никаких иголок. Есть индуктивный сигнал от земляной петли щупа осциллографа. И он далек до порога и гистерезиса входного триггера Шмитта. Ноги и подтяжки надо выбирать правильные или пропускать сигнал через компаратор с включенным цифровым фильтром.
Ставить емкость на сигнал с открытого стока - очень плохая затея. Но если бы автор сменил активный фронт, то результат получил бы и с емкостью.