Форум разработчиков электроники ELECTRONIX.ru > Измерение временных интервалов

singlskv

Oct 9 2006, 16:34

Цитата(=GM= @ Oct 9 2006, 17:59)

Хочу немного покритиковать программу.

1) От возникновения прерывания захвата до команды "in AL,TIFR" может пройти от 12 до 15 МЦ, т.е. достаточно много времени, чтобы произошел перенос от переполнения, следовательно, возможна ошибка в определении времени.

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

Код

    in    R5, ICR1H
    tst   R5
    brne  _do_not_correct_result

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

Цитата

2) Вполне возможно, что если прерывания TIM1_OVF и TIM1_CAPT возникли в течение указанного периода, то прерывание TIM1_OVF выполнится после TIM1_CAPT и ПОВТОРНО скорректирует результат в r3-r2 (не уверен на все 100, надо проверять).

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

Код

out TIFR, AL

Цитата

3) Вход в прерывание TIM1_CAPT означает конец интервала измерения ...

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

Цитата

Ну и последнее, в подобных случаях предпочитаю использовать конструкцию

Код

subi r2,-1 ;
sbci r3,-1 ;

Вместо эквивалентной

Код

add R2,сonst1 ;
adc R3,сonst0 ;

что очевидно лучше, поскольку освобождаются два регистра сonst0 и сonst1.

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

Леонид Иванович

Oct 9 2006, 20:15

Цитата

Ну и последнее, в подобных случаях предпочитаю использовать конструкцию

Код

subi r2,-1 ;
sbci r3,-1 ;

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

Код

subi r16,low(-1)
sbci r17,high(-1)

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

GetSmart

Oct 9 2006, 20:37

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

=GM=

Oct 10 2006, 10:43

Цитата(GetSmart @ Oct 9 2006, 15:24)

Цитата(=GM=)

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

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

