[ozforester 0]

Добрый вечер. Продолжаю изучать таймеры, пытаюсь понять что можно выжать из простого микроконтроллера при измерении периода между соседними фронтами. Думаю как лучше сохранить текущий CCR с минимальной задержкой, чтобы не потерять следующий. С прерыванием по захвату таймера получается небыстро. Может быть можно объединить два прерывания, дма и таймер, или два таймера с разными каналами дма запускать синхронно, один из которых с прескалером в половину первого? Как лучше поступить? Или я просто чего-то недочитал, и выдумал проблему на ровном месте?

Изменено 30 апреля пользователем ozforester

[HardEgor 66]

В 01.05.2024 в 01:57, ozforester сказал:

 Думаю как лучше сохранить текущий CCR с минимальной задержкой, чтобы не потерять следующий.

Использовать DMA для сохранения значений. Главное, что бы каналов хватило)

[jcxz 192]

48 минут назад, ozforester сказал:

Думаю как лучше сохранить текущий CCR с минимальной задержкой, чтобы не потерять следующий

...

Как лучше поступить?

Использовать нормальный МК, имеющий FIFO в таймере и DMA. А не пытаться натянуть сову на глобус.

[ozforester 0]

Ну, сова и глобус у меня уже есть, а нормальный мк нужно еще добыть. А с какой модели начинается буфер? Если не применить, то хотя бы прочитать и запомнить.

[jcxz 192]

Например - есть у XMC4xxx. У всех МК семейства. Начиная с младших. Глубиной = 4. Может и у более младшего семейства (XMC1xxx) есть - не смотрел.
PS: Наличие FIFO гораздо важнее, чем DMA. Позволяет регистрировать импульсы хоть в 1 такт.

[adnega 11]

12 часов назад, ozforester сказал:

Как лучше поступить? Или я просто чего-то недочитал, и выдумал проблему на ровном месте?

Обрисуйте конкретную задачу - будет проще предложить решение.

Регистры CCR - это и есть FIFO на один элемент, далее - DMA (с характерным темпом не чаще 12 тактов CPU).

Не знаю зачем "нормальным" МК какие-то FIFO: ну наловишь импульсы "хоть в 1 такт" - дальше что? кто их будет способен обработать?

[jcxz 192]

35 минут назад, adnega сказал:

Не знаю зачем "нормальным" МК какие-то FIFO: ну наловишь импульсы "хоть в 1 такт" - дальше что? кто их будет способен обработать?

Кто? Очевидно программа на этом МК. И в чём именно проблема обработать?

35 минут назад, adnega сказал:

Регистры CCR - это и есть FIFO на один элемент

Чушь. FIFO не может быть "на один элемент". По определению.

 

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

[adnega 11]

36 минут назад, jcxz сказал:

Кто? Очевидно программа на этом МК. И в чём именно проблема обработать?

Чушь. FIFO не может быть "на один элемент". По определению.

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

Идут импульсы/паузы в тактах: 1/1-1/2-1/1-1/1 и т.д. непрерывно. Сколько тактов стоит CPU вытащить эти данные из FIFO (со всеми флагами переполнения и т.п.)? Очевидно же, CPU не сможет обработать такой непрерывный поток. Очевидно же, DMA тоже может обеспечить поток, который CPU не сможет обработать.

Чушь - ок.

Отсутствие потери событий гарантируется архитектурой системы. Кто-то проектирует систему, где допускается потеря событий - я так не поступаю и другим не советую.

Предметнее проще: приведите пример задачи, где без "нормального" МК не обойтись. Я довольно сильно использую таймеры - пока все задачки решаются STM-совместимой таймерной периферий большинства популярных МК.

 

[adnega 11]

Могут предложить такую задачку (если ТС не против):

1) Есть адресные светодиодные ленты (типа WS2811) - 4 шт.

2) Есть источник данных для этой светодиодной ленты.

3) Нужно сделать контроллер с одним входом (WS2811) и 4 выходами (WS2811).

4) На каждом выходе нужно индивидуально задать сколько светодиодов будет пропущено из потока.

Проще: нужно входные импульсы пропустить на выход, но первые 24*Ni (i от 1 до 4, Ni > 0) заменить на лог "0".

Будем считать, что импульсы со скважностью 2 и частотой 800кГц.

Я сделал такое на STM32F042 (аналог F030, на F030 тоже заработает). Контроллер позволяет данные для одной длинной светодиодной ленты поделить на сегменты с индивидуальным смещением - резко удобнее становится подключение.

Кста, одноканальный вариант вообще на Тини13 делал)

