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

[BOB51]

ldi r30,0xdf
ld r20,r30

...

Где Вы откопали
ld r20,r30
???

Вторым регистром в команде LD может быть указан X, Y или Z
или как слэнг первый регистр регистровой пары - в данном случае R31 (но уж никак не R30)

шпора AVR.pdf

(60.25 КБ) 165 скачиваний

[GoldenAndy]

LD на вход требует не имя регистра, а имя регистровой пары
Причем это имя может быть только X, Y или Z, оно там в команде кодируется всего двумя битами.
И оно захардкоджено прямо в асме, как и регистры R0-R31



R26-R31 переопределены как XL,XH,YL,YH,ZL,ZH в регистрово-битовых определениях контроллера

[BOB51]

Однако все, что указано в *.inc файлах может быть переопределено пользователем в прикладной программе (дополнительный файл определений).

и вот еще момент...
допустим мне форма

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

ld r16,z 

не сильно нравится...
тогда

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

#define pointer_2 z
#define tmp0 r16

и в самой программе

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

ld tmp0,pointer_2

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

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

; ***** CPU REGISTER DEFINITIONS *****************************************
.def	XH	= r27
.def	XL	= r26
.def	YH	= r29
.def	YL	= r28
.def	ZH	= r31
.def	ZL	= r30

переопределяем не регистр, а его ранее выполненное определение

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

#define ptrd_h XH
#define ptrd_l XL

и далее уже используем ptrd_h вместо XH (но никак не вместо Х !!!)

[GoldenAndy]

BOB51, не путайте вопрошающего

[BOB51]

Его запутаеш!

[главный колбасист]

ld r20,Z

Так получается. ошибок нет.

Добавлено after 9 hours 11 minutes 29 seconds:

Где Вы откопали
ld r20,r30
???

Это я сама придумала. что с меня возьмешь.

Вообще хотелось по ходу цикла вычищать содержимое и без того небольшой озу ,в случае использования rcall вместо rjmp, чтобы
не переполнялся стек,и через полминуты работы симулятора не выскакивала ошибка переполнения.
Бред,конечно. не обессудьте...

[BOB51]

Переполнение стека обусловлено несоответствием количества переходов rcall количеству возвратов ret (или прерываний - по сути те же rcall только аппаратными средствами с возвратом по reti).
Симулятором причину прекрасно можно отследить. Как само значение в указателе стека, так и того, что в стек попадает.

[dgrett]

Ничего не понял. Вы что-то не так делаете.

[главный колбасист]

Ничего не понял. Вы что-то не так делаете.

Конечно я не так все делаю. Я вообще не понимаю что я тут делаю.(в этой реальности)

Ааа... ret у меня вообще ни одной строчки нет.Значит надо вставить ret и этот геморрой закончится?

[BOB51]

Каждому rcall по своему ret.
И каждому прерыванию по личному reti.
Тогда все довольны будут.

[a1000]

[uquote="главный колбасист",url="/forum/viewtopic.php?p=4155615#p4155615"]Ааа... ret у меня вообще ни одной строчки нет.Значит надо вставить ret и этот геморрой закончится? [/uquote]
Мне даже стало интересно, как-же вы из подпрограмм возвращаетесь?

[GoldenAndy]

главный колбасист, в вашей задаче чтения данных из 3231 достаточно было обойтись парой вложенных циклов и ветвлений. код получился бы достаточно компактный, но при этом гораздо более читаемый и без повторений одинаковых операций в разных местах...
А вот так запутанно бегать по коду - вы и сами запутаетесь, и код будет нечитаем. И ошибку с ACK/NACK легко можете пропустить.
Ну и экономия ОЗУ актуальна только если оно вам нужно для обработки большого массива каких то данных... Обычно программная память кончается быстрее Соответственно, код лучше оптимизировать. Например, вот так:

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

1.  Настройка i2c
2.  i = 0
3.  IIC_START i2c
4.  IIC_SEND (3231_ADDR+i)
5.  if (i = 0) 
    then begin
6.       IIC_SEND 0x00 ;адрес, с которого мы будем читать данные из 3231
7.       goto 16
         end
    else begin
8.       j = 7 ; число байт, которые надо прочитать
9.       Z = (адрес области памяти для чтения из 3231)
10.      j = j - 1
11.      if (j > 0) then IIC_READ_ASK
                    else IIC_READ_NASK
