Инструменты пользователя

Инструменты сайта


doc:doclist:timers

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
doc:doclist:timers [2019/07/17 17:07]
vasco [Бит CAP_FIX]
doc:doclist:timers [2019/07/17 18:18] (текущий)
katya
Строка 326: Строка 326:
  
 =====Бит CAP_FIX===== =====Бит CAP_FIX=====
-Событие захвата происходит по фронту тактовой частоты таймера TIM_CLOCK. Если на некотором фронте сигнал на входе канала поменял значение,​ например был логический "​0"​ а стал "​1",​ то генерируется сигнал возникновения события,​ который уходит на NVIC, DMA и прочих абонентов. На следующем такте TIM_CLOCK значение CNT сохраняется в регистры CCR и/или CCR1 и служит значением при котором было зафиксировано событие.+Событие захвата происходит по фронту тактовой частоты таймера TIM_CLOCK. Если на некотором фронте сигнал на входе канала поменял значение,​ напримербыл логический "​0"​ а стал "​1",​ то генерируется сигнал возникновения события,​ который уходит на NVIC, DMA и прочих абонентов. На следующем такте TIM_CLOCK значение CNT сохраняется в регистры CCR и/или CCR1 и служит значениемпри котором было зафиксировано событие.
  
 Но частота TIM_CLOCK может быть много меньше чем частота ядра. Если NVIC получит сигнал на прерывание от события,​ то ядру Cortex-M3 потребуется 12 тактов на то, чтобы войти в прерывание и начать исполнять код. Если этот код считывает значение CCR, то это значение может оказаться старым,​ еще не обновленным,​ потому что такт TIM_CLOCK еще не прошел. Но частота TIM_CLOCK может быть много меньше чем частота ядра. Если NVIC получит сигнал на прерывание от события,​ то ядру Cortex-M3 потребуется 12 тактов на то, чтобы войти в прерывание и начать исполнять код. Если этот код считывает значение CCR, то это значение может оказаться старым,​ еще не обновленным,​ потому что такт TIM_CLOCK еще не прошел.
  
-Этот вариант событий наблюдается в проекте [[https://​github.com/​StartMilandr/​Bugs/​tree/​master/​Timer_CapSyncChannels|"​Задержка обновления регистров захвата CCR в таймерах"​]]. В этом проекте один канал захватывает фронт внешнего сигнала,​ а второй канал захватывает само событие захвата на первом канале. В прерывании считываются значения CCR обоих каналов и теоретически они должны отличаться не больше чем на единицу. Но если сделать частоту TIM_CLOCK небольшой,​ то возникают события когда CCR одного из каналов имеет еще старое,​ не обновленное значение. Получается так, что прерывание возникает от первого события по захвату фронта сигнала,​ а через такт TIM_CLOCK будет захвачено "​событие захвата в первом канале"​. Но обработчик прерывания,​ сработавший по первому событию,​ уже может считать флаги событий в обоих каналах,​ хотя CCR во втором канале еще не обновился. Т.е. флаги показывают,​ что значения захвата можно считывать,​ но CCR еще не обновилось. Если же поднять частоту TIM_CLOCK, то такого поведения не возникает - обработчик не успеет добраться до регистров CCR раньше,​ чем отработает обновление в таймерах.+Этот вариант событий наблюдается в проекте [[https://​github.com/​StartMilandr/​Bugs/​tree/​master/​Timer_CapSyncChannels|"​Задержка обновления регистров захвата CCR в таймерах"​]]. В этом проекте один канал захватывает фронт внешнего сигнала,​ а второй канал захватывает само событие захвата на первом канале. В прерывании считываются значения CCR обоих каналов итеоретическиони должны отличаться не больше чем на единицу. Но если сделать частоту TIM_CLOCK небольшой,​ то возникают событиякогда CCR одного из каналов имеет еще старое,​ не обновленное значение. Получается так, что прерывание возникает от первого события по захвату фронта сигнала,​ а через такт TIM_CLOCK будет захвачено "​событие захвата в первом канале"​. Но обработчик прерывания,​ сработавший по первому событию,​ уже может считать флаги событий в обоих каналах,​ хотя CCR во втором канале еще не обновился. Т.е. флаги показывают,​ что значения захвата можно считывать,​ но CCR еще не обновилось. Если же поднять частоту TIM_CLOCK, то такого поведения не возникает - обработчик не успеет добраться до регистров CCR раньше,​ чем отработает обновление в таймерах.
  
 Чтобы избежать подобного сценария в регистры CHx_CTRL2 таймеров добавлен **4-й бит**, который мы называем **CAP_FIX**,​ а в спецификациях он еще не описан. При выставлении этого бита в "​1",​ выставление флагов и генерация сигналов событий происходит синхронно с обновлением регистров CCR. Т.е. если стоит флаг события захвата,​ то можно считывать регистр CCR, значение в нем заведомо обновлено. Чтобы избежать подобного сценария в регистры CHx_CTRL2 таймеров добавлен **4-й бит**, который мы называем **CAP_FIX**,​ а в спецификациях он еще не описан. При выставлении этого бита в "​1",​ выставление флагов и генерация сигналов событий происходит синхронно с обновлением регистров CCR. Т.е. если стоит флаг события захвата,​ то можно считывать регистр CCR, значение в нем заведомо обновлено.
doc/doclist/timers.txt · Последние изменения: 2019/07/17 18:18 — katya