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

[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 - и это будет правильно

[singlskv]

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

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

Совт-слово можно корректировать прямо в прерывании со сбросом флага OCF1A (TOV1),
тогда в последующих за ним прерываниях корректировка не понадобится.

P.S только имейте ввиду, что сейчас кое-кто придет и скажет что так делать низя...

[prottoss]

Совт-слово можно корректировать прямо в прерывании со сбросом флага OCF1A (TOV1), тогда в последующих за ним прерываниях корректировка не понадобится.
P.S только имейте ввиду, что сейчас кое-кто придет и скажет что так делать низя...

Мне все равно, кто счас придет... Он не пуп земли, и послать его далеко мне очень легко...

По поводу корректировки в прерывании - я сторонник делать все что можно за пределами прерывания, а прерывание должно быстро отработать и освободить место другому, что бы не было пауз в 1 мс)))...

Дак я не понял, с моей идеей Вы согласны, или нет? Так, как я предлагаю - и волки сыты и овцы целы). Дело в том, что у меня счас тоже проект, в котором МК должен мерить импульсы от датчика скорости((( В ТЗ - от ИНТ0 и с точностю десятки микросекунд. А ТС1 выполняет роль системных часов. Вот и изгаляюсь тоже. Но похоже что, то что я придумал, работает - опять же, если суммарное время поступивших внешних прерываний не превысит 1 мс...

И я не пойму, а что делать низя? Что вы имели в виду?

[singlskv]

Мне все равно, кто счас придет... Он не пуп земли, и послать его далеко мне очень легко...

Он и так далеко, Oxford UK

По поводу корректировки в прерывании - я сторонник делать все что можно за пределами прерывания, а прерывание должно быстро отработать и освободить место другому, что бы не было пауз в 1 мс)))...

Ну дык это всего лишних тактов 10-15

Дак я не понял, с моей идеей Вы согласны, или нет? Так, как я предлагаю - и волки сыты и овцы целы).

Вы о сохранении TIFR в памяти или о сохраниени TCNT и TIFR в регистрах в соседних командах ?
Если первое, то согласен, только сравниваем младшее слово с 1000 при коррекции.
А если второе, то ИМХО это нам ничего не дает.
Представте себе что во время выполнения не относящегося к нашему делу прерывания
происходит запрос на прерывание от таймера, а затем через какое-то время(пока еще
не закончилось другое прерывание) происходит запрос на прерывание INT.
Когда закончится другое прерывание, первым будет обработанно INT, при этом
значение в TCNT будет уже довольно большим, а флаг OCF1A, будет выставлен.
А теперь другая ситуация.
Представте себе что во время выполнения не относящегося к нашему делу прерывания
происходит запрос на прерывание INT.После окончания прерывания, начнется обработчик INT,
но при считывании значений мы получили TCNT=1999 и выставленный флаг OCF1A.

В каком из этих двух вариантов Вы будете производить коррекцию, а в каком нет ?

Может быть все-таки так надежнее:
if (((TIFR & (1 << OCF1A)) != 0)&&(lo<1000)) hi++; // OCR1A/2 =1000
Кстати, точно такуюже проверку мы можем делать и с данными сохранеными в памяти.