Как там (в 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. Согласны?

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

Цитата

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

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

=GM=

Oct 10 2006, 11:04

Цитата(Леонид Иванович @ Oct 9 2006, 19:15)

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

Код

subi r16,low(-1)
sbci r17,high(-1)

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

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

Цитата(singlskv @ Oct 9 2006, 15:34)

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

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

singlskv

Oct 10 2006, 11:19

Цитата(=GM= @ Oct 10 2006, 15:04)

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

Цитата(singlskv @ Oct 9 2006, 15:34)

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

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

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

singlskv

Oct 10 2006, 11:49

Цитата(=GM= @ Oct 10 2006, 14:43)

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

Код

                          <---- ICR1=FFFF  момент захвата
                          <---- TCNT1=FFFF
TIM1_CAPT:
                              <---- ICR1=FFFF начало обработки прерывания
                              <---- TCNT1=5
                              <---- TOV1=1
    in    _Sreg,SREG
    in    R4, ICR1L     <---- R4=FF
    in    R5, ICR1H     <---- R5=FF
    tst   R5                <---- R5==0 ???
    brne  _do_not_correct_result <---- переходим без коррекции
    in    AL, TIFR
    andi  AL, (1 << TOV1)
    breq  _do_not_correct_result
    out   TIFR, AL
    add   R2, Const1
    adc   R3, Const0
_do_not_correct_result:
    mov   R6, R2
    mov   R7, R3
    out   SREG,_Sreg
    reti

=GM=

Oct 10 2006, 12:51

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

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

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

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

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

singlskv

Oct 10 2006, 13:23

Цитата(=GM= @ Oct 10 2006, 16:51)

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

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

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

Цитата

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

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

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

SasaVitebsk

Oct 10 2006, 13:25

Цитата(singlskv @ Oct 10 2006, 14:19)

Цитата(=GM= @ Oct 10 2006, 15:04)

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

Цитата(singlskv @ Oct 9 2006, 15:34)

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

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

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

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

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

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

smk

Oct 10 2006, 14:09

По моему скромному мнению, мне очень понравилась идея, ссылка на которую дана в этой теме. Ну а по своему опыту скажу, что во время такого измерения следует допускать только те операции, которые собственно не счет микросекунд, что занимают не более частота кварца/1Мгц - 1 тактов. Отладку такой проги можно делать только в AVR Studio. Одним таймером считать другой.

GetSmart

Oct 10 2006, 14:14

Ой-Ой-Ой.

Ладно, господа. Я вас примирю. Используем только const0, в которой храним -1. И уже sub/sbc с этой константой и младшими 16 регистрами. Итого теряется толька одын регистр.

=GM=
Читайте внимательно ПДФ-ы. Там всё есть. При "ручном" сбросе TOV1 прерывание по переполнению уже не обрабатывается.

Теперь про ICR1H/ICR1L объясняю в последний раз для особо трудных. В системе есть высокоприоритетное прерывание скажем длительностью 100 мкс. Вдруг оно возникает когда в TIMER=FFE0h. Соответственно оно закончится когда в таймере будет 0044h. Однако (случайно так) захват происходит когда в таймере 0020h. Что мы видим? Что Вы видете? ICR1H/ICR1L = 0020h. TOV1 = 1. Вас это удивляет? Как только высокоприоритетное прерывание заканчивается, то прерывание по переполнению не выполняется (!), а выполняется прерывание по захвату и обнаруживает то, что я уже написал. Вообще, я бы анализировал не совпадение с нулём регистра ICR1H, а только его старший бит. Таким образом максимально расширив диапазон допустимых высокоприоритетных прерываний.

Ещё вопросы?

ЗЫ. singlskv forever!

GetSmart

Oct 10 2006, 14:33

Цитата(=GM=)

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

Таких описок у Вас тут уже немерено

Не, мы не особо рады. Просто перед начинанием споров и критики вы должны были полностью разобраться в уже написанном коде и только когды вы полностью (!) поняли там каждую команду вы имеете право вносить свои предложения по упрощению. Если это послужит вам уроком, то мы думаю будем таки рады

Цитата(=GM=)

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

Это наверное тоже техническая описка? Только возникла она наверно ещё глубоко в мыслях. Мозг как бы обманул сам себя.

PS Без обид. Это я пока по-доброму критикую.

=GM=

Oct 10 2006, 14:36

Цитата(SasaVitebsk @ Oct 10 2006, 12:25)

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

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

Проблема не такая уж и незначительная. Постоянно натыкаюсь в сети на проекты частотомеров, цифровых шкал, где разработчики бездумно выставляют секундный интервал и подсчитывают количество приходящих импульсов, не пытаясь выжать максимальную точность. На 1 кГц они могут получить ТРИ значащих цифры!

Исходя из собственного опыта, скажу, что на 16-мегагерцовой атмеге можно измерить частоту до 3.2 МГц с точностью 0.2 Гц, т.е. с относительной погрешностью порядка 6Е-8. Причем на голой атмеге, не используя всяких прибамбасов в виде фпга и т.д. а если на входе поставить пять D-триггеров, то можно мерить 100 МГц с точностью 8 Гц. Получше, чем у некоторых промышленных частотомеров, как вам такая перспектива, э?

Цитата(SasaVitebsk @ Oct 10 2006, 12:25)

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

Я тоже так иногда делаю. Но чаще использую регистры временного хранения. Занес константу, сделал что-то и забыл.

singlskv

Oct 10 2006, 16:20

Еще подправил код:
- заменил на одну константу ConstFF и sub/sbc
- за счет этого ввел новую константу _TOV1 которая является флагом TOV1 в TIFR
- что позволило избавиться от AL==R24 в прерывании TIM1_CAPT
- подправил код для длинных прерываний, сдвинул в "середину" ICR1H >=7F

Код

.def  ConstFF = R8
.def  _TOV1   = R9
.def  _Sreg   = R10
....
    clr   ConstFF
    dec   ConstFF
    ldi   R16, (1 << TOV1)
    mov   _TOV1, R16
....

; Input Capture:
TIM1_CAPT:
    in    _Sreg,SREG
    in    R4, ICR1L
    in    R5, ICR1H
    mov   R7, ConstFF
    lsr   R7
    cp    R5, R7
    brsh  _do_not_correct_result
    in    R6, TIFR
    and  R6, _TOV1
    breq  _do_not_correct_result
    out   TIFR, R6
    sub   R2, ConstFF
    sbc   R3, ConstFF
_do_not_correct_result:
    mov   R6, R2
    mov   R7, R3
    out   SREG,_Sreg
; <-- 32bit Result R7-R6-R5-R4 (MSB R7)
    reti

; Timer Overflow:
TIM1_OVF:
    in    _Sreg,SREG
    sub   R2, ConstFF
    sbc   R3, ConstFF
    out   SREG,_Sreg
    reti

Если кто найдет баги, телеграфируйте ...

=GM=

Oct 10 2006, 17:15

Цитата(singlskv @ Oct 10 2006, 15:20)

Еще подправил код:

Что-то мне разонравилось измерение по прерыванию. Наверное, надо делать без всяких прерываний, в фоне(:-).

singlskv

Oct 10 2006, 17:52

Цитата(=GM= @ Oct 10 2006, 21:15)

Мне кажется, зря вы здесь используете повторно r7, r6. Вдруг основная программа не успеет их обработать, а уже возникнет новое прерывание TIM1_CAPT. Понятно, что хочется съэкономить, но такая экономия может выйти боком(:-)

Нет, c R6,R7 там все в порядке.
вот этот код будет выполнен в конце прерывания TIM1_CAPT при любых условиях:

Код

mov R6,R2
mov R7,R3

так что здесь, ИМХО все ОК.

singlskv

Oct 10 2006, 18:06

Цитата(=GM= @ Oct 10 2006, 21:15)

Цитата(singlskv @ Oct 10 2006, 15:20)

Еще подправил код:

Что-то мне разонравилось измерение по прерыванию. Наверное, надо делать без всяких прерываний, в фоне(:-).

Вам больше не нравятся прерывания ?
- Вы просто не умеете их правильно готовить (с) (не мой)

GetSmart

Oct 10 2006, 20:19

Цитата(singlskv)

Код

    in    R5, ICR1H
    mov   R7, ConstFF
    lsr   R7
    cp    R5, R7
    brsh  _do_not_correct_result

Маленькое упрощение:

Код

    in    R5, ICR1H
    tst   R5
    brmi  _do_not_correct_result

Цитата(=GM=)

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

Вы уже наконец поняли о чём я говорил? Если да, то ничего не хотите добавить к этому?

Цитата(=GM=)

Что-то мне разонравилось измерение по прерыванию. Наверное, надо делать без всяких прерываний, в фоне(:-).

Особенно если учесть, что раньше был другой текст

singlskv

Oct 10 2006, 20:58

[quote name='GetSmart' date='Oct 11 2006, 00:19' post='163416']
[quote=singlskv]

Код

    in    R5, ICR1H
    mov   R7, ConstFF
    lsr   R7
    cp    R5, R7
    brsh  _do_not_correct_result

[/quote]Маленькое упрощение:

Код

    in    R5, ICR1H
    tst   R5
    brmi  _do_not_correct_result

Ой... , Вы правы (вот и я научился чему то новому в этом топике

)
Уже не помню почему, но у меня стойко закрепилось в мозгу, что после
tst Rxx нужно использовать breq/brne, jz/jnz, и т.д.
Спасибо...

defunct

Oct 10 2006, 22:32

Цитата(SasaVitebsk @ Oct 10 2006, 16:25)

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

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

Дык задача многосторонняя, от того и интерес. ;>
В системе с одноуровневым КП и таймером с "окном" ~1-10% от интервала измерений, обслуживать несколько прерываний и при этом не терять точность. Нельзя сказать, что это тривиальная задача для AVR.

Ну и плюс простота кода - не нужно долго вникать.

=GM=- это конечно здорово, что вы попытались упростить код, правильно мыслите, однако прислушайтесь к совету GetSmart - перед всякой критикой нужно полностью разобраться в том, что уже есть, иначе критика вызывает улыбку.

GetSmart
Я таки все так же против увеличения латентности других прерываний и использования проверки последнего бита. 256 тактов "запаса" еще как-то понятно, а вот на что может понадобиться больше - уже нет. Тем паче "флагманские" прерывания (которые могут потребовать относительно длительной обработки) обладают более низким приоритетом чем T1_CAPT.
Половина таймера это на самом деле очень много. И если в системе есть обработчики такой длительности ~32k тактов, то это значит, что мы можем ошибиться уже в обратную сторону - "через круг таймера".

GetSmart

Oct 10 2006, 23:11

defunct
Скучали тут без Вас

А почему все думают, что у АВР одноуровневой КП? Может уже я чего-то не знаю?

Цитата(defunct)

Я таки все так же против увеличения латентности других прерываний и использования проверки последнего бита.

Так... Вы - против, я - за. Что будем с этим делать?
Ограничение только в том, что любое допустимое в системе прерывание обязано занимать время меньшее, чем минимум времени между двумя исследуемыми импульсами. А уж сколько оно будет на практике, 100 мкс или 30 мс - это должен учитывать разработчик конкретного устройства. Эта программа даёт ему такую возможность вплоть до 32 мс.

Поясните, плиз, как можно ошибиться уже в обратную сторону?

defunct

Oct 10 2006, 23:14

Цитата(GetSmart @ Oct 11 2006, 02:01)

А почему все думают, что у АВР одноуровневой КП? Может уже я чего-то не знаю?

А почему "думают"? ;>
Об этом в ДШ сказано.

When an interrupt occurs, the Global Interrupt Enable I-bit is cleared and all interrupts
are disabled. The user software can write logic one to the I-bit to enable nested interrupts.
All enabled interrupts can then interrupt the current interrupt routine. The I-bit is
automatically set when a Return from Interrupt instruction – RETI – is executed.
....
When the AVR exits from an interrupt, it will always return to the main program and execute
one more instruction before any pending interrupt is served.

Если к примеру сравнить с C51, то в нем предусмотрено два уровня, L0, L1.
Когда выполняется обработчик L0, то другие прерывания с приоритетом L0 не могут быть вызваны, зато прерывание с приоритетом L1 - может. В AVR такого нет по определению, а установка флага I внутри обработчика прерывания, можно назвать не иначе как "глюкодром"

, ведущий к deadlock основной программы.

Цитата

Так... Вы - против, я - за. Что будем с этим делать?

Ничего

оставим как есть - 2 варианта.
Не бывает единственно верных решений.

Цитата

Поясните, плиз, как можно ошибиться уже в обратную сторону?

по тактам начиная с такта i:

i - переход на длительный обработчик (пусть будет Uart0) TCNT1 = 0x7FFE
i + 0x1 - срабатывание захвата TIF1 = 1, ICR = 0x7FFF, TOV1 = 0.
i + 0x7FF8 - Uart0 обработка завершена выполнение RETI (4 такта), TCNT1 = FFF6, TOV1 = 0
i + 0x7FFC - возврат в основную, выполнение хотя бы одной команды, TCNT1 = 0xFFFA
i + 0x7FFD - начало входа в обработчик (не менее 4х тактов) T1_ICAP, TCNT1 = 0xFFFB, TOV1 = 0
i + 0x8001 - первая команда обработчика T1_ICAP, TCNT1 = 0xFFFF, TOV1 = 0
i + 0x8002 - вторая команда обработчика T1_ICAP, TOV1 = 1 <------ !
ну и коррекция рез-тата +0x10000, т.к. попадаем под условие коррекции (ICR < 32k, TOV=1).

Эта одна из возможных иллюстраций. На самом деле все ухудшается еще и наличием более высокоприоритетных чем T1_ICAP прерываний от T2 и INTx и т.п.

GetSmart

Oct 10 2006, 23:34

Цитата

как "глюкодром"

Класс!
Не, ну не надо так уж клеймить АВР. Минус только в отсутствии аппаратного запоминания текущего приоритета и запрета низкоприоритетных прерываний и текущего. При большом желании можно легко (!) сделать двухуровневой КП (трёх) если вручную запрещать текущее прерывание, а потом устанавливать флаг I. Плохо только что стека маловато.

defunct

Oct 10 2006, 23:57

Цитата(GetSmart @ Oct 11 2006, 02:34)

Не, ну не надо так уж клеймить АВР.

Не "клеймлю" я его ;>
AVR - отличный процессор. Просто я не сторонник изощренных путей написания программ.
На мой взгляд, надо подстраиваться под железо и писать соответствующие обработчики прерываний. Для AVR они должны быть короткими, т.к. нет многоуровневого КП.

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

Цитата

Минус только в отсутствии аппаратного запоминания текущего приоритета и запрета низкоприоритетных прерываний и текущего.

Это не минус, это фича

Для многих задач это плюс т.к. одноуровневый КП избавляет программиста от некоторых проблем синхронизации.

Цитата

При большом желании можно легко (!) сделать двухуровневой КП (трёх) если вручную запрещать текущее прерывание, а потом устанавливать флаг I. Плохо только что стека маловато.

Можно, но не нужно. Проще просто подобрать другой камень когда это действительно надо.

GetSmart

Oct 11 2006, 02:49

Цитата(defunct)

i - переход на длительный обработчик (пусть будет Uart0) TCNT1 = 0x7FFE
i + 0x1 - срабатывание захвата TIF1 = 1, ICR = 0x7FFF, TOV1 = 0.
i + 0x7FF8 - Uart0 обработка завершена выполнение RETI (4 такта), TCNT1 = FFF6, TOV1 = 0
i + 0x7FFC - возврат в основную, выполнение хотя бы одной команды, TCNT1 = 0xFFFA
i + 0x7FFD - начало входа в обработчик (11 тактов) T1_ICAP, TCNT1 = 0xFFFB, TOV1 = 0
i + 0x8008 - первая команда обработчика T1_ICAP, TOV1 = 1 <------ !
ну и коррекция рез-тата +0x10000, т.к. попадаем под условие коррекции (ICR < 32k, TOV=1).

Ну зачем же такой "экстремальный" пример приводить? Который, кстати, алгоритм-то не дискредитирует

Я же не обещал ровно до 32К тактов дополнительного прерывания. Ваш пример всего-лишь указывает, что максимальное время прерывания = 32К-хх тактов. Скажем 31К или 32000 такта 100% хватит для работоспособности проги. А в Вашей версии будет то же самое = 256-хх тактов.
Вобщем недостатка как такового в моей версии и нету. Блин

=GM=

Oct 11 2006, 10:54

Цитата(singlskv @ Oct 10 2006, 17:06)

Цитата(=GM= @ Oct 10 2006, 21:15)

Цитата(singlskv @ Oct 10 2006, 15:20)

Еще подправил код:

Что-то мне разонравилось измерение по прерыванию. Наверное, надо делать без всяких прерываний, в фоне(:-).

Вам больше не нравятся прерывания ?
- Вы просто не умеете их правильно готовить (с) (не мой)

А что там уметь? Прерывание, оно и в Африке-прерывание(:-).
По делу. Выразился не так, как хотел. Мне не нравится длинное прерывание, которое вдруг стало накладываться на наши два. Откуда бы ему взяться в задаче по измерению временного интервала? Поэтому предлагаю сделать откат назад и исключить третье прерывание.

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

Вот еще один вопросик, требующий внимания. Автор топика намеревался измерять длительность секундных импульсов, а не период. Т.е., есть передний фронт импульса, длительность импульса и задний фронт импульса. Время начала импульса наша программа измерит, а как быть со спадом? Может быть перенастраивать ICES1 при первом входе в прерывание TIM_CAPT или есть более короткий путь?

И моим оппонентам на будущее. Я говорю то, что говорю, не надо искать второго смысла, ОК? И замечайте смайлики иногда.

=GM=

Oct 11 2006, 11:10

Цитата(singlskv @ Oct 10 2006, 16:52)

Цитата(=GM= @ Oct 10 2006, 21:15)

Мне кажется, зря вы здесь используете повторно r7, r6. Вдруг основная программа не успеет их обработать, а уже возникнет новое прерывание TIM1_CAPT. Понятно, что хочется съэкономить, но такая экономия может выйти боком(:-)

Нет, c R6,R7 там все в порядке.
вот этот код будет выполнен в конце прерывания TIM1_CAPT при любых условиях:

Код

mov R6,R2
mov R7,R3

так что здесь, ИМХО все ОК.

Ну раз так, вот вам еще экономия. Не используйте регистры r5-r4 в прерывании, храните результат непосредственно в регистрах icr1h-icr1l. Будет сохранно, как в банке ... до следующего захвата.

singlskv

Oct 11 2006, 16:06

Цитата(=GM= @ Oct 11 2006, 15:10)

Ну раз так, вот вам еще экономия. Не используйте регистры r5-r4 в прерывании, храните результат непосредственно в регистрах icr1h-icr1l. Будет сохранно, как в банке ... до следующего захвата.

А как Вы в основной программе планируете узнавать что произошел второй захват ?

GetSmart

Oct 11 2006, 16:25

Цитата(=GM=)

Автор топика намеревался измерять длительность секундных импульсов, а не период. Т.е., есть передний фронт импульса, длительность импульса и задний фронт импульса. Время начала импульса наша программа измерит, а как быть со спадом? Может быть перенастраивать ICES1 при первом входе в прерывание TIM_CAPT или есть более короткий путь?

Ну дык у АВР есть возможность вызывать прерывание по любому изменению состояния входа. Надо только при запуске правильно инициализироваться (учесть текущее состояние), а дальше - понеслась.

Ведро маслят... Это многое объясняет... Как-нить при случае тоже ляпну такое

AVR

Oct 11 2006, 17:25

Прошу прощения за оффтоп, но для самого автора темы проблема давно уже как не актуальна (1-й пост - 2-го июня)...

singlskv

Oct 11 2006, 17:30

Цитата(AVR @ Oct 11 2006, 21:25)

Прошу прощения за оффтоп, но для самого автора темы проблема давно уже как не актуальна (1-й пост - 2-го июня)...

ну точно OFF - в топку

GetSmart

Oct 11 2006, 17:43

Цитата(AVR @ Oct 11 2006, 23:25)

Прошу прощения за оффтоп, но для самого автора темы проблема давно уже как не актуальна (1-й пост - 2-го июня)...

___________
Please, don't kill me

CD_Eater

Oct 11 2006, 17:59

Цитата(defunct @ Oct 11 2006, 03:57)

Цитата

Минус только в отсутствии аппаратного запоминания текущего приоритета и запрета низкоприоритетных прерываний и текущего.

Это не минус, это фича

Для многих задач это плюс т.к. одноуровневый КП избавляет программиста от некоторых проблем синхронизации.

Конечно, гарантия непрерываемости текущего обработчика прерываний даёт возможность, например, использовать некоторые регистры или ячейки памяти в качестве общих временных для всех обработчиков прерываний без сохранения их предыдущего состояния, а также ограничивает размер стека - это удобно. С другой стороны, на ранних AVR-ках с аппаратным стеком (на 3 вложенных вызова подпрограмм и прерываний) иначе и быть не могло. А далее памяти прибавили, но основу ядра менять не стали...

Цитата

При большом желании можно легко (!) сделать двухуровневой КП (трёх) если вручную запрещать текущее прерывание, а потом устанавливать флаг I. Плохо только что стека маловато.

Можно, но не нужно. Проще просто подобрать другой камень когда это действительно надо.

Зачем выбирать другой камень, если вопрос лишь в доработке софта ?
Менять камень нужно лишь в случае, если он не удовлетворяет требованиям к железу.

singlskv

Oct 11 2006, 20:51

Цитата(defunct @ Oct 11 2006, 03:14)

Цитата(GetSmart @ Oct 11 2006, 03:11)

Так... Вы - против, я - за. Что будем с этим делать?

Ничего

оставим как есть - 2 варианта.
Не бывает единственно верных решений.

Осмелюсь предложить следующее решение:

Код

.def  ConstFF = R8
.def  _TOV1   = R9
.def  _Sreg   = R10
....
    clr   ConstFF
    dec   ConstFF
    ldi   R16, (1 << TOV1)
    mov   _TOV1, R16
....

; Input Capture:
TIM1_CAPT:
    in    _Sreg,SREG
    in    R4, ICR1L
    in    R5, ICR1H
    cp    R5, _TOV1
    brsh  _do_not_correct_result
    in    R6, TIFR
    and   R6, _TOV1
    breq  _do_not_correct_result
    out   TIFR, R6
    sub   R2, ConstFF
    sbc   R3, ConstFF
_do_not_correct_result:
    mov   R6, R2
    mov   R7, R3
    out   SREG,_Sreg
; <-- 32bit Result R7-R6-R5-R4 (MSB R7)
    reti

Здесь уже кому как повезет, куда _TOV1 попадет в TIFR, такой и будет запас
для длинных прерываний.
Да и код, ИМХО становится намного понятнее

А если серьезно, то запас для других прерываний нужно оставлять в зависимости
от конкретной задачи.
Например, вместо TIM1_OVF мы можем использовать TIM1_CAPTA со значением
OCR1A<32K и тогда запас должен быть другим, тогда будет рулить такой код:

Код

    in    R4, ICR1L
    in    R5, ICR1H
    in    R7, OCR1AH
    lsr   R7
    cp    R5, R7
    brsh  _do_not_correct_result

Ну конечно на определенном диапазоне значений OCR1A

=GM=

Oct 12 2006, 09:31

Цитата(singlskv @ Oct 11 2006, 15:06)

Цитата(=GM= @ Oct 11 2006, 15:10)

Ну раз так, вот вам еще экономия. Не используйте регистры r5-r4 в прерывании, храните результат непосредственно в регистрах icr1h-icr1l. Будет сохранно, как в банке ... до следующего захвата.

А как Вы в основной программе планируете узнавать что произошел второй захват ?

А вы у GetSmart спросите, он всё знает(:-). Спокойно, GetSmart, шютю я(:-)

Чуть посерьёзнее. Я вам про экономию регистров в прерывании говорю, "которых всегда не хватает", а вы плавно меняете тему. Какая разница, где хранить время текущего захвата, в регистрах r7-r6-r5-r4 или в r7-r6-icr1h-icr1l? Никакой разницы нет. Почти. Зато экономится два регистра!

Ну а по делу, думаю есть несколько подходов.

1) Есть две переменные, скажем, oldTime и newTime (ваши r7-r6-r5-r4). Прерывание захвата должно переписывать содержимое newTime в oldTime, и только затем обновлять newTime. Основная программа в любое удобное для себя время(:-) определяет длительность интервала, просто вычитая содержимое oldTime из newTime.

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

