Как считать значение аппаратно-программного таймера... Опции

[Alechin]

Есть некий системный таймер, построенный на аппаратном таймере контроллера и расширенный его программным счетчиком (по переполнению таймера) (пример - 32-ух разрядный счетчик микросекунд системного времени). Задача - чтение на лету его значения. Пока без остановки таймера это сделать у меня не получается (периодически получалась рассинхронизация переполнения счетчика аппаратного таймера и еще не инкрементированного старшего слова).
Но при останове таймера происходит потеря точности счета. Приходится корректировать значение. Т.е. все довольно сложно. Какие еще могут быть варианты?

[=GM=]

Есть некий системный таймер, построенный на аппаратном таймере контроллера и расширенный его программным счетчиком (по переполнению таймера) (пример - 32-ух разрядный счетчик микросекунд системного времени). Задача - чтение на лету его значения. Пока без остановки таймера это сделать у меня не получается (периодически получалась рассинхронизация переполнения счетчика аппаратного таймера и еще не инкрементированного старшего слова).
Но при останове таймера происходит потеря точности счета. Приходится корректировать значение. Т.е. все довольно сложно. Какие еще могут быть варианты?

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

[Alechin]

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

Делал такой вариант - все равно проскакивают сбои - ведь пока читали одно из значений могло измениться. И непонятно, когда появился флаг переполнения до чтения таймера или после (у меня чтение значения таймера возможно и в прерывании с более высоким приоритетом, чем прерывание по перепролнению). А понятие "маленькое" растяжимо. Такой вариант уменьшил число сбоев многократно, но не исключил их (я по этому таймеру вычисляю период между метками, подаваемыми на прерывания - до этого раз в пять-шесть секунд были сбои, с данным вариантом раз в 20-30 секунд, с остановом - не дождался сбоя).

[CDT]

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

