Точный подсчёт времени, как реализовать? Опции

[Leo_vrn]

Господа гуру в программировании AVR. Вопрос к вам.

Есть задачка точного измерения промежутков времени. Точность нужна до тысячной доли секунды. Подскажите, каким боком такое можно реализовать. Не должно быть погрешности измерения более 1 тысячной в интервале до 30 секунд.
В идеале нужна параллельная работа двух таких секундомеров. В принципе можно и по одному на разных кристаллах.
Выбор самого кристалла не очень важен. Главное, чтобы имел USART.

[AVR]

Точность нужна до тысячной доли секунды. Подскажите, каким боком такое можно реализовать

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

[junoSynthesizer]

я конечно не гуру а тоже нуб =), но кажись математику никто не отменял

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

т.е. заносим в счётчик цифру 6, чтобы прерывание было вызвано через 0,25 мс
после этого строим внешний счётчик четвертинок секунд (в теле прерывания)
таким образом мы получам погрешность половину от максимально допустимой (если с точностью до 1 мс, тогда максимальная 0,5 получается, вроде так)

и прикол в том, что таких таймеров можно запустить и 2 =)

[bodja74]

1 Инициализируем таймер Т1,если нужна точность ,или кварц с подходящим делителем или внешнее тактирование.
2 Указываем прерывание по захвату от Т1
3 В прерывании с регитра ICR читаем полученную длину импульса
4 Отправляем значение в USART

Пойдет мега8,16 и т.д.

[defunct]

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

Уточните задачу:
Как и какие события будут сигнализировать МК о старте измерения и о финише?

Потому что просто "отмерять" интервалы времени - тривиальная задача:
зная возможности аппаратуры - 16 битный таймер в режиме CTC с генерацией прерывания, обеспечит абсолютно точное деление частоты осциллятора на любое натуральное число больше 11+(количество тактов требующихся на обработку). Дальше не составит труда преобразовать полученную таким образом частоту в интервал времени: T = OCR1X/ Fosc. Ну и подобрать осциллятор который обеспечит Вам требующуюся точность.

Например пусть нужно точно отмерять интервал времени в 1ms, тогда, подставив этот интервал в формулу
OCR1X = Fosc * 0.001c.
для обеспечения высокой точности OCR1X должен быть натуральным числом >11, т.о. нам остается только подобрать кварц (любой из 4.000Mhz, 8.000Mhz, 10.000Mhz и т.п.).

[arttab]

а если не серийка, то и поправочный коэфициетн для своего кварца измерить и корректировать измерения

[Leo_vrn]

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

Уточните задачу:
Как и какие события будут сигнализировать МК о старте измерения и о финише?

Потому что просто "отмерять" интервалы времени - тривиальная задача:
зная возможности аппаратуры - 16 битный таймер в режиме CTC с генерацией прерывания, обеспечит абсолютно точное деление частоты осциллятора на любое натуральное число больше 11+(количество тактов требующихся на обработку). Дальше не составит труда преобразовать полученную таким образом частоту в интервал времени: T = OCR1X/ Fosc. Ну и подобрать осциллятор который обеспечит Вам требующуюся точность.

Например пусть нужно точно отмерять интервал времени в 1ms, тогда, подставив этот интервал в формулу
OCR1X = Fosc * 0.001c.
для обеспечения высокой точности OCR1X должен быть натуральным числом >11, т.о. нам остается только подобрать кварц (любой из 4.000Mhz, 8.000Mhz, 10.000Mhz и т.п.).

В качестве события для старта и останова замера времени используется подача лог.0 на какую-нибудь ногу контроллера. То-есть пришёл 0 на одну ногу - запускаем таймер, пришёл 0 на другую ногу - останавливаем таймер.
Получается, что во времяцикла измерения контроллер должен будет постоянно опрашивать состояние одной из своих ног.

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

Лучше всего использовать аппаратную схему захвата таймера. Только два разных сигнала СТАРТ и СТОП тогда нужно будет преобразовать в один импульс, длительность которого нужно измерить. Сделать это можно с помощью внешнего триггера. Этот импульс подаете на вход ICP1. Измеряем так:

1. Разрешаем прерывание по переполнению таймера 1.
2. Разрешаем прерывание по захвату таймера 1 при переходе из 0 в 1.
3. В обработчике прерывания по захвату, если сброшен флаг готовности данных, сохраняем значение регистра ICR1 в переменной A, очищаем переменную B, устанавливаем флаг начала измерения и перенастраиваем схему захвата на переход из 1 в 0.
4. В обработчике прерывания по переполнению таймера 1, если установлен флаг начала измерения, то считаем переполнения таймера в переменной B.
5. В обработчике прерывания по захвату, если установлен флаг начала измерения, сохраняем значение регистра ICR1 в переменной C, сбрасываем флаг начала измерения, устанавливаем флаг готовности данных.