[jcxz 192]

2 часа назад, adnega сказал:

Идут импульсы/паузы в тактах: 1/1-1/2-1/1-1/1 и т.д. непрерывно.

Может не будем валить с больной головы на здоровую? Речь шла о фиксации длительности одиночных импульсов.

2 часа назад, adnega сказал:

Отсутствие потери событий гарантируется архитектурой системы. Кто-то проектирует систему, где допускается потеря событий - я так не поступаю и другим не советую.

В случае с CCR в STM32 - не только потеря самих событий, но отсутствие информации, что такая потеря произошла. Что делает практически невозможной обработку любых перепадов (даже редких и одиночных) в такой системе.

Вот получили вы через DMA в памяти набор значений CCR о событиях. Хотите например декодировать ШИМ-сигнал по ним. Или длительности коротких импульсов померять. Но где гарантия, что в тот момент, когда STM зарегистрировал событие фронта, по настоящему была короткая иголка (в несколько тактов), спад которой был потерян? А значит - весь дальнейший анализ невозможен, так как неизвестно состояние линии после события - 0 или 1? Как предлагаете определять?

Поэтому при наличии всякого рода дребезгов, анализ посредством DMA на STM32 очень сложен. (если только нет какого-то способа детектировать факт потери). Только ISR. Ведь в ISR можно прочитать текущее реальное состояние линии после события.

2 часа назад, adnega сказал:

Я довольно сильно использую таймеры - пока все задачки решаются STM-совместимой таймерной периферий большинства популярных МК.

Ок. Тогда расскажите - как будете действовать в случае: Вот получили вы событие срабатывания CAPTURE от таймера. Через DMA, в массиве таких событий. Как определите - один там фронт или спад произошёл или 2, 4, ... пересечений? И как определите реальное состояние линии после такого события: 0 или 1? С учётом того, что прерывание от DMA произошло значительно позже этого события.

 

ЗЫ: Или всё-таки в таймерах STM32 есть какой-то способ зарегистрировать факт потери события? Кто знает?

[adnega 11]

>Может не будем валить с больной головы на здоровую? Речь шла о фиксации длительности одиночных импульсов.

С одиночными импульсами вообще проблем никаких нет - хоть поллингом флагов CCR таймера.

Речь шла о захвате в пределе - в терминах ТС "с минимальной задержкой". Я понял, что речь идет о задержке между соседними импульсами.

>отсутствие информации, что такая потеря произошла.

И что делать с информацией, что потеря произошла? Какой практический смысл?

> была короткая иголка (в несколько тактов)

В таймере перед блоком захвата есть аппаратный фильтр - для борьбы с такими иголками)

> Поэтому при наличии всякого рода дребезгов, анализ посредством DMA на STM32 очень сложен.

Я борьбу с дребезгом поручаю аппаратному фильтру. Иначе "дребезги" разобьют в дребезги любую систему, борющуюся с ними программно.

Разве нет?))

Системы, типа, "я зафиксировала дребезг на входе поэтому работать дальше не буду" я рассматривать не готов)

> Тогда расскажите - как будете действовать в случае...

Вообще проблем не вижу. Недавно сдал систему захвата 12 каналов датчиков детонации с привязкой к углу возникновения с точностью 0.025 градуса. Помехи от частотника прут и по каналам захвата и от энкодера)) Есть и аппаратная борьба на входе МК (причем лайтовая, чтоб импульс не сдвинуть и не наврать с углом), и программная низкоуровневая, и программная высокоуровневая. Забавно, вообще все построил на EXTI-прерываниях. А точность получилась - мама не горюй - видно как вал скручивается в зависимости от нагрузки и оборотов)) Кста, есть программная компенсация задержки распространения сигнала во входных аналоговых цепях.

ШИМ-декодировать приходилось в драйвере приемника от ИК-пультов. Или в вызывной панели VIZIT. Или в работе с 1-wire устройствами. Вообще без проблем.

Итого: если не придумывать себе проблему, чтоб потом ее героически решить, то и проблемы не будет.

> ЗЫ: Или всё-таки в таймерах STM32 есть какой-то способ зарегистрировать факт потери события? Кто знает?

Я же сказал: задача фиксировать факт потери события в большинстве случаев не стоит.

Кто знает систему, где обработка потерь импульсов играет рояля?

[jcxz 192]

2 часа назад, adnega сказал:

С одиночными импульсами вообще проблем никаких нет - хоть поллингом флагов CCR таймера.

Да уж... Видимо вы из тех, кто на каждую минимальную функцию (типа захвата фронта/спада) ставит по отдельному процессору. 

