Разница М2-М1 всё время где-то 1033-1034, это приемлемо, по крайней мере согласуется с количеством импульсов входной частоты за 1 сек.
А вот разница N2-N1=0, как это может быть? И как можно получить конечную частоту, деля на 0?

Скорее всего, неверный формат вывода. N1, N2, М1, М2 - целые числа формата long, значит формат вывода должен быть %li, а не %i.

Действительно, только %li

Теперь мне не нравится, что ntick1 всё время равен 0, так не должно быть. Хотя N2=ntick2<<16.

И почему такая разница во времени между циклами измерения? Для 12 МГц клока составит 65536*83нс=5,461 мс.

Признавайтесь, куда у вас подключена нога захвата :-)?

И ещё, попробуйте поставить все операторы sprintf после вычисления Fx, возможно они вносят неоднородную задержку в цикл измерения. Не забудьте ввести доп.переменные ntick3, 4... чтобы не затирать начало

А потом перейдём к решению "нюанса".

Входной меандр подключен к Т0. ICP висит в воздухе...

Ну вот, приплыли :-). Не обижайтесь, шутю я, у всех бывает. У вас в ICR1 стоял 0х0000 по умолчанию, вот вы его и считывали.

Нога должна быть физически подключена к генератору и Т0. Иначе захват не будет работать. Далее, таймер0 и захват должны быть настроены на срабатывание от одного фронта, скажем 1-0.

А DDR соответствующих ножек влияет? Подтяжка? Сейчас вывод тини26 подключен напрямую к T0 меге и все. Надо добавить соединение с ICP? (пока что делаю на т.н. Breadboard пластиковая макетка с дырочками).

Да, надо соединить Т0 и ICP с генератором меандра. ICP настроить на ввод, подтяжка не нужна.

Появилась стабильность Значения 1018.8184 - 1018.8183 около того. Наверное, можно списать на погрешность кварца генератора и частотомера, хотя один из вариантов прошлого () периодически показывал значения очень близкие к расчетному +0.00030 или около того.
Однако периодически происходят выбросы 1024.125... К сожалению перешел на другое рабочее место, где самодельный переходник USB-USART не определяется, посему не могу предоставить никакой отладочной информации, сам считываю с дисплейчика.

Ну, я рад за вас. Выбросы происходят из-за того самого "нюанса", который теперь стоит обсудить. Дело в том, что между считыванием ICR1 и считыванием nover есть временной зазор, если прерывание TOV1 попадёт на него, то nover изменится на 1, хотя не должно. Вот такой нюанс. Подумайте сами, как его можно разрешить, завтра обсудим. Кстати, нельзя ли взглянуть на схему генератора струны?

Автогенератор в институте, и схемы от него нет, даже боюсь его развинчивать, но постараюсь что нибудь добыть когда там буду.

Может быть запретить прерывания перед считыванием ICR1?

up: выбросы бывают и в меньшую сторону, около 1013 Гц.

Всё равно между захватом и запретом можем пропустить переполнение tov1 или tov0, хотя и реже.
Расскажу, как работает код
1. Сбросили флаг захвата, это понятно, чтобы будущее содержимое ICR1 и TCNT0 было синхронизировано.
2. Ждём захвата, чтобы текущее содержимое системного времени в TCNT1 защёлкнулось в ICR1 и чтобы содержимое TCNT0 соответствовало защёлкнутому времени.
3-4. Сохраняем содержимое ICR1 и TCNT0 в памяти для дальнейшего использования.
5. Сохраняем старшую часть 32-битного счётчика nover в памяти для дальнейшего использования. Заметьте, я специально оттянул время запоминания nover подальше от захвата п.2, чтобы дать время сработать возможному прерыванию и скорректировать nover.
6. Сохраняем старшую часть 32-битного счётчика mover в памяти для дальнейшего использования. Тут статика, никаких особенностей.

Тут можно посмотреть варианты решения http://electronix.ru/forum/index.php?showtopic=16900

Вот так видимо?

Не понял, по-подробнее можно?

Ваш пост из того топика.

Сообщение отредактировал rezident - Jun 16 2010, 20:48

Ну что, ps1x, есть подвижки? В принципе, я нашёл решение для си, надо проверить...