Основная программа неспешно проверяет флаг готовности данных, когда он установится, делает вычисление интервала:

T = 65536 - A + 65536*B + C [периодов тактовой частоты]

Затем передает T по UART. Чтобы начать новый цикл, нужно сбросить флаг готовности данных.

Точность такого метода плюс-минус период тактовой частоты, т.е. лучше микросекунды. И вычислительные ресурсы почти не тратятся.

[singlskv]

Лучше всего использовать аппаратную схему захвата таймера. Только два разных сигнала СТАРТ и СТОП тогда нужно будет преобразовать в один импульс, длительность которого нужно измерить. Сделать это можно с помощью внешнего триггера. Этот импульс подаете на вход ICP1. Измеряем так:

1. Разрешаем прерывание по переполнению таймера 1.
2. Разрешаем прерывание по захвату таймера 1 при переходе из 0 в 1.
3. В обработчике прерывания по захвату, если сброшен флаг готовности данных, сохраняем значение регистра ICR1 в переменной A, очищаем переменную B, устанавливаем флаг начала измерения и перенастраиваем схему захвата на переход из 1 в 0.
4. В обработчике прерывания по переполнению таймера 1, если установлен флаг начала измерения, то считаем переполнения таймера в переменной B.

А что мы посчитаем если прерывание по захвату выставит флаг в момент обработки прерывания
по переполнению ?

Точность такого метода плюс-минус период тактовой частоты, т.е. лучше микросекунды. И вычислительные ресурсы почти не тратятся.

ИМХО если прерывания совпадут, то точность получится 65536 тактов.

[defunct]

А что мы посчитаем если прерывание по захвату выставит флаг в момент обработки прерывания
по переполнению ?

Где-то уже обсуждали подобный вопрос. GetSmart тогда предложил гениально простое решение - в обработчике "по захвату" просто проверять флаг переполнения из регистра TIFR.

ИМХО если прерывания совпадут, то точность получится 65536 тактов.

См. выше ;>

Сообщение отредактировал defunct - Aug 7 2006, 09:45

[singlskv]

Где-то уже обсуждали подобный вопрос. GetSmart тогда предложил гениально простое решение - в обработчике "по захвату" просто проверять флаг переполнения из регистра TIFR.

Код

loop:
    rjmp loop; "захват" в середине 2х тактовой команды
                                              Вариант1           Вариант2
                                             B=5 ICR=0000     B=5 ICR=FFFD             в момент "захвата"
                                             "переполнение"  нет "переполнения"
ICR: ;обработчик прерывания "захват"
                                             "переполнение"    "переполнения"
    проверка "переполнения"  в TIFR
        inc  B                              B=6 ICR=0000     B=6 ICR=FFFD

ну вот мы и получили разницу >65000 тактов.

[bodja74]

А что мы посчитаем если прерывание по захвату выставит флаг в момент обработки прерывания
по переполнению ?

Ничего страшного не произойдет,счетный регистр TCNT в момент захвата перенесет свое значение в регистр ICR и выставится флаг ICF регистра TIFR ,после окончания обработки прерывания по переполнению прога перейдет на прерывание по захвату.

[singlskv]

А что мы посчитаем если прерывание по захвату выставит флаг в момент обработки прерывания
по переполнению ?

Я не очень точно там выразился, смотри мой последний пост.

[defunct]

Долго искал, но таки отыскал ветку где обсуждался подобный вопрос:

http://electronix.ru/forum/index.php?showtopic=16900&hl=

см. коментарий #8

[singlskv]

Долго искал, но таки отыскал ветку где обсуждался подобный вопрос:

http://electronix.ru/forum/index.php?showtopic=16900&hl=

см. коментарий #8

В таком виде как в примере - нельзя выполнять команды условного перехода и арифметические команды в основном цикле программы.

ну дык все правильно.
толко раскажите мне пожалуйста КАК не выполнять 2х/3х тактовые команды в основном
цикле программы ?

[bodja74]

А что мы посчитаем если прерывание по захвату выставит флаг в момент обработки прерывания
по переполнению ?

Я не очень точно там выразился, смотри мой последний пост.

Угу,в принципе не вижу смысла проверять ,пускай себе катится по прерыванию.
А лучше всего растянуть переполнение на более чем 30сек,как я уже писал - поставить
кварц типа 1.024Мгц,2.048Мгц, или внешний такт с той же тысячной и не мучатся со всем этим.

[singlskv]

ИМХО: при любой попытке "уточнить" значение измеряемого интервала
можно нарисовать временную диаграмму которая заставит ошибаться
алгоритм "уточнения".

[defunct]

В таком виде как в примере - нельзя выполнять команды условного перехода и арифметические команды в основном цикле программы.

ну дык все правильно.
толко раскажите мне пожалуйста КАК не выполнять 2х/3х тактовые команды в основном
цикле программы ?

