AVR: Синхронизация исполнения кода к значению таймера Т1

[ВитГо]

Есть задача очень критичная к времени исполнения кода..
параллельно задаче крутиться еще несколько задач - поэтому критичная задача реализована через T1 в режиме CTC top=OCR1A OC1=toggle - то есть генерация сигнала идет по таймеру и очень точно..
в прерывании T1 осуществляется обработка и задание новых значений OCR1A и т.д..

в принципе сам смысл захода в прерывание предполагает возможность возникновения некоторого джиттера захода в 1-3 такта (прерывание всегда ждет окончания исполнения текущей команды и только после этого осуществляется переход по вектору)

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

то есто чтото вроде алгоритма:

IN temp, TCNT1
cpi temp, значение
если значение рядом - то ждем
если значение не рядом - то много ждем

подождали и оказались здесь в значение таймера равное константе (при любом заходе с любой задержкой)

p.s. в принципе думаю что эту задачу решу, но вдруг ктото уже заморачивался...

Прошу прощения, но по-моему, эта проблема у вас надумана сильно. Я делал похожую задачу, и при частоте кварца 16 МГц и периодом прерываний 0,1 мс я на цифровом осциллографе не смог увидеть этот "дребезг". Просто по этому прерыванию я программно формировал короткий импульс на одной ножке (запуск внешнего АЦП). При этом задача тоже была весьма критичная во времени. Все процедуры были у меня оптимизированы так, что к моменту наступления следующего прерывания они гарантированно должны были закончиться и фактически просто крутился вхолостую основной цикл. Естественно писалось всё на ассемблере. А если 1-3 такта так критичны, то может тогда использовать другой МК с бОльшей тактовой?

[ВитГо]

Прошу прощения, но по-моему, эта проблема у вас надумана сильно. Я делал похожую задачу, и при частоте кварца 16 МГц и периодом прерываний 0,1 мс я на цифровом осциллографе не смог увидеть этот "дребезг". Просто по этому прерыванию я программно формировал короткий импульс на одной ножке (запуск внешнего АЦП). При этом задача тоже была весьма критичная во времени. Все процедуры были у меня оптимизированы так, что к моменту наступления следующего прерывания они гарантированно должны были закончиться и фактически просто крутился вхолостую основной цикл. Естественно писалось всё на ассемблере. А если 1-3 такта так критичны, то может тогда использовать другой МК с бОльшей тактовой?

гм..
у меня программа генерит изображение на телевизор
рабочая частота меги 16 мгц.
1\16000000=0.0625 мкс
на вывод одной точки трачу 0.125 мкс
за 0.1 мс я выведу 8 точек !

так что мне задержки важны.. очень...

[BCluster]

на вывод одной точки трачу 0.125 мкс
за 0.1 мс я выведу 8 точек !

странная арифметика )
за 0.1 мс при 0.125 мкс на точку вы должны вывести 800 точек или я чет недопонимаю?

Тогда либо другого типа МК (STM) с бОльшей тактовой, либо часть процесса вывода огранизовать аппаратно с двойной буферизацией. МК пишет в промежуточный буфер, а внешняя схема синхронизации (на жёсткой логике) байт будет переписывать в сдвиговый регистр. Что-то такое было реализовано в Спектруме версии АТМ-Турбо. Таким образом куча времени на запись в промежуточный буфер

[ВитГо]

на вывод одной точки трачу 0.125 мкс
за 0.1 мс я выведу 8 точек !

странная арифметика )
за 0.1 мс при 0.125 мкс на точку вы должны вывести 800 точек или я чет недопонимаю?

ой.. да, ошибся...

в общем мне важно синхронизироваться по таймеру...

Последний раз редактировалось ВитГо Вт сен 04, 2012 13:43:58, всего редактировалось 1 раз.

[ВитГо]

Тогда либо другого типа МК (STM) с бОльшей тактовой, либо часть процесса вывода огранизовать аппаратно с двойной буферизацией.

все уже написано, и все работает.. нужно только сделать синхронизацию...

кстати на stm все еще веселее, так как там порты тактируются отдельно от процессора, так что там будут свои не менее интересные грабли при выводе ))

в принципе есть мысли как это сделать.. попробую наверное сегодня ночью написать

[BOB51]

внешний "рассыпушный" элемент, тактируемый сигналом из ведущего МК (МОНГОФАЗНАЯ СИНХРОНИЗАЦИЯ времен когда сам МК на рассыпухе собран был))
или МК с приоритетным контроллером прерываний (родичи MCS51)

[ВитГо]

неее, это точно не то..

в принципе после прерывания счетчика он сбрасывается в ноль..
причем это происходит вне зависимости от исполняемых процессором команда и входа в прерывание.
поэтому нужно по входу в прерывание прочитать значение TCNT1L
у него будут значения например от 1 до 5..
далее в зависимости от этих значений нужно сделать переход на исполнение

гм..
может быть так:

in R16 , TCNT1L
cpi R16 , 5 ; 1
breq l2 ; 1 точка (1) если условие не сравнялось и 2 если сравнялось
; здесь мы уже задержались на 1 лишний такт
cpi R16 , 4 '; 1
breq l1 ; еще 1 такт если не сравнялось и 2 если сравнялось
; получается что здесь относительно точки (1) мы уже на 2-3 такта сдвинулись
...
...
...

l1:
nop
l2:
; здесь типа уже синхронизированы..

[ILYAUL]

Ни хрена не понял , есть константа , есть таймер , на фига искать совпадение таймера с константой , если константу можно загнать в таймер.....

[ВитГо]

а потому что таймер работает с OC1A, и состояние на выводе OC1A при совпадении TCNT и OCR уже поменялось.. и мне нужно строго в определенный момент начать вывод информации..
строго определенный от момента изменения состояния на OC1A

а константу в счетчик загнать - это установить паузу без учета того времени которое мы потратили на вход в прерывание

Последний раз редактировалось ВитГо Вт сен 04, 2012 17:22:38, всего редактировалось 1 раз.

И всё же ещё раз предложу использовать жёсткую логику для разгрузки МК в критичном месте. Потому как, по-моему, вы тут стараетесь впихнуть невпихуемое.

[ILYAUL]

Во первых Режим таймера в Normal mode
Во - вторых Считывать не TCNT а OCR
В третьих Const-X = OCR где Х время на прерывание

[ВитГо]

Во первых Режим таймера в Normal mode
Во - вторых Считывать не TCNT а OCR
В третьих Const-X = OCR где Х время на прерывание

еще раз повторю:
режим таймера CTC, top=OCR1A, toggle OC1A - это не изменяемо.. на этом работает программа

кстати а что даст по вашему мнению считывание OCR в нормальном режиме таймера?

в общем такое ощущение что не поняли вопрос...

[ILYAUL]

А для таймера и Ваших отсчётов и прерываний ничего не изменится , зато всегда будете знать ,что Вы писали в OCR и кстати добавится точность.

[ВитГо]

ладно, вопрос снят, ларчик открылся просто

Код:

;здесь  вошли в прерывание, могла быть задержка от 0 до 5 тактов

                  ldi R16   , TCNT1L    ; 1

                  cpi R16   , 5         ; 1 поздно вошли в прерывание, уже 5 тиков прошло
                  breq  after_5       ; 1 (2)

                  cpi   R16   , 4         ; 1 прошло 4 тика
                  breq  after_4       ; 1 (2)

                  cpi   R16   , 3         ; 1 прошло 3 тика
                  breq after_3       ; 1 (2)                  

                  cpi   R16   , 2         ; 1 прошло 2 тика
                  breq after_2       ; 1 (2)                  

                  cpi   R16   , 1         ; 1 прошел 1 тик
                  breq after_1       ; 1 (2)                  
                       
                  rjmp  after_0      ; 1 (2)

after_5:            ; сюда попали потратив 4 тика
                        nop             ; разница входа между after_5 и after_4 один тик
after_4:            ; сюда попали потратив 6 тиков
                        nop
after_3:            ; сюда попали потратив 8 тиков
                        nop
after_2:            ; сюда попали потратив 10 тиков
                        nop
after_1:            ; сюда попали потратив 12 тиков

after_0:                ; сюда попали потратив 13 тиков

; в эту точку программы мы попадем строго через 13 тиков после генерации запроса на прерывание T1 CTC, top=OCR1A


а вы говорите невпихуемое

перефразирую классиков: "процессор, рассыпуха... главное алгоритм !"

чё та я логики тут не очень усматриваю. Тут вам не жалко потратить 13 тактов (0,8 мкс при 16МГц) в воздух, но при этом

на вывод одной точки трачу 0.125 мкс

(8 точек - 1 мкс)

[ВитГо]

Формат видеосигнала предусматривает задержку в 5.8 мкс перед выдачей изображения..
вот в этой задержке я себе совершенно спокойно прощаю задержку в 13 тактов

а вот когда начинается генерация видео - там время уже ни на что не тратиться.. и на счету каждый такт

самое главное в этом подходить к генерации строки видео в одно и тоже время от синхроимпульса, вне зависимости от того какую команду нам пришлось завершать перед вызовом прерывания... - вот для этого я и задавал вопрос...

кстати, не поленился и просимулировал в АВР Студии этот код для проверки по тактам. От точки

cpi R16 , 5 ; 1 поздно вошли в прерывание, уже 5 тиков прошло

до конца
R16 5 4 3 2 1
такты 7 8 9 10 11

[ВитГо]

Гм.. а как симулировали, у меня все работает так как задумано

у меня:
R16 = 5 . до конца 8 тактов (+ 5 тактов на которые мы задержались=13 тактов)
R16 = 4 . до конца 9 тактов (+ 4 такта на которые мы задержались =13 тактов)
R16 = 3 . до конца 10 тактов (+ 3 такта на которые мы задержались =13 тактов

дальше не стал проверять

для желающих попробовать даю ссылку на проект http://vg.ucoz.ru/raznoe/time_test.zip