Ассемблер (ASM) для AVR в вопросах и ответах

[xkp]

Спасибо большое! Дописал в программу вывод на графический индикатор и протестил в протеусе. Пока вроде все устраивает. но и тут появились НО ((
При частоте тактирования МК в 1мГц таймер-счетчик "переполняется" при входном сигнале ниже 15 Гц, тоесть насчитывает больше чем $FFFF (вернее тактов проходит больше чем максимальное значение счетчика), и естественно когда вычитает из нового значение старое, то получается котовасия.

Спойлер

Код: Выделить всё

tim1_capt:
   push tmp         ;сохраняем данные
   push tmp0         ;которые можем потерять
   in tmp,sreg         ;tmp, tmp0,
   push tmp         ;sreg

in tmp,icr1l
in tmp0,icr1h
lds r18,timl
lds r19,timh
sts timl,tmp
sts timh,tmp0
clc
sub tmp,r18
sbc tmp0,r19
sts timindl,tmp
sts timindh,tmp0

   pop tmp            ;восстанавливаем ранее
   out sreg,tmp      ;сохранённые данные
   pop tmp0         ;в обратном порядке
   pop tmp            ;sreg,tmp,tmp0
   reti

Как решить эту проблему? Очевидно нужно добавить третий регистр в результат.
Примерно так, но это работать не будет.

Спойлер

Код: Выделить всё

in tmp,icr1l
in tmp0,icr1h
lds r18,timl
lds r19,timh
sts timl,tmp
sts timh,tmp0
clc
clr r20
sub tmp,r18
sub tmp0,r19
ror r20
sts timindl,tmp
sts timindh,tmp0
sts timindh2.r20

[akl]

Вы должны разрешить прерывания по переполнению таймера, в каждом из которых наращивать счётчик. Это и будет старшая часть общего счётчика. Дополнительно этот регистр использую для отсечки заданного времени измерения. Может посмотрите кусок кода с обработкой прерываний из CLR2313.

Спойлер

Код: Выделить всё

RESET:
   RJMP   START      ; On Reset
   RJMP   ON_OFF      ; On Interrupt 0
   RJMP   GO_ISR1      ; On Interrupt 1 прерывание при нажатии кнопки "РЕЖИМ"

   IJMP         ; Timer 1 capture
   RETI         ; Timer 1A compare
   ADIW   XL,1      ; Timer 1 overflow
   CPI   XH,$10      ; время измерения ~32 сек
   BRCS   IZM
   SET
IZM:
   RETI
;***************************************************************************
;***************************************************************************
;***************************************************************************
;***************************************************************************
;***************************************************************************
CAPT:
   IN   R1,ICR1L
   IN   R0,ICR1H
   CLR   XH
   CLR   XL      ; очистить старшее слово nx_begin
      
;   LDI   ZH,HIGH(CAPT_1)
   LDI   ZL,LOW (CAPT_1); следующее прерывание будет на CAPT_1
   RETI
CAPT_1:
   IN   R19,ICR1L
   IN   R18,ICR1H   ; конечное значение nx
   
   ADIW   YL,1      ; Nx=Nx+1
      
   CPI   XL,40      ; время измерения закончилось?
   CPC   XH,ZH
   BRCC   CAPT_3      ; да
   RETI         ; нет
CAPT_3:
   IN   R16,TIFR
   SBRC   R16,7      ; если есть необработанное требование прерывания OVER_T1
   RETI         ; выход для его обработки и ожидания
            ; окончания следующего периода

   OUT   TCCR1B,ZH   ; STOP T1
   OUT   TIMSK,ZH

   SUB   R19,R1
   SBC   R18,R0
   SBC   XL,ZH
   SBC   XH,ZH      ; nx-nx_begin
      
   STS   $76,XH
   STS   $77,XL
   STS   $78,R18
   STS   $79,R19      ; nx
      
   STS   $86,ZH
   STS   $87,ZH
   STS   $88,YH
   STS   $89,YL      ; Nx
      
   SET
   RETI
;***************************************************************************

[xkp]

Хорошая идея. только вот вопрос....
сначало о хорошем. Предыдущее значение, например, 1. Текущее 4. Переполнения небыло. результат 3.
А вот теперь при тех же самых условиях но с переполнением. Предыдущее = $FFFE, текущее = 1. Результат тот же - 3. но тут было переполнение и к старшему байту прибавится 1. Получится $010003 что равно 65539, вместо нашего числа 3.
Вобщем я не понял как это можно использовать.

[Alexeyslav]

Переполнение не надо учитывать в таких вычитаниях. Такие вот фокусы двоичной арифметики в ограниченной разрядности.

[xkp]

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

[Alexeyslav]

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

[xkp]

так разница ни как не может быть больше FFFF, т.к. счетчик считает только до FFFF а потом обнуляется.

[Alexeyslav]

А если он за время опроса 3 раза прокрутится через переполнение? посчитанная разница конечно будет меньше FFFF но она будет далека от реальной.

[xkp]

так в этом и есть мой опрос. Я еще с самого начала писал

Если да то как и сколько байт памяти будет занимать максимально возможный результат? Думаю 3 байта...

может в tim1_over (по переполнению) каждый раз инкрементировать старший (третий) бай. а в tim1_capt уже работать (вычитать) не с 2 байтами а с 3.

[Alexeyslav]

С 3-мя байтами будут потенциальные проблемы. 16-битный счетчик имеет специальный механизм синхронизации, а вот с 3-м байтом надо что-то делать. будет промежуток времени между чтением первых 16 бит и 3-го байта когда могут произойти несинхронизированные изменения. Допустим, таймер досчитал до FFFF и мы это значение считали на следующем такте он переполняется возникает прерывание и в 3-й байт уходит +1, потом мы считываем третий байт который уже не соответствует значению счетчика считанному несколькими тактами ранее.

[akl]

может в tim1_over (по переполнению) каждый раз инкрементировать старший (третий) бай. а в tim1_capt уже работать (вычитать) не с 2 байтами а с 3.

Да, именно так. С учётом того, что на время обработки прерывания флаг I в SREG сбрасывается аппаратно и прерывание tim1_capt имеет более высокий приоритет чем tim1_over. Т.е. если прерывание переполнения пришло хоть на один такт раньше захвата, программа сработает правильно и старший байт счетчика инкрементируется, а из ICR1 будет считано правильное значение. Если же переполнение пришло в обработчике захвата, то тут может быть несколько вариантов
- Работа по одному периоду. Просто таймер останавливается, прерывания запрещаются, полученное значение счётчика используется для обработки.
- Работа по заданному времени измерения, т.е. когда измеряется целое число периодов. По захвату считывается ICR1 и идёт анализ окончания времени измерения. Если время измерения закончилось и нет требования переполнения, то таймер останавливается, прерывания запрещаются, полученное значение счётчика используется для обработки. Если время измерения закончилось и есть требование переполнения, то измерение продолжается до тех пор пока не будет необслуженного переполнения. Некоторые разруливают эту ситуацию анализом считанного ICR1, но мне такой анализ не нравится.

[xkp]

Может есть МК AVR с 24-битным таймер-счетчиком?

[bob1]

серия Xmega. Там 16 битные счетчики можно через систему событий соединить.

[Seriyvolk]

Может кто мучал такие дисплеи по SPI? http://www.buydisplay.com/default/i2c-2 ... w-on-black
Не могу запустить...

[xkp]

так это не SPI. это i2c.

[WiseLord]

Ну вообще-то там в перечне протоколов и SPI есть: 6800 4-bit Parallel , 8080 4-bit Parallel , 6800 8-bit Parallel , 8080 8-bit Parallel , I2C, 3-Wire Serial SPI, 4-Wire Serial SPI

[imerlin]

Да, забыл упомянуть... Хотелось бы обойтись 13-й тинькой. Но намёк я понял, спасибо!

Ну я бы попробовал бы сделать так:
при частоте 1 Гц скважность 0.4 это 0.4/0.6 сек.
при частоте 500 Гц это 0.0008/0.0012 сек

Если настроить удобным образом коэффициенты деления частот, можно будет:

инициировать таймер значением, до которого он досчитает через 0.4 сек, включить выход

прерывание таймера:
инвертировать выход
загрузить таймер следующим значением, (для первого прохода это 0.6 сек, для второго чуть менее 0.4 и так далее)

прикидочная растактовка такая:
частота 13 тиньки 9,6 Мгц

если поделить CLKPR на 4 и таймер настроить TCCR0B на деление на 64,
то 0.0008 сек уложится 9600000/4/64*0.0008 30 тактов счетчика
0.00012 - 45
0.4 - 15000
0.6 - 22500

так как счетчик 8-битный придется в прерывании таймера вручную обрабатывать старший байт счетчика (сам счетчик грузить нулем до исчерпания старшего байта наверное)

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

Вот примерно такие прикидки, вроде тинька 13 вполне должна потянуть, еще и на что нибудь полезное время останется.

PS: можно, конечно еще понизить частоту счетчика раз так в 10, но тогда в заданные интервалы времени не будет укладываться целое число тактов на высоких частотах (500 Гц) - допустима ли такая потеря точности в задаче я не знаю.

[xkp]

13 тинька вполне подойдет для таких целей. Когда то я на 13 тиньке собирал генератор с изменяемой частотой для металлоискателя, вообще там всем запрявляла мега32, по i2c "говорила" 13 тиньке какую частоту выдавать, затем м32 спрашивала время затухания сигнала у тини85, работающюю на 20 мГц для более точных показаний. Ну так вот. 13 тинька отлично справлялась с этим!
В приложении исходный код на эту самую тьньку. Просить переписать не надо. Не буду. Так же во вложении есть лист ворда, в котором прописана формула расчета частоты на выходе мк. Вводиш частоту тактирования МК и 2 управляющих регистра и получаешь результат - частоту на выходе МК. Писался этот лист на 2007 ворде. Сейчас у меня стоит 2003 и в нем не работает. Думаю что в 2007 работать будет.

[Alexeyslav]

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

Если сумматор взять 8-битный Тогда подавая код 255 на вход сумматора он будет переполняться каждый такт, на выходе частота будет в 2 раза меньше частоты суммирования. т.е. если суммировать входное число каждую 1мс то на выходе на код 255 будет 500Гц, на код 1 будет 2 Гц. Если взять 16 бит, нижний предел частоты будет около 0.01Гц

Скважность реализовать программно. Счет настроить на 10кГц и после подсчитывать количество переполнений - после 6 переполнений устанавливаем "0" на выходе, потом после 4 переполнений устанавливаем "1". Или наоборот, по желанию.

[gauss]

Вопрос по внешним прерываниям АВР.

В даташите есть примерно такая фраза: "Внешнее прерывание сработает по спадающему фронту на входе"
Что считать этим самым спадающим фронтом? Например, будет ли им являться спад с 5 до 4.9В?