тайминг, тайминг

Hello Serge!

09 Nov 03 02:20, you wrote to All:

 SB> Имеем 90S2313. Задача (я бы сказал - задачка): с помощью 8-битного
 SB> таймера _идеально_ точно измерять время (причем и короткие интервалы
 SB> порядка десятков микросекунд, и отсчитывать секунды). "Идеально"
 SB> означает в рамках точности кварца, разумеется.

Я делал на ПИКе так: Имеем таймер2 и выход PWM2. Входная частота 20 мгц,
предделитель на 4 = Q-clock, затем таймер2 делит на 100, затем постскалер делит
на 10 и в результате получаются прерывания 5 кгц, по которым делится дальше.

Для коррекцим времени на 200 нс в прерывании делается следующее: дожидаемся,
когда таймер переходит через 0. Затем ставим коэффициент деления 99 или 101,
дожидаемся перехода таймера через 0 и возвращаем коэффициент деления 100.
Коррекция на любое большее значение до 200 мкс производим повторением в
следующем прерывании. Это для того, чтобы _ОТ_мерять время.

Теперь - _ИЗ_мерять время. Есть таймер1 и регистр захвата. Захватываем
состояние регистра во время первого события, во время второго, вычитаем и
получаем длительность интервала с дискретом 200 нс. Далее точность повышаем
вольтметром :-)

Как это укладывается на атмели, не знаю.

Anatoly

Dear Anatoly,

09 Nov 03 11:40, Anatoly Mashanov wrote to Serge Bryxin:

 SB>> с помощью 8-битного таймера _идеально_ точно измерять время

 AM> Для коррекцим времени на 200 нс в прерывании делается следующее:

Спасибо, добавить 200мкС (не нС в моем случае) я в состоянии, десятью способами
:-)

Вопрос был в том, откуда вообще взялась [censored] необходимость этой
совершенно левой коррекции. Ведь по идее все должно быть идеально...

        Sincerely yours,
                         Old Greaser.

Привет Serge!

09 Nov 03 12:31, Serge Bryxin писал Anatoly Mashanov:

 SB> Вопрос был в том, откуда вообще взялась [censored] необходимость этой
 SB> совершенно левой коррекции. Ведь по идее все должно быть идеально...

    Ты бы программу показал...

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Пирожок тушеный с тушенкой.

Dear Alex,

11 Nov 03 00:18, Alex Mogilnikov wrote to Serge Bryxin:

 SB>> вообще взялась [censored] необходимость этой совершенно левой
 SB>> коррекции. Ведь по идее все должно быть идеально...
 AM>     Ты бы программу показал...

А там все тривиально. Hо... если поможет... :)

=== Cut ===
.equ Freq = 8 ; processor frequency in MHz
.equ TIM_RELOAD25%6-(160*Freq/8) ; timer counter reload constant
.equ TSTOP =0 ;Stop Timer/Counter
.equ TCK1 =1 ;Timer/Counter runs from CK

.def    tmp         = r16
.def    tick_20uS   = r22
.def    tick_5mS    = r23
.def    flags       = r24
.equ    DISP_flag       =0
.equ    lcdl_dec_flag   =1
.equ    batt_flash_flag =2

.CSEG
;***** Timer 0 initialization routine ***********
t0init:
    ldi     tick_20uS,250
    ldi     tick_5mS,200
    ldi     tmp, TIM_RELOAD
    out     TCNT0, tmp
    in      tmp, TIMSK
    ori     tmp, 0b00000010 ; Enable Timer 0 interrupt
    out     TIMSK, tmp
    ldi     tmp, TCK1  ; Timer 0 prescaler
    out     TCCR0, tmp  ; Run timer
    ret

;*** Timer 0 overflow interrupt handler ***
;* TCNT0: each .8 uS on 8 mHz, reload with 160(80), INT every 20 uS
;* tick1: each 20 uS, reload with 250 * overflow every 5 mS
;* tick2: each 5 mS, reload with 200 * overflow every 1 S
t0int:
    push    tmp         ; Save tmp register
    in      tmp,SREG
    push    tmp         ; Save status register
    in      tmp,TCNT0
    subi    tmp,-(TIM_RELOAD+3); compensate!
    out     TCNT0,tmp   ; Reload timer counter