Дело в том, что у меня счас тоже проект, в котором МК должен мерить импульсы от датчика скорости((( В ТЗ - от ИНТ0 и с точностю десятки микросекунд. А ТС1 выполняет роль системных часов.

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

И я не пойму, а что делать низя? Что вы имели в виду?

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

[prottoss]

Вы о сохранении TIFR в памяти или о сохраниени TCNT и TIFR в регистрах в соседних командах ?
Если первое, то согласен, только сравниваем младшее слово с 1000 при коррекции.
А если второе, то ИМХО это нам ничего не дает.

Я о сохранении TIFR и TCNT в соседних командах , а потом в памяти - дальнейший анализ в основном цикле

Представте себе что во время выполнения не относящегося к нашему делу прерывания
происходит запрос на прерывание от таймера, а затем через какое-то время(пока еще
не закончилось другое прерывание) происходит запрос на прерывание INT.
Когда закончится другое прерывание, первым будет обработанно INT, при этом
значение в TCNT будет уже довольно большим, а флаг OCF1A, будет выставлен.

Нам важно, если делать, как я, только одно значение TCNT - 1999. Если флаг OCF1A - установлен, мы будем в любом случае корректировать софт-слово, если, при этом значение счетчика 1999, мы будем корректировать (в сохраненной переменной) - устанавливать в 0

А теперь другая ситуация.
Представте себе что во время выполнения не относящегося к нашему делу прерывания
происходит запрос на прерывание INT.После окончания прерывания, начнется обработчик INT,
но при считывании значений мы получили TCNT=1999 и выставленный флаг OCF1A.

То же самое, что и выше



Вот код, который я набросал для процедуры считывания периода:

Код

UINT SPEED_SENS_GetState(void)
{
   /* запрещаем прерывание */
   GICR &= ~SPEED_SENSOR_ISR_ENABLE;

    /* считываем значения */
    register ULONG stop = Pulse.Time[Pulse.Start ^ 1];
    register ULONG start = Pulse.Time[Pulse.Start];
    register UCHAR tifr_stop = Pulse.TIFR_reg[Pulse.Start ^ 1];
    register UCHAR tifr_start = Pulse.TIFR_reg[Pulse.Start];

    /* разрешаем прерывание */
    GICR |= SPEED_SENSOR_ISR_ENABLE;

    /* корректируем результат по состоянию флага OCF1A
    на момент считывания значений времени */
    if(tifr_stop & (1 << OCF1A))
    {
       stop += 65536;
        if(SYSTIMER_COMPARE_VAL == LOWORD(stop))
           stop -= SYSTIMER_COMPARE_VAL;
    }
    if(tifr_start & (1 << OCF1A))
    {
       start += 65536;
        if(SYSTIMER_COMPARE_VAL == LOWORD(start))
           start -= SYSTIMER_COMPARE_VAL;
    }

    /* считаем разность (STOP - START)*/
    stop = (LOWORD(stop) >> 1) + /* преобразуем в мкс */
       (HIWORD(stop) * 1000);
start = (LOWORD(start) >> 1) + /* преобразуем в мкс */
       (HIWORD(start) * 1000);

    /* преобразуем в Герцы и возвращаем */
    return (UINT)(((LONGLONG)10000000) / abs(stop - start));
}

Дело в том, что у меня счас тоже проект, в котором МК должен мерить импульсы от датчика скорости((( В ТЗ - от ИНТ0 и с точностю десятки микросекунд. А ТС1 выполняет роль системных часов.

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

Не факт, что завтра мне не дадут задание довесить еще один датчик... или 8 на весь порт...

[singlskv]

Код

UINT SPEED_SENS_GetState(void)
{
   /* запрещаем прерывание */
   GICR &= ~SPEED_SENSOR_ISR_ENABLE;

    /* считываем значения */
    register ULONG stop = Pulse.Time[Pulse.Start ^ 1];
    register ULONG start = Pulse.Time[Pulse.Start];
    register UCHAR tifr_stop = Pulse.TIFR_reg[Pulse.Start ^ 1];
    register UCHAR tifr_start = Pulse.TIFR_reg[Pulse.Start];

    /* разрешаем прерывание */
    GICR |= SPEED_SENSOR_ISR_ENABLE;

    /* корректируем результат по состоянию флага OCF1A
    на момент считывания значений времени */
    if(tifr_stop & (1 << OCF1A))
    {
       stop += 65536;
        if(SYSTIMER_COMPARE_VAL == LOWORD(stop))
           stop -= SYSTIMER_COMPARE_VAL;
    }
    if(tifr_start & (1 << OCF1A))
    {
       start += 65536;
        if(SYSTIMER_COMPARE_VAL == LOWORD(start))
           start -= SYSTIMER_COMPARE_VAL;
    }

    /* считаем разность (STOP - START)*/
    stop = (LOWORD(stop) >> 1) + /* преобразуем в мкс */
       (HIWORD(stop) * 1000);
start = (LOWORD(start) >> 1) + /* преобразуем в мкс */
       (HIWORD(start) * 1000);

    /* преобразуем в Герцы и возвращаем */
    return (UINT)(((LONGLONG)10000000) / abs(stop - start));
}

Ну так вроде будет работать,
просто сравнение в прерывании с cерединой диапазона счетчика
таймера - это более общий подход, который работает и в варианте
использования ICP1 и прерывания захвата таймера.
Только вот это я недопонял:

Код

    if(tifr_stop & (1 << OCF1A))
    {
       stop += 65536;
        if(SYSTIMER_COMPARE_VAL == LOWORD(stop))
           stop -= SYSTIMER_COMPARE_VAL;
    }

Почему мы добавляем 65536, а вычитаем только 1999
Хотя это конечно детали.

Не факт, что завтра мне не дадут задание довесить еще один датчик... или 8 на весь порт...

Ну тогда Вам и автору данного топика следует рассмотреть следующий вариант:
1. Подключаем датчики к соответствующим INTx.
2. Каждый пин INTx через диод подключаем к ICP1.
3. В каждом прерывании INTx считываем значение ICR1 вместо TCNT1.
4. Делаем корректировку по середине диапазона(можно в обработчике INTx, а можно и
в основном цикле, кому как больше нравится)

Понятно, что при перекрытии прерываний считанное из ICR1 значение будет отличаться
от реального момента прерывания, но:
1. Такой подход даст нам более надежный имунитет от "других прерываний"
2. Общая (средняя) ошибка вычисления длительностей при
перекрытии прерываний существенно уменьшится.