Ничего не понял, поясните. Здесь никакой идеи, просто проверка содержимого r5:r4 на 0, только 0 может показать, что был перенос.

Обратимся к посту №1 данной темы. Автор пишет:
Иными словами, опорный генератор не должен иметь отклонение частоты относительно мировых эталонов более 1/(N*1000000), где N -количество секунд в измеряемом интервале (шумы генератора здесь не рассматриваем). Получить такую точность с помощью простого генератора на кварце - сама по себе нетривиальная задача.
Когда же мы говорим о временнОм разрешении, то, как Вы верно заметили, под этим подразумевается погрешность метода. Она является абсолютной величиной, и не зависит от измеряемого интервала времени.
Суммарная ошибка в первом приближении определяется двумя этими факторами.

Нет, не поможет. Кратковременная нестабильность дополнительно ухудшает точность опорного генератора, хотя и является величиной "второго порядка малости".

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

Да, верно. Придётся делать контрольные замеры, можно даже с помощью того же таймера.
Только приемлемо ли это для автора темы?

Я же написал, что там может быть и 10 и 100 и при этом быть перенос. Что Вы не поняли? Что в системе может быть больше чем эти два прерывания? Вы хоть поняли как предыдущая версия программы работала?

Вы не учли вот эту проверку:

которая происходит перед "in AL, TIFR"

Вот это помагает избежать данной проблеммы:


или начало ....
Ну например если мы хотим измерять длительность единичного импульса на входе.

subi на регистрах R0-R15 ?! ню...ню...

А не так, случайно:



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

Сообщение отредактировал Леонид Иванович - Oct 9 2006, 20:16

Павезло так павезло

Как там (в r5-r4) может быть 10 или 100 и быть перенос? Его не может быть или я ничего не понимаю. Перенос может быть, если только в ICR1H-ICR1L (читай r5-r4) было 0хFFFF, а потом стало 0х0000. Никак не 10 или 100.

Ладно, отбросим предрассудки и недоразумения(:-), и начнем сначала.

1) Есть переменная в r7-r6-r5-r4, показывающая время. Содержимое регистров r5-r4 отражает содержимое аппаратных регистров захвата, по сути текущее время таймера1 на конец (или начало, не суть) измеряемого интервала. Каждые 65536 мкс содержимое таймера1 обнуляется и возникает перенос, который программно учитывается в регистрах r7-r6. Согласны?

2) Пойдем дальше. Как только возникает конец интервала, тут же происходит захват и мы имеем точное время записи, копируя содержимое ICR1L, ICR1H в r5-r4, и содержимое r3-r2 в r7-r6. Согласны?

3) Однако, если захват произойдет на 65536 микросекунде нашего таймера, возникнет перенос, который еще не учтен в r3-r2, и следовательно, в r7-r6. Как его учесть? Использовать ТЕКУЩИЙ аппаратный перенос от таймера1 НЕЛЬЗЯ, т.к. он никакого отношения к времени захвата не имеет. Согласны?

4) Наличие 0х0000 в r5-r4 означает, что в момент захвата произошло переполнение таймера1, и что перенос следует учесть в r7-r6. Согласны?

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


Я-то понял, а вот вы похоже нет, хотя вы один из авторов(:-). И при чем здесь количество прерываний?

Именно так и надо, так строже, и надёжнее - труднее ошибиться. Но прынцип тот же самый - вычитать минус 1, вместо того, чтобы прибавлять 1. Что очевидно лучше, чем регистровое вычитание, поскольку освобождаются два регистра сonst0 и сonst1.


Просто механически повторил ваш код, рука, так сказать, пронесла. А вы что, рады технической описке? Мелочь отметили, а главное пропустили, что не надо впустую инициализировать два регистра, да и сами регистры не нужны? Я вот на форуме стараюсь показать лучшее, что знаю сам, и поучиться лучшему у других.

Если использовать subi, то мы занимаем под прерывание дефицитные R16-R32, а их всегда мало.
А вот R0-R15 как раз часто бывает в избытке, так что 2 лишних регистра const0 и const1
не очень жалко

Чудак-человек, я согласен, что практически ваша программа будет работать, хотя логика запутанная(:-).

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

Пусть одновременно возникло два прерывания: захват и, другое, более приоритетное.
Пусть на момент захвата ICR1=00FF. Приоритетное прерывание начнет обрабатываться первым и пусть оно обрабатывается, скажем, 270 мкс. Поскольку таймер работает параллельно и независимо от приоритетного прерывания, возникнет OVF1=1.

Приоритетное прерывание закончило работу, начинает работать ваше прерывание по захвату.
Оно проверяет r5=0? Да. Проверяет далее OVF1=1? Да. И корректирует содержимое r3-r2 и, соответственно, r7-r6. А это неправильно. Как-то так.

И последний интересный вопрос, ответ на который я пока не знаю. Если прерывания TIM1_OVF и TIM1_CAPT возникли одновременно, и стало выполняться прерывание TIM1_CAPT, а прерывание TIM1_OVF дожидается своей очереди, вы уверены, что можно его снять, сбросив TOV1? В документации ничего не нашел по этому поводу.

ICR1=00FF
TCNT1=00FF
пусть прошло 270мкс =010E время обработки другого прерывания
ICR1=00FF
TCNT1=00FF+010E=020D
r5=0 ? Да.
OVF1=1 ? нет
итого: r3-r2 не корректируем

фраза из даташита:

TOV1 is automatically cleared when the Timer/Counter1 Overflow Interrupt Vector is
executed. Alternatively, TOV1 can be cleared by writing a logic one to its bit location.

На самом деле Вы привели просто неудачный пример.
Проблемма с длинным прерыванием действительно есть, и выглядит она вот так:

Int0: <---длинное прерывание >256 тактов
...............
TCNT1=0 <--- здесь переполнение TOV1=1
..............
ICR=0101h <--- здесь захват
.............
reti

CAPT: <--- сюда попадаем сразу после Int0
..............
in r4,ICR1L
in r5,ICR1H <--- r5=01 не корректируем, а зря
<--- TOV1=1

Хотел бы отметить два факта. Во-первых просто поразительно насколько у людей разные интересы. На мой взгляд совсем незначительная проблема вызвала серьёзный интерес и бурную деятельность.

Во-вторых. Хотя я (как все) и применяю вычитание вместо сложения, тем не менее я делаю ещё так. Один из регистров в младшей области обзываю Vol0 и очищаю его. Ну и дальше работаю с ним. Это помогает в разных ситуациях. типа sts xxx,Vol0... inc/adc ... add Zl,wl/adc Zh,Vol0 ...
Где-то (по моему в PIC) подобное на уровне архитектуры применяется.