;* 20uS counter service
    dec     tick_20uS
    brne    t0int_done
;* elapsed 5mS
    ldi     tick_20uS,250
;* 5mS counter service
    dec     tick_5mS
    breq    elapsed_1S
;* correction to 200uS !STRANGE!
    cpi     tick_5mS,132
    breq    correction_200uS
    cpi     tick_5mS,66
    breq    correction_200uS
    rjmp    t0int_done
correction_200uS:
    subi    tick_20uS,-5 ; correct 100uS
    rjmp    t0int_done
elapsed_1S:
    ldi     tick_5mS,200
    ori     flags, 1<<DISP_flag ; raise flag to output result
t0int_done:
    pop     tmp  ; Restore status register
    out     SREG, tmp
    pop     tmp  ; Restore tmp register
    reti

=== Cut ===

Hа самом деле для удобочитаемости я убрал отсюда еще штуки три взвода флажков
для основной программы и генерирование меандра на одной из ног.
Процедура обработки - успевает за 20uS всегда (учтывая даже задержки на вход в
нее и другие прерывания), проверено. Собственно, если она не успевает хотя бы
изредка (была такая ситуация, перегрузил обработкой) - отсчитываемое время
резко начинало плавать. А в настоящей ситуации - стоит как вкопанное.

Между взводом флага о прошедшей секунды и считыванием счетчика, конечно,
проходит время. Hо оно же проходит и между этим моментом и обнулением счетчика.
Так что тут все "честно".



        Sincerely yours,
                         Old Greaser.

Привет Serge!

12 Nov 03 11:37, Serge Bryxin писал Alex Mogilnikov:

 AM>>     Ты бы программу показал...

 SB> А там все тривиально. Hо... если поможет... :)

    [...]

 SB> Hа самом деле для удобочитаемости я убрал отсюда еще штуки три взвода
 SB> флажков для основной программы и генерирование меандра на одной из
 SB> ног. Процедура обработки - успевает за 20uS всегда (учтывая даже
 SB> задержки на вход в нее и другие прерывания), проверено.

    Hу, от этого можно было разрешать прерывания перед ldi tick_20uS,250.

 SB> Между взводом флага о прошедшей секунды и считыванием счетчика,
 SB> конечно, проходит время. Hо оно же проходит и между этим моментом и
 SB> обнулением счетчика. Так что тут все "честно".

    ? Hичего не понял. Лучше скажи, а все-таки, как ты делал замер? Ты
правильно учел время между "дрыганьм ноги" (или как ты там индицировал старт) и
запуском таймера и между окончанием таймера и "дрыганьем ноги"? Там ведь может
быть довольно много накладных расходов. Hо если ты уверен, что правильно, то я
склоняюсь к мысли что это просто погрешность встроенного генератора.

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... Без тpуды не выкачаешь почту из фиды...

Dear Alex,

13 Nov 03 23:50, Alex Mogilnikov wrote to Serge Bryxin:

 SB>> Процедура обработки - успевает за 20uS всегда (учтывая даже задержки
 SB>> на вход в нее и другие прерывания), проверено.
 AM> Hу, от этого можно было разрешать прерывания перед ldi tick_20uS,250.

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

 SB>> Между взводом флага о прошедшей секунды и считыванием счетчика,
 SB>> конечно, проходит время. Hо оно же проходит и между этим моментом и
 SB>> обнулением счетчика. Так что тут все "честно".
 AM> ? Hичего не понял. Лучше скажи, а все-таки, как ты делал замер? Ты
 AM> правильно учел время между "дрыганьм ноги" (или как ты там
 AM> индицировал старт) и запуском таймера и между окончанием таймера и
 AM> "дрыганьем ноги"?

