Немного изменил код, счетчик не сбрасывается, а постоянно накапливается. Результатом измерения будет разность между двумя захватами. А в такой реализации 8 бит может быть недостаточно.
Таймер (TCNT) конечно можно корректировать в обработчике CAPT, но это IMHO будет некрасивое решение.

Вроде нормальный пример. Тока непонятно зачем R0 и R1 используются.

Кстати, то что прерывание захвата приоритетней переполнения это хорошо. Иначе гемору было бы больше.


Хотя... постойте... В прерывании OVR инкрементируются R3:R2, которые потом копируются в R7:R6. Однако при отложенном прерывании OVR почему-то у Вас инкрементируется не R7:R6, а R4 и далее по списку.

Сообщение отредактировал GetSmart - Jun 2 2006, 23:08

???

О чем вы, господа? Забыли, что внутри проца есть еще синхронизация пина? т.е. 1-2 такта задержки вам обеспечено.. Что больше необходимой 1мкс (при тактовой 1МГц).

О чём вы, господин? Задержка всегда постоянная. И для двух фронтов она компенсирует друг друга.

Э, да, вспылил, был неправ

Ой.. и правда.
Успел отредактировать ;>

А чем вызвано ограничение по кварцу - 1 МГц? (Или я проглядел?)
При расширении разрядности таймера до 24-32 разрядов (да хоть до 64-х! ) увеличение тактовой до 8-16 МГц резко увеличит точность при сокращении времени измерения.

defunct
Ну ёкарный бабай...
Ещё нужно заменить "tst R1; brne ..." на "tst R5; brmi ..."
Поясню почему. Дело в том, такая конструкция допускает ещё другие, длительные прерывания (до 32к тактов). При этом конечно периоды импульсов должны быть ещё больше. Вобщем мне кажется, что так более логично и идеальнее алгоритм.

Не понимаю как Вам удаётся менять посты без надписи "отредактировано"?!

R1 на R5 заменил!
Насчет brmi - на любителя, но я все же предпочитаю brne. 256 тактов и так предостаточно. Все таки задача мерять интервалы времени с точностью 1mks, а не принимать антикризисные меры по оживлению программы с курса ...123 в котором задержка в обработчике прерывания на 20ms считается нормальным явлением. Длительные прерывания - от лукавого, никогда такого не делаю и никому не советую.


Полная правка?

ps: извиняюсь за мою невнимательность и небрежность при написании примера. GetSmart пожалуйста, если там еще что-то заметите, просто внесите Ваши исправления и запостите отдельным сообщением. (а то как-то неудобно уже постить на эту тему и бесконечно править 10 строчек кода)

все хорошо ребята - мона конечно извращаться с АВР с аппаратным захватом, но тут парень был прав, если в результате возникнет несколько прерываний, то не факт, что все там работает аппаратно, а вы это все понимает - паралельно, но там не все параллельно, проверить просто - забейте проц в постоянное прерывание, а лучше создайте множественные случаи прерывания, проц может просто умереть, у меня так было, и не из-за программы, а потому что сбивалась декодировка кодов внутри этой продвинутой РИСК-архитектуры.

Да, еще раз задам вопрос, почему выбрана частота - 1МГц, может парень просто хочет пользовать калиброванную RC-цепочку в качестве задатчика частоты .

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

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

Кто не согласен со мной, спорить не буду - у каждого своя правда и я с каждой по своему согласен

Да кстати в продолжение темы, а знаете зачем у кварца при контроллерах с двух сторон кондерчики стоят, и почему для разных частот надо брать разную емкость (в пкФ), и не зависит ли от этой емкости частота конечная. Такой вопрос моему другу на беду задал залетный председатель комиссии на защите магистерской работы (нашел что у магистра спрашивать) , ну вообщем парень конечно же не ответил, как в принципе и большая часть нашего профессорско-преподавательского состава , а ответ то прост, но он нам просто не нужен в большинстве случаев, сказано надо ставить, значит надо ставить, начинаем думать только кода кто то раком запаял кандеры вместо пикофарад микрофарады или нанофарады, или еще какая то гадость, или как в этом случае хотим получить сумасшедшую точность измерения временных интервалов с таким вот кварцевым генератором, часть схемы которого реализован в дешевом микроконтроллере как Атмега8 (у нас он стоит чуть больше 1 евро), плюс ширпотребовский кварц на 1МГц, и сомнительные кондеры, хотя я обычно ставлю NPO, они очень стабильны во времени и температуры и там все нормально, но многие ставят X7R или X5R. Честь и хвала им (стоимость то одинаковая).

И вот все равно не понимаю я...

Предположим, в этом примере добавили мы const1 в прерывании OVF1 и тут грянуло прерывание CAPT. Что получится?

У меня ситуация, когда память Тини13 (1кь) заполнена на 960 байт, при этом ОЗУ 64 байт и его мало. Та-же прога, но адаптированная к Меге8 работает без проблем (512 байт ОЗУ). А TIFR один раз переполняется и сбросить его можно только принудительно записав в его единицу свою единицу (видать триггер там есть)! Просто присваиваем разряду 1 в дополнение к той, что там есть уже.

Уход в процентах не зависит от делителя. Вот уход в герцах!!! Это документируемо и полезно в плане утверждения документации. Иначе ваша погрешность - обнять и плакать! Вы поняли о чем я?