12.      save DATA -> Z
13.      Z = Z + 1
14.      if (j > 0) then goto 10
15.      end ; конец блока else для if (i=0)
16. i = i + 1
17. if ( i < 2 ) then goto 3
18. IIC_STOP   

Я вот тут вам как то накидал в псевдокоде алгоритм чтения данных из 3231 (это "перепевка" из какой то из моих старых программ... Написана на некоем подобии языка высокого уровня, что бы было легче разобраться)

Обратите внимание, в строке 4 адрес 3231 должен задаваться в 8-битном формате - 1101000х (0xD0) - тогда для записи, когда i=0 - как раз уйдет адрес с режимом записи 11010000, а когда i станет 1 - по шине уйдет адрес 11010001 - режим чтения. Т.е. не нужно писать 2 отдельных блока для отправки адреса для записи и адреса для чтения.

Точно так же старт и повторный старт выполнятся в одном месте.

По использованию ОЗУ - нужно только 7 байт для данных из 3231, а так же 2 байта стека для вызова подпрограмм общения с i2c.
По регистрам - ZL/ZH на ссылку в ОЗУ, 2 регистра для i,j - переменных цикла, да пара временных регистров для общения с i2c

IIC_START, IIC_SEND, IIC_READ_ASK, IIC_READ_NASK, IIC_STOP - это подпрограммы работы с модулем i2c для вашего МК. Должны вызываться посредством CALL/RCALL

Сам блок работы с i2c

Спойлер

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

;--------------------------------------------------------
; I2C Code
;--------------------------------------------------------
; по мотивам DiHalt'a
;--------------------------------------------------------
; Работа с IIC передатчиком. Предупреждаю -- это быдлокод!
; Несмотря на то, что так делают почти все :) 
; Но это медленно и тормозно, особенно в свете использования
; RTOS. Почему? Да потому что использует глухое
; ожидание флага готовности IIC. Вместо того, чтобы отдать 
; управление диспетчеру задач. Также нет обработоки ошибок
; и какой либо оценки прошла команда или нет. Просто пример!
;---------------------------------------------------------
; IIS_START — устраивает на шине Start состояние
; IIC_SEND — посылает байт, просто байт. Не важно что это — адрес, данные…
; IIC_READ_ASK — команда противополжная предыдущей — принимает байт в конце дает ACK
; IIC_READ_NASK — тоже принимает байт, но в конце дает NACK, используется для приема последнего байта, 
; 	             чтобы дать понять Slave устройству что мы в его услугах больше не нуждаемся.
; IIS_STOP — устраивает на шине Stop состояниеи освобождает линию
;---------------------------------------------------------
; Последовательность инициализации TWI (i2c)-интерфейса
; Рассматривается только Master-режим
; В регистр TWBR, а так же в биты 0,1 (TWPS0:1) регистра TWSR записываются константы для определения скорости шины.
; (констатны можно рассчитать на AVRCalc)
;---------------------------------------------------------
; Последовательность чтения для IIC, на примере обычной EEPROM типа АТ24Схх обычно такая:
;	Старт
;	Адрес дейвайса[write]   
;	Адрес ячейки откуда будем читать
;	Повторный Старт,
;	Адрес девайса [read],
;	Байт из адресованой ячейки,
;	Байт из адресованой ячейки+1,
;	Байт из адресованой ячейки+2
;	….
;	Cтоп
;
; Последовательность записи для IIC обычно такая:
;	Старт
;	Адрес девайса [write]
;	Адрес ячейки куда будем писать
;	Данные раз
;	Данные два
;	Данные три
;	…..
;	Стоп
;  [write] & [read] - младший бит адреса. =0 - запись, =1 - чтение
;
;---------------------------------------------------------
; примеры для работы с часами - см. http://easyelectronics.ru/chasy-realnogo-vremeni-pcf8583.html

;---------------------;


; Даем старт на линию I2C
; Портит R16,SREG
IIC_START:
			LDI 	R16,1<<TWINT|1<<TWSTA|1<<TWEN|0<<TWIE
			OUT	TWCR,R16