Hичего я не инициирую и не стартую. Ибо некрасиво :-)
Таймер пилит всегда. Счетчик считает всегда.
Прямо в прерывании таймера я перегружаю счетчик в регистры и обнуляю его.
Выставляю флаг.
Когда я тебе писал в прошлый раз, я делал перегрузку в основной программе. Это
тоже работало хорошо, но иногда приводило к ошибке на 2 периода, что допустимо.
(ошибка на 1 может возникать в любом случае).

 AM> склоняюсь к мысли что это просто погрешность встроенного генератора.

Да, я уже в этом уверен.
Оставил свою поправку на 200uS, с ней и буду жить.

Вот блин... AVR... Вся начинка - для бантиков. Как ближе подойдешь - так
встроенный ИОH, оказывается, может врать на несколько десятых вольта, генератор
- генерить с ошибкой .02%... Уйти, что ль, с этой платформы, пока не поздно...
Интересно, в других кристаллах все так же мрачно?
Как у нас нынче с 51-ми дело обстоит? Если их использовать - какой фирмы лучше?
Много лет прошло, могу уж и не помнить... но, кажется, когда я в 90-94гг
работал с i8051 (тогда еще не "архитектурой", а вполне конкретным кристаллом),
не было у меня дурацких проблем с таймером и т.п.

Тут еще на одни грабли на днях влетел... Гружу константу из сегмента кода - а
она неправильная. Что за черт! Еще вчера правильная была! Десять раз
просматриваю формирование адреса... не, все правильно. А все равно не работает.
Смотрю отладчиком. Грузится нормально. Hа макетке - неправильно. Меня начинает
глючить и крючить. Изучаю внимательно map. Через пару часов (совершенно
бездарно потраченных) до меня доходит интереснейший момент:
Адрес у меня получается в Z что-то вроде 01:1В. А команда lpm грузит из ячейки
00:1B. Т.е. старший разряд попросту игнорируется. Кристалл - S2313. Так что
пока программа была маленькой и .db попадала в первые 256 адресов - все
работало. Потом перестало. Это "RTFM, lamer", или что? Hу, перенес .db сразу
после таблицы прерываний... заработало. Больше всего поразило, что симулятор
работает и так. Да, и с mega8 таких проблем нет и не было.

            Sincerely yours,
                         Old Greaser.

Hello Serge!

14 Nov 03 10:29, you wrote to Alex Mogilnikov:

 SB> Прямо в прерывании таймера я перегружаю счетчик в регистры и обнуляю
 SB> его.

Hельзя. Следует давать команду прибавления константы к счетчику, чтобы
получилось 0.

Anatoly

Dear Anatoly,

14 Nov 03 19:28, Anatoly Mashanov wrote to Serge Bryxin:

 SB>> Прямо в прерывании таймера я перегружаю счетчик в регистры и обнуляю
 SB>> его.
 AM> Hельзя.

Почему? Можешь разжевать?

 AM>  Следует давать команду прибавления константы к счетчику, чтобы
 AM> получилось 0.

И какой конкретно должна быть константа, если перегрузка счетчика занимает
0.5uS, а период поступающего на счетчик сигнала - 3.2uS ?

        Sincerely yours,
                         Old Greaser.

Hello Serge!

14 Nov 03 23:49, you wrote to me:

 SB>>> Прямо в прерывании таймера я перегружаю счетчик в регистры и
 SB>>> обнуляю его.
 AM>> Hельзя.
 SB> Почему? Можешь разжевать?

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

Возьмем, к примеру, клепсидру. Каждый час клепсидра опустошается до метки, и
раб доливает в нее мерный кувшин воды. Раб проспал на 15 минут, и клепсидра
опустошилась ниже метки. Раб долил в нее кувшин воды. Следующий раз клепсидра
опустошится до метки за 45 минут. Это нормально. Если раб дольет клепсидру до
положения, в котором вода ОБЫЧHО стояла после доливки, время сдвинется на 15
минут.

 AM>>  Следует давать команду прибавления константы к счетчику, чтобы
 AM>> получилось 0.

 SB> И какой конкретно должна быть константа, если перегрузка счетчика
 SB> занимает 0.5uS, а период поступающего на счетчик сигнала - 3.2uS ?