А если по подробней о задаче и поискать другой алгоритм (способ,метод) измерения?
- какова тактовая частота контроллера и обязана ли она быть такой?;
- период поступления "меток"?;
- потребная точность измерения (только реально, а не "чем лучше тем лучше"?;
- этот таймер меряет только это или еще для чего-то нужен?;
- остальные таймеры заняты?;
- почему обязательно "на лету"?;
- а что за контроллер то?

[Alechin]

А если по подробней о задаче и поискать другой алгоритм (способ,метод) измерения?
- какова тактовая частота контроллера и обязана ли она быть такой?;
- период поступления "меток"?;
- потребная точность измерения (только реально, а не "чем лучше тем лучше"?;
- этот таймер меряет только это или еще для чего-то нужен?;
- остальные таймеры заняты?;
- почему обязательно "на лету"?;
- а что за контроллер то?

Контроллер - M128L на 8 МГц. Выше нельзя - 3-ех Вольтовая.
Задача - измерять частоту сигналов по 8-ми (пока 4-ем) входам. Частота - от 1 кГц (экстрим, обычно 100 Гц) до 0.5 Гц т.е. от 10 мсек до 2 сек (пропаданием сигнала считаю его отсутствие в течение 3 сек). При этом по каждому сигналу необходимо вести счет времени нахождения его частоты в заданном диапазоне (5 диапазонов).
Кроме этого еще куча задач - не скоростных (RTC, дисплей, RF), поэтому реально свободен только один 16-ти разрядный таймер.
Сделано так: на таймере (Т1) построен счетчик системного времени: TCNT1 - младшее слово, WORD переменная - старшее слово, инкрементируемое по перемполнению таймера (т.е. DWORD). Таймер тактируется 1 МГц (делитель на 8). Т.е. очень удобно - имеем 32-ух разрядный счетчик микросекунд (системное время, которое можно также использовать для нужд основной программы).
Обработчики прерывания по каждому вх. сигналу просто считывают значение системного времени, вычисляют разницу с запомненным системным временем предыдущего вызова и ВНИМАНИЕ: добавляют эту разницу к счетчику времени нахождения в соотв. диапазоне частот. Все работает четко, много времени не занимает. Но при ошибках в чтении значения системного таймера счетчики времени работы в заданном диапазоне увеличиваются сразу на очень большое число (т.е. разность системных времен при рассинхронизации старшего и младшего слова получается большой). Это сразу заметно: счетчик тикает по секундам - вдруг раз - пара часов добавилась.
Останавливать таймер не очень хорошо - так как при этом накапливается ошибка (получилось 2 мкс на чтение значения таймера). Надо оценить, насколько она велика, может плюноть на нее.
В принципе за секунду имеем 100 * 4 прерывания - минимум 400 чтений таймера - почти 1 мсек.
На измерении частоты (периода) это не должно сказываться - там время накопления ошибки не превышает периода сигнала, а вот при накоплении статистики (времени работы в диапазоне частот) - может сказаться - время накопления статистики - месяцы.

Утомил?
Может я не прав и зря все это замутил?

[CDT]

О точности измерения частоты опять промолчали.

Если:

Задача - измерять частоту сигналов по 8-ми (пока 4-ем) входам. Частота - от 1 кГц

то

В принципе за секунду имеем 100 * 4 прерывания - минимум 400 чтений таймера - почти 1 мсек.

это не совсем так.

Что бы правильно считать таймер не останавливая надо что бы он не менялся за время чтения.
Минимальная обработка прерывания до считывания как минимум состоит из

Код

push rTmp
in rTmp,sreg
push rTmp
in rTmp,tcntL
in rTmpH,tcntH

, что составляет (10+1...3)*0,125=1,625 мкс, т.е в Вашем случае изменение таймера почти гарантировано (еще не известно, чего туда транслятор напихал).
Простое увеличение К деления прескайлера уменьшит, но не исключит такую вероятность. Соответственно, если во время чтения tcntL в таймере было 01FF, то после чтения tcntH получим 02ff (или 00ff в зависимости от направления счета). Еще противней, если значение будет FFFF
Если до чтения таймера нет переходов (время выполнения кода стабильное) можно проанализировать значение младшего байта и откорректировать считанное значение.

Еще следует учесть, что при почти одновременном приходе нескольких прерываний, за время обработки первого таймер уйдет, пока начнется обработка следующего. Поэтому делитель прескайлера полезно сделать максимально большим (по крайней мере больше времени обработки прерывания). Вот зачем вопрос о требуемой точности.

[prottoss]

О точности измерения частоты опять промолчали.
Если:

Задача - измерять частоту сигналов по 8-ми (пока 4-ем) входам. Частота - от 1 кГц

то

В принципе за секунду имеем 100 * 4 прерывания - минимум 400 чтений таймера - почти 1 мсек.

это не совсем так.
Что бы правильно считать таймер не останавливая надо что бы он не менялся за время чтения.
Минимальная обработка прерывания до считывания как минимум состоит из

Код

push rTmp
in rTmp,sreg
push rTmp
in rTmp,tcntL
in rTmpH,tcntH

, что составляет (10+1...3)*0,125=1,625 мкс, т.е в Вашем случае изменение таймера почти гарантировано.
Простое увеличение К деления прескайлера уменьшит, но не исключит такую вероятность. Соответственно, если во время чтения tcntL в таймере было 01FF, то после чтения tcntH получим 02ff (или 00ff в зависимости от направления счета). Еще противней, если значение будет FFFF
Если до чтения таймера нет переходов (время выполнения кода стабильное) можно проанализировать значение младшего байта и откорректировать считанное значение.

Че то дяденька Вы не в ту степь городите... извиняюсь за выражения.
Вот выдержка из даташита ATmega32 (касается всех AVR с 16-бит ТС): 16-bit Timer/Counter1->

Accessing 16-bit Registers (Page 87): When the low byte of a 16-bit register is read by the CPU, the high byte of the 16-bit register is copied into the temporary register in the same clock cycle as the low byte is read.

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

PS: Си компиляторы об этом знают, то бишь можно делать так: unsigned int cpount = TCNT1, ассемблеру это не ведомо, по этому надо сначала считывать младший байт, за тем старший...

[CDT]

[ Че то дяденька Вы не в ту степь городите... извиняюсь за выражения.
Вот выдержка из даташита ATmega32 (касается всех AVR с 16-бит ТС): 16-bit Timer/Counter1->

Accessing 16-bit Registers (Page 87): When the low byte of a 16-bit register is read by the CPU, the high byte of the 16-bit register is copied into the temporary register in the same clock cycle as the low byte is read.

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

Да, запамятовал. Эти грабли из другого огорода.
Тогда для начала надо выяснить: таймер неправильно читается или обрабатывается?
И продолжить цитату:

Код

It is important to notice that accessing 16-bit registers are atomic operations. If an interrupt
occurs between the two instructions accessing the 16-bit register, and the interrupt
code updates the temporary register by accessing the same or any other of the 16-bit
Timer Registers, then the result of the access outside the interrupt will be corrupted.
Therefore, when both the main code and the interrupt code update the temporary register,
the main code must disable the interrupts during the 16-bit access.

[prottoss]

Тогда для начала надо выяснить: таймер неправильно читается или обрабатывается? И продолжить цитату:

Код

It is important to notice that accessing 16-bit registers are atomic operations...

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

[prottoss]

2 Alechin

Че й то я так и не понял проблемы. Я делаю вот так:

Код

/* системное время */
ULONG g_SysTIME_ms; /* милисекунды */



/* данные датчика */
typedef struct
{
   ULONG Time[2]; /* массив начального и конечного времени  */
   UCHAR Start; /* Индекс стартового времени в массиве времени */
} Pulse_Status_t;

Pulse_Status_t Pulse;



/*****************************************************************************
Обработчик прерывания ТС1 по сравнению TCCR1A
******************************************************************************/
#ifndef __DEBUG__
#pragma optimize = s 9/* оптимизация по скорости */
#endif /* #ifndef __DEBUG__ */



#pragma vector = TIMER1_COMPA_vect
__interrupt void TIMER1_COMPA_isr(void)
{
   g_SysTIME_ms++;
}



/*****************************************************************************
Обработчик прерывания INT0(1,2)
******************************************************************************/
#ifndef __DEBUG__
#pragma optimize = s 9/* оптимизация по скорости */
#endif /* #ifndef __DEBUG__ */



#pragma vector = SPEED_SENSOR_ISR
__interrupt void SPEED_SENS_isr(void)
{
   /* запоминаем текущее время */
    Pulse.Time[Pulse.Start] = MAKEULONG(LOWORD(g_SysTIME_ms),TCNT1);

    /* формируем новый индекс для стартового времени */
    Pulse.Start ^= 1;
}

Таким образом имею время между двумя импульсами, ну а дальше, в основном цикле запрещаю прерывание от INT0 считываю значения START и STOP и поперли дальше. Вместо INT0 можно поставить INT от порта и наворотить еще масса чего, чтоб получить то ж самое от 8-и датчиков

[singlskv]

2 prottoss

Код

#pragma vector = SPEED_SENSOR_ISR
__interrupt void SPEED_SENS_isr(void)
{
   /* запоминаем текущее время */
    Pulse.Time[Pulse.Start] = MAKEULONG(LOWORD(g_SysTIME_ms),TCNT1);

    /* формируем новый индекс для стартового времени */
    Pulse.Start ^= 1;
}

У Вас точно такая же проблемма в коде что и у автора топика.
Что будет если в этой строке MAKEULONG(LOWORD(g_SysTIME_ms),TCNT1) Вы
считаете значение TCNT1=0 ?
А означать это будет переполнение таймера, то есть Вы получите время на
1ms меньше чем реальное.

2 Alechin
Вы попробовали подправленный код из поста #10 ?

[prottoss]

2 prottoss
У Вас точно такая же проблемма в коде что и у автора топика.
Что будет если в этой строке MAKEULONG(LOWORD(g_SysTIME_ms),TCNT1) Вы
считаете значение TCNT1=0 ?
А означать это будет переполнение таймера, то есть Вы получите время на
1ms меньше чем реальное.

Да...на самом деле. Значит в функции, возвращающей значение периода необходимо добавить проверку младшего слова на значение ХХ, если меньше, то прибавлять к конечному результату еще одну 1000...

[singlskv]

2 prottoss
У Вас точно такая же проблемма в коде что и у автора топика.
Что будет если в этой строке MAKEULONG(LOWORD(g_SysTIME_ms),TCNT1) Вы
считаете значение TCNT1=0 ?
А означать это будет переполнение таймера, то есть Вы получите время на
1ms меньше чем реальное.

Да...на самом деле. Значит в функции, возвращающей значение периода необходимо добавить проверку младшего слова на значение ХХ, если меньше, то прибавлять к конечному результату еще одну 1000...

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

Код

#pragma vector = SPEED_SENSOR_ISR
__interrupt void SPEED_SENS_isr(void)
{
   WORD lo = TCNT1;
   WORD hi = LOWORD(g_SysTIME_ms);

   if (((TIFR & (1 << OCF1A)) != 0)&&(lo<1000)) hi++; //  OCR1A/2 =1000

    Pulse.Time[Pulse.Start] = MAKEULONG(hi,lo);
    Pulse.Start ^= 1;
}

[prottoss]

В Вашем случае это будет выглядеть примерно так:

Код

#pragma vector = SPEED_SENSOR_ISR
__interrupt void SPEED_SENS_isr(void)
{
   WORD lo = TCNT1;
   WORD hi = LOWORD(g_SysTIME_ms);

   if (((TIFR & (1 << OCF1A)) != 0)&&(lo<1000)) hi++; //  OCR1A/2 =1000

    Pulse.Time[Pulse.Start] = MAKEULONG(hi,lo);
    Pulse.Start ^= 1;
}

Да нет уж, тогда делать не так. Лучше уж сделать в прерывании три регистровых переменных и последовательно считать в них значение TC1 и TIFR, потом спокойно все это сохранить в память, а уж разгребать потом в процедуре GetState. По крайней мере можно будет знать сколько тактов ошибки - всего 2

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

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

Да уж, решение...

[singlskv]

В Вашем случае это будет выглядеть примерно так:

Код

#pragma vector = SPEED_SENSOR_ISR
__interrupt void SPEED_SENS_isr(void)
{
   WORD lo = TCNT1;
   WORD hi = LOWORD(g_SysTIME_ms);

   if (((TIFR & (1 << OCF1A)) != 0)&&(lo<1000)) hi++; //  OCR1A/2 =1000

    Pulse.Time[Pulse.Start] = MAKEULONG(hi,lo);
    Pulse.Start ^= 1;
}

Да нет уж, тогда делать не так. Лучше уж сделать в прерывании три регистровых переменных и последовательно считать в них значение TC1 и TIFR, потом спокойно все это сохранить в память, а уж разгребать потом в процедуре GetState. По крайней мере можно будет знать сколько тактов ошибки - всего 2

Ну можно конечно TIFR и в память писать, это уже кому как удобно.

А количество тактов ошибки все равно непредсказуемо, например в ситуации
когда одновременно пришло несколько внешних прерываний.
Именно по этой причине идет сравнение (lo<1000).

[prottoss]

А количество тактов ошибки все равно непредсказуемо, например в ситуации
когда одновременно пришло несколько внешних прерываний.
Именно по этой причине идет сравнение (lo<1000).

Почему это не предсказуемо? У нас не предсказуемо значение софтверного слова счетчика до момента, пока мы не считали TCNT и пока мы не проанализировали OCF1A, потому что с периода входа в прерывание INT и до считывания TIFR счетчик мог переполнится, и, естественно, g_SysTIME_ms, тоже должно быть инкременированно. То что будет после считывания TIFR и TCNT1 нас уже не касается, это будущее состояние . То бишь OCF1A является 16-ым разрядом TCNT1 и нулевым разрядом g_SysTIME_ms. Считывая его и счетчик TCNT мы как раз и имеем полныое представление о программно-аппаратном счетчике. И ошибкf будет всего один такт TCNT1 (я ошибся в прошлом посте, сказав, что 2 такта)

[singlskv]

А количество тактов ошибки все равно непредсказуемо, например в ситуации
когда одновременно пришло несколько внешних прерываний.
Именно по этой причине идет сравнение (lo<1000).

Почему это не предсказуемо? У нас не предсказуемо значение софтверного слова счетчика до момента, пока мы не считали TCNT и пока мы не проанализировали OCF1A, потому что с периода входа в прерывание INT и до считывания TIFR счетчик мог переполнится, и, естественно, g_SysTIME_ms, тоже должно быть инкременированно. То что будет после считывания TIFR и TCNT1 нас уже не касается, это будущее состояние . То бишь OCF1A является 16-ым разрядом TCNT1 и нулевым разрядом g_SysTIME_ms. Считывая его и счетчик TCNT мы как раз и имеем полныое представление о программно-аппаратном счетчике. И ошибкf будет всего один такт TCNT1 (я ошибся в прошлом посте, сказав, что 2 такта)

Представте себе что одновременно пришло 2 внешних прерывания.
Выполнятся начнет то, которое приоритетнее. А второе прерывание начнет выполняться
только после окончания первого, то есть для второго прерывания ошибка будет равна
времени работы первого прерывания + время входа во второе прерывание до момента
считывания TCNT.

[prottoss]

Представте себе что одновременно пришло 2 внешних прерывания. Выполнятся начнет то, которое приоритетнее. А второе прерывание начнет выполняться только после окончания первого, то есть для второго прерывания ошибка будет равна времени работы первого прерывания + время входа во второе прерывание до момента
считывания TCNT.

Если суммарное время прерываний больше периода счета счетчика TCNT1, тогда конечно - но это 1 МС! Конечно, если писать прерывания в стиле avr123 ), тада да. А если нет, что тогда? У нас счетчик считает в реалтайме, по этому каждое прерывание получит свое значения и только в одном из прерываний будет установлен 16-ый бит софтварного счетчика - OCF1A. Кроме того, что я это представлял, я еще моделировал различные ситуации с данной проблемой в AVRStudio...

[singlskv]

У нас счетчик считает в реалтайме, по этому каждое прерывание получит свое значения и только в одном из прерываний будет установлен 16-ый бит софтварного счетчика - OCF1A.

Нет, OCF1A будет выставлен во ВСЕХ внешних прерываниях, если за время
выполнения одного прерывания возникнет флаг другого, и т.д.
Дело в том, что у внешних прерываний выше приоритет, и пока
не выполнятся ВСЕ ждущие высокоуровневые прерывания, прерывание таймера по
сравнению не отработает.

[prottoss]

Нет, OCF1A будет выставлен во ВСЕХ внешних прерываниях, если за время
выполнения одного прерывания возникнет флаг другого, и т.д.
Дело в том, что у внешних прерываний выше приоритет, и пока
не выполнятся ВСЕ ждущие высокоуровневые прерывания, прерывание таймера по
сравнению не отработает.

Согласен, если в первом внешнем прерывании выставится флаг OCF1A, то это скажет всем последующим, что софт-слово времени надо скорректировать на 1 - и это будет правильно