IIC_S:		
			IN	R16,TWCR
			ANDI	R16,1<<TWINT			
			BREQ	IIC_S			; Ждем пока передатчик IIC выполнит старт
			RET

;-----------------------------------------------------------------------------
;Посылаем байт (R16) по IIC 
; Портит R16,SREG
IIC_SEND:  	
			OUT	TWDR,R16
			LDI 	R16,1<<TWINT|1<<TWEN|0<<TWIE
			OUT	TWCR,R16
IIC_B:		
			IN	R16,TWCR
			ANDI	R16,1<<TWINT	; Ждем пока передатчик пошлет байт			
			BREQ	IIC_B
			RET

;-----------------------------------------------------------------------------
; Принять байт. 
; Принятый байт в R16
; Портит SREG
IIC_READ_ASK:
			LDI		R16,1<<TWINT|1<<TWEN|1<<TWEA|0<<TWIE
			OUT	TWCR,R16
IIC_R:		
			IN	R16,TWCR
			ANDI	R16,1<<TWINT			
			BREQ	IIC_R			; Ждем пока байт будет принят
			IN	R16,TWDR
			RET

;-----------------------------------------------------------------------------
; Принять последний байт. Помните я писал о разнице между просто байтом и последним
; байтом? В последнем байте не генерируется ACK!!!
; Принятый байт в R16
; Портит SREG

IIC_RREAD_NACK:
			LDI 	R16,1<<TWINT|1<<TWEN|0<<TWEA|0<<TWIE
			OUT	TWCR,R16
IIC_R2:		
			IN	R16,TWCR
			ANDI	R16,1<<TWINT	; Ждем пока байт будет принят		
			BREQ	IIC_R2
			IN	R16,TWDR
			RET

;-----------------------------------------------------------------------------
; Сгенерировать STOP
; Портит R16,SREG
IIC_STOP:	
			LDI R16,1<<TWINT|1<<TWSTO|1<<TWEN|0<<TWIE
			OUT	TWCR,R16
IIC_ST:		
			IN	R16,TWCR
			ANDI	R16,1<<TWSTO			
			BREQ	IIC_ST			; Ждем пока не будет готов стоп.
			RET

[a1000]

Я так понял, что предыдущий пост адресован мне.
Да, я видел такую реализацию у DI HALT. Но он сам-же писал о таком методе

Работа с IIC передатчиком. Предупреждаю -- это быдлокод!
Несмотря на то, что так делают почти все
Но это медленно и тормозно, особенно в свете использования
RTOS. Почему? Да потому что использует глухое
ожидание флага готовности IIC.

Я не спорю, метод простой, рабочий и широко распространённый. Но я занимаюсь программированием не для комерции, а ради высокого искусства. Вот захотелось сделать на прерываниях, а оно для I2C одно. Вот и сгородил такой лабиринт.
А на счёт памяти вы правы. Пишу для ATmega8 и HEX уже 6,6 KB. А хотелось ещё DS18B20 прикрутить. Наверное прийдётся на 328 мегу перейти.

[GoldenAndy]

a1000, отвечал я колбасисту.
Таки да, ответ вам должен быть. А то я попутал по кучке ответов.

а код либы - да, по мотивам ДиХальта. Там половина копипасты, я там что то под себя вроде переписывал.. Заголовок, судя по всему, ДиХальтов. Может и всё его - 7 лет прошло, не помню.
Я тогда изучал АВРки и их ассемблер.
И большинство чужих либ изучал и переписывал под себя.