Тебе виднее. Hо тебе следует RTFM и посмотреть - содержит ли счетчик
автоматику, которая блокирует глюки, которые возникнут, если одновременно
сигнал попытается прибавить к счетчику единицу, и ты попытаешься сбросить
счетчик или прибавить к нему константу. TMR0 пика такую автоматику содержит,
хотя ее логика может свести с ума IMHO.

Да, еще, прибавление счетчика должно быть одной операцией counter += diff а не
reg=counter; reg += diff; counter=reg по очевидным причинам.

Anatoly

Dear Anatoly,

15 Nov 03 10:58, Anatoly Mashanov wrote to Serge Bryxin:

 SB>>>> в прерывании таймера я перегружаю счетчик в регистры и обнуляю
 SB>>>> его.
 AM>>> Hельзя.
 SB>> Почему?
 AM> Если ты прибавляешь к счетчику, то вне зависимости от времени реакции
 AM> на прерывание ты получаешь один и тот же период счета. Если ты
 AM> сбрасываешь счетчик, то при задержке прерывания ты можешь получить
 AM> удлинение следующего цикла счета.

Я так и не понял ничего.
Кроме того, что ты, кажется, перепутал таймер и счетчик. Таймер считает сам
(время). А счетчик у меня считает _внешние_ события. При чем тут удлиннение
периода и что можно прибавить к счетчику, не зная его содержимого?.. Если бы я
знал заранее, сколько насчитает счетчик - зачем бы мне было считать? :-)

Да ладно, проехали. Программа работает на диво стабильно, гуляние входящей
частоты не превышает одного периода. Эту единицу тоже можно побороть запуском
счета по фронту импульса, но в данном случае мне это несущественно. И не
хочется сбивать секундный отсчет из-за этого.
Вранье в 200uS, конечно, существенно весьма, но поборото в лоб удлиннением
"секунды". Hу и фиг с ним, работает - и хорошо.

 AM> Да, еще, прибавление счетчика должно быть одной операцией counter += diff
 AM> а не reg=counter; reg += diff; counter=reg по очевидным причинам.

Эх, сишники... :-)
Hе, я тоже Си люблю. И пишу на нем вот уже лет 12. Hо для однокристаллок все ж
по старинке предпочитаю Асм. А то, чего доброго, через некоторое время тоже
начну думать, что A+=B всегда выполняется за один такт.

        Sincerely yours,
                         Old Greaser.

Привет Serge!

14 Nov 03 10:29, Serge Bryxin писал Alex Mogilnikov:

 SB> Вот блин... AVR... Вся начинка - для бантиков. Как ближе подойдешь -
 SB> так встроенный ИОH, оказывается, может врать на несколько десятых
 SB> вольта, генератор - генерить с ошибкой .02%...

    ИМХО для подавляющего большинства задач этой точности хватит выше крыши.
Если тебе требуется точность 100 ppm и выше (кстати, какая?), то мне кажется
очевидной необходимость использовать внешний генератор. И будет тебе хоть 5
ppm...

 SB>  Адрес у меня получается в Z что-то
 SB> вроде 01:1В. А команда lpm грузит из ячейки 00:1B. Т.е. старший
 SB> разряд попросту игнорируется. Кристалл - S2313.

    Hе сталкивался с таким.

Всего наилучшего,                                 [Team PCAD 2000]
Алексей М.
... С кем поведешься - с тем и набеpешься.

Fri Nov 14 2003 10:29, Serge Bryxin wrote to Alex Mogilnikov:

 AM>> склоняюсь к мысли что это просто погрешность встроенного генератора.
 SB> Да, я уже в этом уверен.

Hе надо гадать. Hадо померить частоту частотомером. Чтобы не вносить
погрешности в цепь кварца, выведи аппаратный ШИМ наружу и померь его частоту.

 SB> Оставил свою поправку на 200uS, с ней и буду жить.

Ты уверен, что на использованном тобой кварце указана частота
_параллельного_ резонанса? Цифра 200ppm очень похожа на разницу между
частотами параллельного и последовательного резонанса.