Речь там была не об этом. Абсолютно без разницы какой длины команды будут выполняться в основном цикле программы. Как видно из примера, в обработчиках прерываний у меня не сохраняется флаговый регистр SREG, соответственно арифметические операции и команды условных переходов в основном цикле программы могут выполняться некорректно.

Необходимо немного подправить пример - сохранять SREG на входе в обработчик прерываний и восстанавливать на выходе. А в остальном пример полностью рабочий.

PS: Также заметьте - тот пример был расчитан на обеспечение точности в 1mks, у Вас же речь идет о точности в 1ms (на три порядка меньше).

Сообщение отредактировал defunct - Aug 7 2006, 13:11

[singlskv]

Угу,в принципе не вижу смысла проверять ,пускай себе катится по прерыванию.
А лучше всего растянуть переполнение на более чем 30сек,как я уже писал - поставить
кварц типа 1.024Мгц,2.048Мгц, или внешний такт с той же тысячной и не мучатся со всем этим.

Ну, да это единственный метод, если нужна "абсолютная" точность.
Можно даже выбрать кварц 4,096 или 8,192 , но на время измерения
запрограммировать CLKPR на деление на 2,4 или 8, а делитель таймера на 1024.
Ну или просто режим CTC с прерыванием каждую ms, но при этом придется
забить на то что результаты отличающиеся на несколько мкс могут в итоге
отличаться на 1 ms.

[singlskv]

Код

.def  AL = R24
.def  Const0 = R8
.def  Const1 = R9

....
   ldi  AL, 1
   mov  Const1, AL
   clr  Const0
...

loop:

   rjmp loop ; B=5 ICR=FFFD   "захват" здесь "переполнения" еще нет


; обработчик Input Capture:
TIM1_CAPT:
    in    R4, ICR1L;   "переполнение" уже есть
    in    R5, ICR1H
    mov   R6, R2
    mov   R7, R3
    tst   R5
    brne  _do_not_correct_result
    in    AL, TIFR
    andi  AL, (1 << TOV1)
    breq  _do_not_correct_result
    add   R6, Const1
    adc   R7, Const0
_do_not_correct_result:
; <-- 32-х битный результат в четверке регистров R7-R6-R5-R4 (MSB R7)
    reti
    

; обработчик Timer Overflow:
TIM1_OVF:
     add R2, Const1; Инкрементировать старшие 16 бит 32-х битного счетчика
     adс R3, Const0; учет переноса.
     reti

[defunct]

singlskv

дык почитайте ветку дальше..

переполнение" уже есть

В коде же специально есть проверка для этого случая.

Код

...
    mov   R7, R3
    tst   R5
    brne  _do_not_correct_result ; <--- вот здесь принимается решение добавлять 0x10000 к результату или нет
...

Сообщение отредактировал defunct - Aug 7 2006, 15:20

[singlskv]

singlskv

дык почитайте ветку дальше..

приведите пример кода и я Вам покажу пример когда Ваш код
будет работать неправильно

singlskv

дык почитайте ветку дальше..

переполнение" уже есть

В коде же специально есть проверка для этого случая.

Код

...
    mov   R7, R3
    tst   R5
    brne  _do_not_correct_result; <--- вот здесь принимается решение добавлять 0x10000 к результату или нет
...

просимулируйте Ваш код при R3:R2=5 b ICRH=FF ICRL=FD

[singlskv]

2 defunct
кажется я понял откуда растут "уши" у нашего спора.
читаем datasheet:
When a capture is triggered, the
16-bit value of the counter (TCNT1) is written to the Input Capture Register (ICR1). The
Input Capture Flag (ICF1) is set at the same system clock as the TCNT1 value is copied
into ICR1 Register. If enabled (ICIE1 = 1), the Input Capture Flag generates an Input
Capture interrupt.
то есть значение таймера сохраняется в ICR ДО попадания в процедуру обработки
прерывания ICR, и любые попытки скоректировать значение счетчик могут привести
к ошибке.

[defunct]

просимулируйте Ваш код при R3:R2=5 b ICRH=FF ICRL=FD

Запутали Вы меня.

Надо полагать раз Вы так уверено говорите о глюке и просите меня промоделировать работу примера, то Вы уже это проделали? В таком случае прошу сообщить результат.

Потому что код этот работает должным образом. И учитывает ту ситуацию, которую вы приводите в пример.

Сообщение отредактировал defunct - Aug 7 2006, 20:05

[singlskv]

Был неправ
tst r5
действительно решает проблемму,
только, чтобы все было коректно нужно после опроса "переполнения" в TIFR
сбрасывать флаг.

[defunct]

только, чтобы все было коректно нужно после опроса "переполнения" в TIFR
сбрасывать флаг.

Согласен, спасибо!

[singlskv]

только, чтобы все было коректно нужно после опроса "переполнения" в TIFR
сбрасывать флаг.

Согласен, спасибо!

И Вам спасибо!
мне почему-то показалось что это невозможно, но "tst r5" расставило все по местам...