Обсуждаем контроллеры компании Atmel.
Ответить

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

Ср янв 05, 2022 20:56:29

главный колбасист писал(а):
ldi r30,0xdf
ld r20,r30
...

Где Вы откопали
ld r20,r30
???
:music:
Вторым регистром в команде LD может быть указан X, Y или Z
или как слэнг первый регистр регистровой пары - в данном случае R31 (но уж никак не R30)
8)
шпора AVR.pdf
(60.25 KiB) Скачиваний: 121

:beer:

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

Ср янв 05, 2022 23:46:33

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

Изображение

R26-R31 переопределены как XL,XH,YL,YH,ZL,ZH в регистрово-битовых определениях контроллера
Изображение
Вложения
R26-31.jpg
(11.78 KiB) Скачиваний: 431
ldi.jpg
(18.01 KiB) Скачиваний: 449

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

Чт янв 06, 2022 00:39:48

Однако все, что указано в *.inc файлах может быть переопределено пользователем в прикладной программе (дополнительный файл определений).
8)
и вот еще момент...
допустим мне форма
Код:
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 (но никак не вместо Х !!!)
8)

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

Чт янв 06, 2022 01:54:45

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

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

Чт янв 06, 2022 10:01:46

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

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

Чт янв 06, 2022 19:16:40

ld r20,Z

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

Добавлено after 9 hours 11 minutes 29 seconds:
Где Вы откопали
ld r20,r30
???
:music:

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

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

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

Чт янв 06, 2022 20:07:27

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

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

Чт янв 06, 2022 20:08:38

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

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

Чт янв 06, 2022 20:18:43

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

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

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

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

Чт янв 06, 2022 20:22:30

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

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

Чт янв 06, 2022 20:57:33

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

Мне даже стало интересно, как-же вы из подпрограмм возвращаетесь?

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

Чт янв 06, 2022 21:05:23

главный колбасист, в вашей задаче чтения данных из 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
Последний раз редактировалось GoldenAndy Пт янв 07, 2022 01:15:59, всего редактировалось 1 раз.

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

Пт янв 07, 2022 00:12:07

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

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

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

Пт янв 07, 2022 01:36:49

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, то проще всего эти задержки делать на тупых циклах.

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

Пт янв 07, 2022 11:05:36

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

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

Пт янв 07, 2022 11:13:27

GoldenAndy писал(а):Обычно i2c-устройства - это не plug'n'play, а запаянные на плату конкретные устройства. И при исправности всех устройств обмен по шине не должен выдавать ошибки.
абсолютно верно! ни коллизий, ни потерь битов в правильно сконструированном девайсе на шине I2C быть не может! и нужды в анализе этих битов нет никакой. от слова совсем.
GoldenAndy писал(а):Если уже параллельно процессу обмена нужно что то выполнять
как я неоднократно утверждал в разных других темах, реальная необходимость действительно параллельно что-то делать в любительских проектах возникает крайне-крайне-крайне редко. более того, после реализации этой "истинной" параллельности обычно оказывается, что никакого выигрыша нет вообще, только напрасно потраченное время. но это моё мнение, оно может не совпадать с мнением редакции :)))
GoldenAndy писал(а):проще всего эти задержки делать на тупых циклах
и тут согласен на все 100%.

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

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

Пт янв 07, 2022 12:49:46

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

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

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

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

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

Пт янв 07, 2022 13:03:52

Иногда полная проверка наоборот является источником ошибок.
Причем весьма долго "скрывающихся".
Тот же контроль на освобождение шины ведомым, когда после передачи адреса следует выдача данных с первым нулевым битом.
8)
В остальном... Глубоко лезть в возможности ассемблера обычно современные котятки не желают - сбегают на Си.
Посему многие "стандартные" приемы давно забыты.
:sleep:

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

Пт янв 07, 2022 13:34:32

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

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

Пт янв 07, 2022 14:01:48

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