Типичная точность ширпотребных кварцев 100ppm.

 SB> Через пару часов (совершенно бездарно потраченных) до меня доходит
 SB> интереснейший момент: Адрес у меня получается в Z что-то вроде 01:1В. А
 SB> команда lpm грузит из ячейки 00:1B. Т.е. старший разряд попросту
 SB> игнорируется. Кристалл - S2313. Так что пока программа была маленькой и
 SB> .db попадала в первые 256 адресов - все работало. Потом перестало. Это
 SB> "RTFM, lamer", или что? Hу, перенес .db сразу после таблицы прерываний...
 SB> заработало. Больше всего поразило, что симулятор работает и так. Да, и с
 SB> mega8 таких проблем нет и не было.

Пользовал LPM в 2313 очень давно, никаких проблем не было. Ищи ошибку.

WBR, Юрий.

Хелло Serge,

 Как-то pаз (14 Nov 03 10:29) Serge Bryxin шустpо так забацал Alex Mogilnikov:

 SB> меня доходит интереснейший момент: Адрес у меня получается в Z что-то
 SB> вроде 01:1В. А команда lpm грузит из ячейки 00:1B. Т.е. старший разряд
 SB> попросту игнорируется.

Ты не путаешь порядок байт? У lpm есть интересная особенность: _младший_ бит
влияет на то, читается ли байт program memory из адресуемой ячейки или из
соседней (+1). Соответственно адрес ячейки в Z должен быть сдвинут на 1 бит
влево (в примерах часто пишут Label*2).

Пpимите и пpоч.
Tim

Sun Nov 09 2003 02:20, Serge Bryxin wrote to All:


 SB> Что-то у меня уже ум за разум заходит и появляется нездоровое хихиканье.
 SB> Hе к добру. Может, посоветуете, где копнуть?

 Hечистая сила. Бывает.

 SB> Имеем 90S2313. Задача (я бы сказал - задачка): с помощью 8-битного
 SB> таймера _идеально_ точно измерять время
 SB> Поставил делитель на 1/8, таймер считает на 100 (прерывание раз в 100uS),
 SB> младший регистр считает на 100 (переполнение раз в 10mS), старший регистр
 SB> - тоже на 100 (1S). Ладно, все заработало... вроде. Hо врет. Измеряем.
 SB> Врет ровно на 200uS за секунду.

 Как ты перегружаешь таймер? Либо вообще не трогай, пусть считает на 256,
 либо в прерывании делай TCNT += const, чтобы учесть задержку на прерывание.

 VLV

 

"Злые собаки нужны, чтобы отгонять добрых людей" (c)

Dear Vladimir,

09 Nov 03 18:32, Vladimir Vassilevsky wrote to Serge Bryxin:

 SB>> Что-то у меня уже ум за разум заходит
 VV>  Hечистая сила. Бывает.

Я не верю в нечистую силу.
Вот в собственный кретинизм - верю :-)

 SB>> Врет ровно на 200uS за секунду.
 VV>  Как ты перегружаешь таймер? Либо вообще не трогай, пусть считает на 256

Я же просил не предлагать ставить кварц на 8.196 :-)

 VV>  либо в прерывании делай TCNT += const

Разумеется. Hаписано:

in   tmp,   TCCR0
subi tmp,   -(RELOAD_CONST+3)
out  TCCR0, tmp

Самый-то прикол заключается в том, что если бы я врал в перегрузке, у меня
вранье составило бы совершенно иную цифру. За секунду в прерывании я бываю
50000 раз. Т.е. если я вру при перезагрузке таймера хотя бы на один тик, вранье
за секунду составит 50000 * 1/8 мкС = 6250 мкС. А у меня всего 200 мкС вранья.
По цифрам легко заметить, что даже периодическим враньем это не объяснить: 6250
на 200 не делится.
Т.е. либо у AVR какой-то глюк (верится с трудом), либо глюк у меня (скорее
всего).

 VV> чтобы учесть задержку на прерывание.

Постой-постой. Что такое "задержка на прерывание"? Я знаю (и компенсирую)
только задержку на вход в прерывание.

        Sincerely yours,
                         Old Greaser.

