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

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

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

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

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

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

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

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

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

Ну дык это всего лишних тактов 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
Кстати, точно такуюже проверку мы можем делать и с данными сохранеными в памяти.


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

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

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

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

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



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





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

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

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

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

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

Хм, я же объясняю, если флаг установлен, к СТАРШЕМУ слову прибавляем 1

Если число в TCNT = 1999, TCNT = 0


Хрен редьки не слаще: Во первых диоды денех стоять, во вторых ловить флаг переполнения хардварного счетчика тоже нада

Да, я забыл что у Вас так хитро организован счетчик.


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

Вот-вот, к тому же плата уже давно готовая и в серии...

Попробуйте защелкивать значение таймера в ICP регистр. не прочитал всю тему было об этом уже.

Сообщение отредактировал ARIM - Nov 8 2006, 07:06

Каскадировать два 8-ми битных и один 16-ти битный таймеры. получим аппаратный 32-х разрядный.

...да, а если они все у Вас заняты разбейте плату молотком...

или возьмите LPC21xx.

Вчера проверил все то, что выкладывал выше на трех ИНТах, работает как часы, погрешность (я не использовал FLOAT в вычислениях) +-1 Гц.
А что автор топика примолк, решил проблемцу так же, как я предлагал, или еще че получше напридумывал?