[adnega 11]

2 минуты назад, jcxz сказал:

Да уж... Видимо вы из тех, кто на каждую минимальную функцию (типа захвата фронта/спада) ставит по отдельному процессору. 

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

Я максимально использую аппаратные возможности МК. "Хоть поллингом флагов" это не призыв к действию, а иллюстрация простоты задачи.

Для захвата ШИМ я использую два варианта:

1) с обработкой в реальном времени каждого импульса в прерывании;

2) с постобработкой порции или всего пакета импульсов в связке TIM+DMA.

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

Итого, ТСу нужно зафиксировать задачу. Если это анти-ШИМ чего-то нешустрого, то советую освоить TIM+ISR. Для более шустрого, но не требовательного с реалтайму - TIM+DMA. Это закроет 99% типовых потребностей. Будут вопросы - поможем.

Если задачу экстремалить, т.е. повышать частоту до предела, то, разумеется, в этот предел упрешься, а там уже принципиально иные способы решения могут возникнуть. Вместо этого рекомендую освоить TIM_master+TIM_slave - добавит в копилку решений еще 0.99%

[ozforester 0]

 Прерывания загнулись где-то на 1/20 тактовой. DMA примерно на 1/3. Если кратко: подготовка дма на два переноса, запуск таймера с захватом и дма-запросом, ожидание, два переноса и прерывание по их завершению, обработка, перезапуск дма и т.д. Хватит, наверное, для лабы. Конкретной практической задачи не ставилось. Просто поверяю прочитанное, памятуя что "гладко было на бумаге".  Когда стал читать таймеры, дошел до etr - сделал счетчик с "прямым счетом", дошел до захвата - сделал с "обратным" и задумался о точости измерения интервала между двумя событиями. Затем о скорости. Применить смогу, например, при измерении частоты без снижения пограшности измерения аналоговыми средствами. Анти-шим это обратное извелечение информации из ШИМ, декодирование что-ли?
 Правильные МК посмотрел. Купить в розницу незадорого, и собрать минимальный набор для отладки не получится. Похоже на чисто промышленный сегмент.
Для того, чтобы сделать вывод о возможном пропуске, я бы попробовал формирователь, превращающий недоступный для регистрации перепад в доступный и захватывал другим таймером, который бы регистрировал сам факт такого события, чтобы можно было сравнить и отбросить результат работы основного таймера как недостоверный. Конечно, с учетом других влияющих на такой косвенный способ факторов.  Для меня интересным было время, которое тратится на дма, на вход в прерывание, на синхронизацию, время сохранности результата в регистре. Какую-то часть информации можно найти в документации, какую-то нет. Именно так. Экстремальные режимы позволяют лучше проверить степень понимания вопроса.
Про ведомый  пришлось раньше изучить, при составном счетчике из двух 16-разрядных, чтобы не отвлекать процессор. Заодно соседние режимы прочитал. Где-то было даже про взаимодействие через внешние выводы.
Спасибо.

[adnega 11]

45 минут назад, ozforester сказал:

 Прерывания загнулись где-то на 1/20 тактовой. DMA примерно на 1/3.

Это очень хороший результат.

Я бы разделил понятия: "точность-погрешность-и т.п." Тут все ок, без предфильтров будет 1 такт таймера.

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

У вас настроен DMA на два переноса - в будущем можете просто увеличить размер буфера или вообще перейти на кольцо.

Если передавать ядру всю информацию об импульсах, то оно загнется раньше TIM/DMA/ISR.

> Применить смогу, например, при измерении частоты

Частоту можно двумя способами измерять:

1) измерив период между соседними импульсами.

2) измерив количество импульсов за единицу времени.

В зависимости от требований выбирается тот или иной способ.

> Анти-шим это обратное извелечение информации из ШИМ, декодирование что-ли?

Да. Очень во многих областях/протоколах информация передается длительностью импульса/паузы.

> Правильные МК посмотрел. Купить в розницу незадорого, и собрать минимальный набор для отладки не получится.

Не знаю что в них правильного? В наличии нет, ценник конский, решение получится не универсальное, т.к. будет привязано к конкретному МК.

Сразу поставить ПЛИС, если программист не способен решить задачу без красивостей/правильностей в железе.

> Для того, чтобы сделать вывод о возможном пропуске

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

> Для меня интересным было время, которое тратится на дма, на вход в прерывание, на синхронизацию, время сохранности результата в регистре.

Это правильные интересы. У вас ядро популярное. Советую книги Джозефа Ю - зачитаться.