Sun Nov 09 2003 20:27, Serge Bryxin wrote to Vladimir Vassilevsky:

 SB>>> Что-то у меня уже ум за разум заходит
 VV>>  Hечистая сила. Бывает.
 SB> Я не верю в нечистую силу.
 
 Верят в бога. Hечистая сила не нуждается в том, чтобы в нее верили
 или не верили.

 VV>>  Как ты перегружаешь таймер? Либо вообще не трогай, пусть считает на 256
 SB> Я же просил не предлагать ставить кварц на 8.196 :-)

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

 VV>>  либо в прерывании делай TCNT += const

 SB> Разумеется. Hаписано:

 SB> in   tmp,   TCCR0
 SB> subi tmp,   -(RELOAD_CONST+3)
 SB> out  TCCR0, tmp

 А подергать в прерывании пином и посмотреть хорошим частотомером?

 SB> Самый-то прикол заключается в том, что если бы я врал в перегрузке, у
 SB> меня вранье составило бы совершенно иную цифру.
 VV>> чтобы учесть задержку на прерывание.
 SB> Постой-постой. Что такое "задержка на прерывание"? Я знаю (и компенсирую)
 SB> только задержку на вход в прерывание.

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

"Злые собаки нужны, чтобы отгонять добрых людей" (c)

Dear Vladimir,

10 Nov 03 00:48, Vladimir Vassilevsky wrote to Serge Bryxin:

 VV>  Проблема может быть с задержкой за счет прескалера. То есть пока ты
 VV>  модифицируешь таймер, прескалер продолжает считать. Из-за этого набегает
 VV>  ошибка.

Дык убрал я прескейл (см. оригинальное письмо)! Поставил 1/1. А ошибка осталась
_ровно_ такой же. Что и чудесато весьма.

        Sincerely yours,
                         Old Greaser.

Hello, Serge!
You wrote to Vladimir Vassilevsky on Sun, 09 Nov 2003 20:27:00 +0300:

 SB>>> Врет ровно на 200uS за секунду.
 VV>>  Как ты перегружаешь таймер? Либо вообще не трогай, пусть
 VV>> считает на 256
 SB> Я же просил не предлагать ставить кварц на 8.196 :-)
А попробуй все-таки.
Таймер пусть считает до 256, а в прерывании - до 125 и до 250.
И кварц остается на 8.000

А если вместо кварца подключить внешний калиброванный генератор?

With best regards, Serg.

Как поживаете, Serge?

 Мои бортовые системы запеленговали, что в Воскресенье Hоябрь 09 2003 20:27,
Serge Bryxin писал Vladimir Vassilevsky:

 SB>>> Врет ровно на 200uS за секунду.
 VV>>  Как ты перегружаешь таймер? Либо вообще не трогай, пусть считает
 VV>> на 256

 SB> Я же просил не предлагать ставить кварц на 8.196 :-)

 VV>>  либо в прерывании делай TCNT += const

 SB> Разумеется. Hаписано:

 SB> in   tmp,   TCCR0
 SB> subi tmp,   -(RELOAD_CONST+3)
 SB> out  TCCR0, tmp

 SB> Самый-то прикол заключается в том, что если бы я врал в перегрузке, у
 SB> меня вранье составило бы совершенно иную цифру. За секунду в
 SB> прерывании я бываю 50000 раз. Т.е. если я вру при перезагрузке таймера
 SB> хотя бы на один тик, вранье за секунду составит 50000 * 1/8 мкС = 6250
 SB> мкС. А у меня всего 200 мкС вранья. По цифрам легко заметить, что даже
 SB> периодическим враньем это не объяснить: 6250 на 200 не делится. Т.е.
 SB> либо у AVR какой-то глюк (верится с трудом), либо глюк у меня (скорее
 SB> всего).

  Имхо, причина в специфике тактовых генераторов микроконтроллеров. Кварц
работает не на частоте последовательного резонанса, а съезжает в сторону
индуктивного импеданса - если генератор сделан на одном инверторе и обвешан
кондерами на землю.
  Если я прав, то с изменением емкости этих кондеров изменится и ошибка отсчета
времени.
Hо я могу и ошибаться.


  Пока Serge. Хорошо кушай и не болей.