Добавлено after 42 minutes 58 seconds:
a1000, по обработке прерывания от i2c - у того же ДиХальта был развесистый такой алгоритм обработки прерывания в зависимости от статусного байта.
Для спортивного интересу - да, можно i2c обрабатывать прерыванием. но выигрыш от этого?
1 байт на 400 кГц передается за 8+1 тактов. Или за 2.5 мкс * 9 = 22,5 мкс.
За 22.5 мкс МК на частоте 8 МГц выполняет условно 180 команд. Это если не считать условных и безусловных переходов и двухсловных команд.
Из которых вы потратите, (если мне не изменяет память) по 4 такта на вход в прерывание и выход из него. Потом нужно сохранить SREG и какой то из регистров. Еще 3 такта. Еще сохранить ZL:ZH - это указатель для ваших сохранений данных из TWDR. Т.е. 5 тактов сохранения, 5 восстановления регистров.
Дальше реализация этапов чтения - у не думаю, что менее 20-30 тактов уйдет... Т.е. на обработку прерывания будет тратиться ну не менее 40-50 тактов. Из 180.
Т.е. при 8 МГц у вас между прерываниями будет 12-15 мкс.
Ради спортивного интереса - да, можно работать с прерыванием.
А так - я бы не заморачивался и сделал на ожиданиях. Обычно i2c-устройства - это не plug'n'play, а запаянные на плату конкретные устройства. И при исправности всех устройств обмен по шине не должен выдавать ошибки. Соответственно, цикл обработки упрощается.
В ожиданиях, если вдруг что, можно сделать не бесконечное ожидание, а конечный цикл, однобайтовый, от 0xFF до 0x00. И отдавать флаг ошибки, если цикл досчитал до 0. Ибо передача/прием байта занимают 180 или 360 тактов (8 или 16 МГц тактовой). а цикл ожидания будет длиться дольше.
Если уже параллельно процессу обмена нужно что то выполнять, то можно делить обмен по i2c на этапы - старт, отправка адреса записи, отправка стартового адреса, повстарт, отправка адреса чтения, чтение байта 1, чтение байта 2, ...., чтение байта 7, стоп.
И выполнять эти этапы раздельно, а между этапами параллельные операции.

Касательно 18B20 - я думаю, что при правильном подходе там обмен уложится байт в 200-300-400. Там же важно выдерживать только 3 тайминга - резет 480 мкс и чтение presence / чтение-запись бита - 15+45 мкс.
Опять же, если не не использовать UART, то проще всего эти задержки делать на тупых циклах.

[BOB51]

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

[ARV]

Обычно i2c-устройства - это не plug'n'play, а запаянные на плату конкретные устройства. И при исправности всех устройств обмен по шине не должен выдавать ошибки.

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

Если уже параллельно процессу обмена нужно что то выполнять

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

проще всего эти задержки делать на тупых циклах

и тут согласен на все 100%.

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

[GoldenAndy]

ни коллизий, ни потерь битов в правильно сконструированном девайсе на шине I2C быть не может!

Ну, тут нужно заложить какой то гипотетический случай на выход из строя i2c-ведомого устройства.... Но с этим прекрасно справится таймаут ожидания - делается на одном регистре и трех ассемблерных командах (пишу по памяти, но могу и криво написать, на асме очень давно не писал, в основном голый Си)
LDI reg, 0xFF
label:
SUB reg
BRNE label

Либо проверять ACK при отправке адреса. Нету ACK - ведомый сдох, несите нового раба. Если АСК есть - то устройство на шине и дальше на тупых ожиданиях работаем.

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

У меня такое было всего один раз. Когда приходилось читать по i2c из INA219 1000 раз в сек попеременно значения тока и напряжения, класть их в буфер и обрабатывать. И это была основная задача - там действительно пришлось использовать прерывание и конечный автомат. Таймер дергал старт обмена, а конечник в прерывании i2c обрабатывал всю лог.цепочку. При этом в прерывании таймера обрабатывались значения тока и напряжения из предыдущего цикла. И это была основная задача МК. А оставшееся от всей этой кухни время - это формирование изображения для дисплея, вывод его по SPI через DMA. По второму i2c был обмен с EEPROMкой внешней, но он редкий, там настройки живут и калибровочные константы. Тут уже былл обмен на ожиданиях, ибо основная задача работает реалтаймово на прерываниях.
Ну и под это все был выбран соответствующий СТМ с частотой 72 МГц, у него 44 кб ОЗУ, что бы помнить 20 тысяч точек тока...

А про команду LD - ну слов нет... Даже в той же студии №4 есть прекрасный хелп по асму. А нет - есть курс ДиХальта, там всё русским по белому описано.

[BOB51]

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

В остальном... Глубоко лезть в возможности ассемблера обычно современные котятки не желают - сбегают на Си.
Посему многие "стандартные" приемы давно забыты.

[GoldenAndy]

BOB51, ну я тоже сбежал на Си. Но для АВР - начинал с ассемблера. Но на Си - тупо удобнее и быстрее. И зачастую - универсальнее.

[BOB51]

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