Цитата(GetSmart @ Oct 11 2006, 15:25)

Цитата(=GM=)

Автор топика намеревался измерять длительность секундных импульсов, а не период. Т.е., есть передний фронт импульса, длительность импульса и задний фронт импульса. Время начала импульса наша программа измерит, а как быть со спадом? Может быть перенастраивать ICES1 при первом входе в прерывание TIM_CAPT или есть более короткий путь?

Ну дык у АВР есть возможность вызывать прерывание по любому изменению состояния входа. Надо только при запуске правильно инициализироваться (учесть текущее состояние), а дальше - понеслась.

Неправильно. В том то и дело, что не один раз при запуске программы надо инициализироваться, а каждый раз при входе в захват(:-(. Потому что на четных захватах вы ловите переход 0-1 (начало импульса), а на нечетных захватах вы ловите 1-0 (конец импульса). Я и спрашивал, перенастраивать ICES1 каждый раз или есть другой способ, попроще?

Цитата(GetSmart @ Oct 11 2006, 15:25)

Ведро маслят... Это многое объясняет... Как-нить при случае тоже ляпну такое

GetSmart, хорош бурчать, это у вас так что проявляется(:-)? Не злитесь, ляпните что-нибудь или тяпните, разрядка придёт, поверьте(:-). Добавлю специально для вас. Напротив моих окон стоит бангало, под ним живет более 20 диких кроликов, смешные такие...А недавно видел как ворона ссорилась с белкой, наскакивали друг на друга, прям как вы на меня(:-).

GetSmart, жена маслята уже посолила, вот. Белые тут тоже водятся, но ехать далеко, в Нью Форист, неохота...

GetSmart

Oct 12 2006, 10:18

Цитата(=GM=)

GetSmart, хорош бурчать, это у вас так что проявляется(:-)?

Это веселуха. Заметьте, над другими тоже. А вообще, люблю "поржать" над чужими глупостями. Это после длииинного отпуска у меня такой бзик. Должен пройти.

Цитата

Я и спрашивал, перенастраивать ICES1 каждый раз или есть другой способ, попроще?

Нету.

Цитата

А вы у GetSmart спросите, он всё знает(:-)

Нее, я мало знаю. На всём форуме я очень мало где появляюсь. То есть знаю совсем немного тем, но обычно очень глубоко.

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

defunct

Oct 15 2006, 02:25

Цитата(=GM= @ Oct 12 2006, 12:31)

А недавно видел как ворона ссорилась с белкой, наскакивали друг на друга, прям как вы на меня(:-).

Дык, эта, если смотреть со стороны, здесь все замечания вам по делу были сказаны, а вы все в шутку да в обидку воспринимаете..
Что ни пост - то перл:

особливо это:

Цитата

Какая разница, где хранить время текущего захвата, в регистрах r7-r6-r5-r4 или в r7-r6-icr1h-icr1l?

Ну уж никак не в аппаратно зависимых регистрах, которые нам абсолютно неподконтрольны.
Вы что, правда не понимаете, что можно не успеть вычитать icr1h-icr1l до того как случится следующий захват? либо например наткнуться на ситуацию когда в момент вычитки L, произойдет следующий захват.

=GM=

Oct 16 2006, 13:06

Цитата(defunct @ Oct 15 2006, 01:25)

Что ни пост - то перл: особливо это:

Цитата

Какая разница, где хранить время текущего захвата, в регистрах r7-r6-r5-r4 или в r7-r6-icr1h-icr1l?

Ну уж никак не в аппаратно зависимых регистрах, которые нам абсолютно неподконтрольны.
Вы что, правда не понимаете, что можно не успеть вычитать icr1h-icr1l до того как случится следующий захват? либо например наткнуться на ситуацию когда в момент вычитки L, произойдет следующий захват.

Я и не такие перлы могу выдавать(:-). Но вообще-то, в нашем случае никакой разницы на самом деле нет, посудите сами, как только произошел захват, возникло прерывание, в котором регистры icr1h-icr1l читаются и переписываются в r5-r4, т.е. и icr1h-icr1l, и r5-r4 изменяются практически одновременно (макс разница 32 мс, если есть длинное прерывание). Естественно предполагается, что вы должны успеть обработать r7-r6-r5-r4 до следующего захвата, который может случиться через секунду (по условию задачи). Ну и спрашивается, зачем тратить два регистра МК, если можно с таким же успехом хранить данные в регистрах захвата?

Если же вы не успели, то произойдет новый захват, r5-r4 тоже испортятся, так что тут ничто не поможет, какая разница, что испорчено? Как меру борьбы, в прерывании можно сразу сохранять время захвата в озу, но опять же сохранять можно прямо из регистров захвата, r5-r4 тут не нужны.

Вы-то сами понимаете, что при наличии длинного прерывания наступит крах вашей системы прерываний, если, скажем, возникнет два прерывания захвата в течение 65 мс?

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

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

Что ещё? На справедливую критику не обижаюсь, с несправедливой борюсь по мере сил(:-), и посмеяться и пошутить люблю, но по-доброму.

defunct

Oct 18 2006, 11:44

Цитата(=GM= @ Oct 16 2006, 16:06)

Я и не такие перлы могу выдавать(:-). Но вообще-то, в нашем случае никакой разницы на самом деле нет, посудите сами, как только произошел захват, возникло прерывание, в котором регистры icr1h-icr1l читаются и переписываются в r5-r4, т.е. и icr1h-icr1l, и r5-r4 изменяются практически одновременно (макс разница 32 мс, если есть длинное прерывание). Естественно предполагается, что вы должны успеть обработать r7-r6-r5-r4 до следующего захвата, который может случиться через секунду (по условию задачи). Ну и спрашивается, зачем тратить два регистра МК, если можно с таким же успехом хранить данные в регистрах захвата?

Если же вы не успели, то произойдет новый захват, r5-r4 тоже испортятся, так что тут ничто не поможет, какая разница, что испорчено?

Затем, что прерывание может произойти именно в момент вычитки значения, и мы можем прочитать недостоверные данные.

Если же рез-тат будет храниться в r7-r6-r5-r4, то мы можем запретить флаг I при обращении к этой 32х битной переменной, и тем самым обезопасить себя от последствий описанного случая.

Учить матчасть

=GM=

Oct 18 2006, 14:14

Цитата(defunct @ Oct 18 2006, 10:44)

Затем, что прерывание может произойти именно в момент вычитки значения, и мы можем прочитать недостоверные данные.

Если же рез-тат будет храниться в r7-r6-r5-r4, то мы можем запретить флаг I при обращении к этой 32х битной переменной, и тем самым обезопасить себя от последствий описанного случая.

Here we go! Я ж вам сконструировал реальный пример. Ну запретили вы все прерывания, потом пришло два захвата до начала вашей обработки с интервалом в 50 мкс, и где будут данные от первого захвата, скажите? Правильно, в глубокой попе, а не в r7-r6-r5-r4.

Как-то вы несистемно подходите к задаче измерения интервалов. Ну написали вы программку чтения данных из регистров icr1, дальше-то что делать? Ждать когда завершится длинное прерывание и фоновая программа наконец запретит прерывания, соизволит переписать r7-r6-r5-r4 в память и разрешит прерывания заново? Данах такую программу измерения! Пока ваша программа будет жевать сопли, там уж десять раз новый захват может возникнуть!

На мой взгляд, чтобы программа обработки захвата была максимально быстрой, она должна записывать время захвата в буфер именно в программе обработки. Если вы согласны с этим, то какая разница откуда писать в буфер? Из r7-r6-r5-r4, или из r7-r6-icr1h-icr1l, или из r3-r2-icr1h-icr1l? Да без разницы! Но лучше из r3-r2-icr1h-icr1l (с возможной коррекцией), т.к. экономятся регистры и быстрее работает. Ну и никаких других прерываний, измерение интервалов само по себе ответственное дело(:-).

Цитата(defunct @ Oct 18 2006, 10:44)

Учить матчасть

Согласен, учить не вредно (хотя конкретно здесь сказано вами не к месту). Но вот посмотрел еще раз на 128-ю атмегу и нашел способ измерения интервалов с точностью 0.5 мкс (полмикросекунды!) Точность удвоена, ура три раза!

Кстати, почему никто не отвечает на вопрос что требуется измерение длины импульса (фронт и спад), а не периода (два фронта или два спада)? Все согласны что ли?

GetSmart

Oct 18 2006, 14:43

Цитата(=GM=)

Как-то вы несистемно подходите к задаче измерения интервалов.

А вы типа полный системщик. Тут вам предложили просто наброски проги с самыми сложными местами. Базару нет - её можно улучшить под конкретную задачу. Похоже только вам здесь хочется её воплотить в железе. Делайте. Напишите и выложите тут свою прогу, а мы её дружно покритикуем. Даже поможем улучшить. А то ведь вы порой бревна в глазу не замечаете. Так что будет интересно и нам и вам. А может даже весело.

defunct

Oct 18 2006, 16:04

Цитата(=GM= @ Oct 18 2006, 17:14)

хотя конкретно здесь сказано вами не к месту

Вам виднее.

Цитата

Кстати, почему никто не отвечает на вопрос что требуется измерение длины импульса (фронт и спад), а не периода (два фронта или два спада)? Все согласны что ли?

Потому что это уже косметика.

Цитата

Если вы согласны с этим, то какая разница откуда писать в буфер? Из r7-r6-r5-r4, или из r7-r6-icr1h-icr1l, или из r3-r2-icr1h-icr1l?

Разница огромная.
Я предпочту запретить прерывания и прочитать достоверное значение из защищенного от изменений буфера. После чего, разрешив прерывания, будет выполнено обновление переменной и т.д. Этим я обезопашу себя и вас от дурацких вопросов в будущем - "окуда появилось это значение". Вы же со своей реализацией и вычиткой icr от таких вопросов ничем не застрахованы, если Вам с вашим системным подходом до сих пор не ясна проблема, то я попробую озвучить ее прямым текстом:
- пол переменной у вас может быть прочитано из одного семпла, а вторая половина - из второго.

GetSmart

Oct 18 2006, 17:17

defunct
Любопытная вещь. Это я где-то уже видел и проверил для АВРов. Там есть временный регистер для защёлкивания старших 8 бит при чтении младших. То бишь читая младший, а затем старший регистр гарантированно прочитается цельное значение.

=GM=
Читать ICR1L и ICR1H по-любому придётся вначале в регистры. Там же проверка стоит старшего байта. Ну а потом прямо в прерывании можно вычитать все 4 байта из предыдущих 4 байт и сувать куда-нибудь. Например в кольцевой буфер в ОЗУ. R6 и R7 можно будет не использовать. Но вообще, особой выгоды в экономии и нет. Лишь бы правильно работала. Апосля можно переключать полярность защёлкивания и желлательно сразу проверить полярность на входе.

singlskv

Oct 18 2006, 20:07

Цитата(=GM= @ Oct 18 2006, 18:14)

Но вот посмотрел еще раз на 128-ю атмегу и нашел способ измерения интервалов с точностью 0.5 мкс (полмикросекунды!) Точность удвоена, ура три раза!

Ну давайте сразу же определимся, в конечном итоге мы измеряли не мкс а такты проца.

То есть Вы утверждаете, что Вы можете измерить временной интервал, с точностью 0,5 такта
процессора, который измеряет этот временной интервал ?

Ну поделитесь кодом, что ли.

Если это know-how, и Вы собираетесь на этом заработать, то тогда
скажите как будет выглядеть возвращаемое значение вашего измерения
например для промежутков 50тактов 50,5тактов 51тактов и т.д.....
Мы, как Ваши потенциальные клиенты должны (перед покупкой Вашего алгоритма)
знать какие выходные данные мы получим.
С нетерпением жду Ваших ответов

P.S. Нельзя ли модернизировать Ваш алгоритм для получения 1/16 такта процессора,
очень надо...

=GM=

Oct 19 2006, 14:55

Цитата(GetSmart @ Oct 18 2006, 13:43)

Цитата(=GM=)

Как-то вы несистемно подходите к задаче измерения интервалов.

А вы типа полный системщик. Тут вам предложили просто наброски проги с самыми сложными местами. Базару нет - её можно улучшить под конкретную задачу.

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

Цитата(GetSmart @ Oct 18 2006, 13:43)

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

Да не хочется мне ее воплощать. Меня интересуют потенциальные возможности аврок. Единственное рациональное зерно, до которого я допер в результате долгой дискуссии - это возможность измерения времени импульса с точностью ПОЛТАКТА процессора, в нашем случае - 0.5 мкс.
Ну а чтобы было веселее, вот моя прога. Критикуйте на здоровье. Улучшайте. Сразу скажу, прога сырая, я ее не проверял, есть два сомнительных места, надеюсь, с помощью коллективного разума разрешим их.

Код

; В регистрах r23-r22-r21-r20 размещается время спада импульса
; В регистрах r19-r18-r17-r16 размещается время фронта импульса
; Регистровая пара X – два старших байта текущего времени
; Регистровая пара Y – текущий указатель в buffer (0х0100-0х01FF)
; Регистровая пара Z – переключатель фрагментов программы захвата

           .dseg                 ;01
buffer:    .org   0x0100         ;02
           .cseg                 ;03
           .org   0x0016         ;04 обработчик захвата1
tim1capt:  ijmp                  ;05 переключатель
           .org   0x001С         ;06 обработчик переполнения1
tim1ovf:   rjmp   overflow1      ;07

;<< фрагмент программы инициализации >>
;. . . . . . . .
           ldi    zl,low(rising) ;10
           ldi    zh,high(rising);11
           ldi    r16,0x00       ;12 захват по спаду
           mov    r15,r16        ;13
           ldi    r16,0x20       ;14 сброс ICF1
           mov    r14,r16        ;15
           ldi    r16,0x40       ;16 захват по фронту
           mov    r13,r16        ;17
;. . . . . . . .
;<< конец фрагмента программы инициализации >>
;
           .org   0x0100         ;22
rising:    in     r16,ICR1L      ;24 обработка фронта
           in     r17,ICR1H      ;24
           out    tccr1b,r15     ;25
           out    tifr,r14       ;26
           movw   r18,r26        ;27 r19-r18-r17-r16
           in     r10,SREG       ;28
           cpi    r17,0x00       ;29
           brne   ris1           ;30
           in     r24,tifr       ;31
           sbrs   r24,tov1       ;32
           rjmp   ris1           ;33
           subi   r16,low(-1)    ;34
           sbci   r17,high(-1)   ;35
ris1:      ldi    zl,low(falling);36
           out    SREG,r10       ;37
           sei                   ;38
           ret                   ;39
;
falling:   in     r16,ICR1L      ;50 обработка спада
           in     r17,ICR1H      ;51
           out    tccr1b,r15     ;52
           out    tifr,r14       ;53
           movw   r22,r26        ;54
           in     r10,SREG       ;55
           cpi    r17,0x00       ;56
           brne   fal1           ;57
           in     r24,tifr       ;58
           sbrs   r24,tov1       ;59
           rjmp   fal1           ;60
           subi   r21,low(-1)    ;61
           sbci   r22,high(-1)   ;62
fal1:      sub    r20,r16        ;63
           sbc    r21,r17        ;64
           sbc    r22,r18        ;65
           sbc    r23,r19        ;66
           st     y+,r20         ;67
           st     y+,r21         ;68
           st     y+,r22         ;69
           st     y+,r23         ;70
           ldi    yh,high(buffer);71
           ldi    zl,low(rising) ;72
           out    SREG,r10       ;73
           sei                   ;74
           ret                   ;75
;
; обработчик переполнения таймера1
overflow1: in     r10,SREG       ;90
           adiw   r26,1          ;91
           out    SREG,r10       ;92
           reti                  ;93

=GM=

Oct 19 2006, 15:21

Цитата(singlskv @ Oct 18 2006, 19:07)

Цитата(=GM= @ Oct 18 2006, 18:14)

Но вот посмотрел еще раз на 128-ю атмегу и нашел способ измерения интервалов с точностью 0.5 мкс (полмикросекунды!) Точность удвоена, ура три раза!

Ну давайте сразу же определимся, в конечном итоге мы измеряли не мкс а такты проца.
То есть Вы утверждаете, что Вы можете измерить временной интервал, с точностью 0,5 такта
процессора, который измеряет этот временной интервал ?

Да, утверждаю. Для нашего случая тактовая частота равна 1 МГц, так что точность будет 0.5 мкс. А в общем случае, полтакта процессора.

Цитата(singlskv @ Oct 18 2006, 19:07)

Ну поделитесь кодом, что ли.

Если это know-how, и Вы собираетесь на этом заработать, то тогда
скажите как будет выглядеть возвращаемое значение вашего измерения
например для промежутков 50тактов 50,5тактов 51тактов и т.д.....
Мы, как Ваши потенциальные клиенты должны (перед покупкой Вашего алгоритма)
знать какие выходные данные мы получим.
С нетерпением жду Ваших ответов

P.S. Нельзя ли модернизировать Ваш алгоритм для получения 1/16 такта процессора,
очень надо...

Кодом поделиться не могу, его просто нет. Есть плодотворная идея как это реализовать на голой атмеге128, и программа, кажется, будет несложной. Зарабатывать на этом я не собираюсь, хотя шут ее знает, может надо(:-)?
Возвращаемое значение будет точно также размещено в 4-х байтах, но одна единица будет соответствовать не длительности 1-го такта, а его половине, т.е. 100, 101, 102, 103 [тактов/2] вместо 50, 50.5, 51 [тактов].
По поводу модернизации. Можно и для 1/16 сделать, только с дополнительными прибамбасами(:-(. Вы лучше скажите, что вы хотите сделать, тогда можно поконкретнее ответить.

singlskv

Oct 19 2006, 17:20

Цитата(=GM= @ Oct 19 2006, 18:55)

Код

........................
........................

Не понял чем Ваш код принципиально отличается от того что мы здесь обсуждали.
Косметика ?
Только Вы умудрились сожрать под прерывания все старшие регистры
кроме R25, да еще и 4 младших.
Интересно, в основной программе Вы планируете для работы с константами
использовать только R25 ? А регистрами X,Y,Z вообще не пользоваться ?

Цитата(=GM= @ Oct 19 2006, 19:21)

Цитата(singlskv @ Oct 18 2006, 19:07)

Цитата(=GM= @ Oct 18 2006, 18:14)

Но вот посмотрел еще раз на 128-ю атмегу и нашел способ измерения интервалов с точностью 0.5 мкс (полмикросекунды!) Точность удвоена, ура три раза!

Ну давайте сразу же определимся, в конечном итоге мы измеряли не мкс а такты проца.
То есть Вы утверждаете, что Вы можете измерить временной интервал, с точностью 0,5 такта
процессора, который измеряет этот временной интервал ?

Да, утверждаю. Для нашего случая тактовая частота равна 1 МГц, так что точность будет 0.5 мкс. А в общем случае, полтакта процессора.

Вы собираетесь для этих целей использовать Analog Comparator ?
Тогда посмотрите Electrical Characteristic
параметр Analog Comparator Propogation Delay

Цитата

По поводу модернизации. Можно и для 1/16 сделать, только с дополнительными прибамбасами(:-(. Вы лучше скажите, что вы хотите сделать, тогда можно поконкретнее ответить.

С дополнительными прибамбасами я и сам знаю как, это была просто шутка

GetSmart

Oct 20 2006, 02:23

Цитата(=GM=)

Похоже вам слово системщик, как быку красная тряпка(:-), не обижайтесь.

Зачем обижаться. Почти верно. Только слово системщик у меня ассоциируется с чем-то сложным и за это уважаемым. Кстати, я сам системщик, то бишь системный программист. У вас же в последней проге слишком много ошибок или опечаток. Ну и ничего нового.

Интересно чем отличается конструкция {sei ; ret} от {iret} ? Если я не ошибаюсь, она только хуже.

Вообще, заинтриговало Ваше заявление про 0.5 такта.

=GM=

Oct 20 2006, 10:08

GetSmart У вас же в последней проге слишком много ошибок или опечаток. Ну и ничего нового.

Есть опечатки, строки 50, 51, 52 и 56, копи+пейст мой бич. Может и ошибки есть, как же без них(:-). Любая сколь угодно малая программа содержит хотя бы одну ошибку(:-). Кто сказал? Вирт?
Нового ничего, за исключением того, что прерывание таймера1 по переполнению не сбрасывается в данном прерывании, что есть правильно.

Вопрос в другом, как мерять импульсы и интервалы между ними от 1 мкс и выше? Есть предложения(:-)?

GetSmart Интересно чем отличается конструкция {sei ; ret} от {iret} ? Если я не ошибаюсь, она только хуже.

Это следствие смены детектора перехода (0-1 или 1-0), чтобы не портить установку. Я сам не очень уверен здесь, хотя делал всё по описанию. Обратите внимание на строчки 25, 26 и 52, 53.

GetSmart Вообще, заинтриговало Ваше заявление про 0.5 такта.

А меня Ваше про 400 Мбод. У меня максимум на 16-ти мегагерцовой атмеге - 39 Мбод.
Насчет 0.5 такта правда, на фирме посоветовался с электронщиком, вроде проходит.
Интересно, что defunct думает по поводу полтакта, пропал он куда-то...