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

[BOB51]

Побайтовое чтение данных (не команд!!) для АВРок обычное дело.
Только вот... Всегда внимательно надо смотреть как на исходное содержимое указателя в Z, так и на применяемое смещение. В смысле когда непосредственно используем, а когда со смещением на один бит.
Вечное нервотрепство - НО...
ДАНЬ МК с ФИКСИРОВАННЫМ РАЗМЕРОМ КОМАНД.
Счетчик команд всегда кратен размеру команды, а доступ к данным (в основном) байту.
Разница при обращении к ПЗУ в табличном режиме заметна в случаях:
обращение к ПЗУ как к содержимому символьной строки данных (побайтовое считывание)
обращение к ПЗУ как к скоростному шифратору/дешифратору кода (побайтовое считывание)
обращение к ПЗУ как к таблице векторов (вычисляемый прерход) - пословное соответствие в случае, когда в таблице расставлены вектора (смещение вырабатывает программа) и побайтовое чтение, когда таблица содержит смещение к вектору (программа задает условие выбора смещения. том числе относительно текущего счетчика команд). Вот в последнем случае действительно мозготрепка и повышенное внимание к содержимому требуется - какой способ применить зависит от конкретики задачи.

[afz]

Вообще-то AVR-овцы конкретно лопухнулись с командами LPM. По-хорошему, надо было вместо одной LPM сделать две команды - что-то, вроде LPLB (загрузить младший байт из программной памяти) и LPHB (старший) и не морочить голову программистской общественности. Да, несколько сложнее организовать подпрограмму последовательного чтения вроде getch(), зато никаких проблем с адресами. Адрес в программной памяти был бы всегда словным, и никаких вопросов, включая и 128-К контроллеры.

[Z_h_e]

А по-моему было бы не удобно считывать некий массив данных разными командами. Возможно не хватает команды LPW (считать слово), но не вместо LPM, а плюсом.

[BOB51]

Это изначальный коммерческий "кусманчик сыра" в мышеловке (насчет "какова организация памяти") - все шустро смотрят на написанное в даташите количество килобайт...
И лишь после "прочтения с пристрастием" начинается понимание, что эта цифирь... "не совсем то"...

Насчет команд LPM - все весьма удобно.
Кому чего добавить хочется - имеем макросы самодельные (как пожелаем назвать/матюкнуть - так и будет).
Это особенность архитектуры с минимальным набором команд (да и не только -макросы всюду имеются).
Гораздо хуже некоторая разница в функционале определения значения в Z между командами
LPM и IJMP/ICALL, также использующими Z в качестве указателя адреса.
Хотя... и это в принципе преодолимо...

[Demiurg]

Директива .DB позволяет нарушить этот формат, в отличие от директивы .DW Можете попробовать.

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

//------------------------------------------------------------------------
#define tab_h(x) HIGH(x), LOW(x)
#define tab_l(x) LOW(x), HIGH(x)
//------------------------------------------------------------------------

Tab_Jmp_KBD_DRV:
.equ	MAX_FSM_KBD_DRV_STATES	= 5 // Êîëè÷åñòâî ñîñòîÿíèé àâòîìàòà.

.equ	_KEYS_INIT				= 0
.db		tab_h(Keys_Init)

.equ	_KEYS_NONE				= 1
.db		tab_h(Keys_None)

.equ	_KEYS_DOWN				= 2
.db		tab_h(Keys_Down)

.equ	_KEYS_WAIT_UP			= 3
.db		tab_h(Keys_Wait_Up)

.equ	_KEYS_UP				= 4
.db		tab_h(Keys_Up)

[trofim2]

Кто предложит расчет логарифма 16 бит на асме ?

[Jack_A]

Вопрос из серии "на деревню - дедушке" . Двоичный, десятичный, натуральный ? Логарифм имеет практический смысл для float арифметики, а какая float на 16 битах ?

[trofim2]

Какая разница "Двоичный, десятичный, натуральный", если легко масштабируется.
А почему логарифм не имеет смысла для целых чисел?

[BOB51]

Ассемблер не СИ и не какой другой "более высокоуровневый" язык - здесь не так легко формулы высшей математики применять - надо до уровня примитива "единичек-ноликов" опускаться или спецалгоритмы жестко привязанные к конкретной задачке применять.
Особо ежли имеем дело с ограниченными ресурсами МК в отношении объемов памяти.

[oleg110592]

[uquote="trofim2",url="/forum/viewtopic.php?p=3105191#p3105191"]расчет логарифма 16 бит на асме ?[/uquote]
может пригодится
в примерах Алгоритм Билдера есть библиотека Геннадия Кабардина. Cодержит:
- пример реализации алгоритмов вычисления натурального логарифма
http://algrom.net/lib-r.html

Состав пакета:
1) Каталог «Stack_machine» содержит файлы с модулями, обеспечивающим работу с вещественными числами в среде стековой машины, и программу «fish.alp», в которой показан пример реализаций функций Ln и Exp.
2) Файл «описание_Stack_machine.doc» содержит описание функций для работы с вещественными числами и в среде стековой машины.
3) Каталог «Ln_Exp» модель реализации функций Ln и Exp в Delphi, которая переносится в программу «fish.alp».
4) Файл « Из Википедии.doc» содержит алгоритм нахождения Ln для любого целого положительного числа.
5) Программа «Test3Float.exe» позволяет преобразовать вещественное число из шестнадцатеричного представления в десятичное.

[Jack_A]

А почему логарифм не имеет смысла для целых чисел?

Да потому что и для целых чисел логарифм будет вещественным. Точнее, не будет никаким, потому что если, к примеру, в Дельфи попытаемся вычислить ln(n), где n - целое, то компилятор выдаст ошибку - несоответствие типов. Или же автоматически приведет тип int к extended. Ну нет в библиотеке логарифмов от целых. Например, log2 (7) - сколько будет ? А log2 (7.0) - пожалуйста. Ну а "масштабирование" для других оснований - это в чистом виде плавающая арифметика.

[trofim2]

Согласен, неверно выразился.
Имел ввиду число с фиксированной точкой типа 1.15 в диапазоне от 1 до 2 (почти), результат для LOG2 в диапазоне от 0 до 1.

[Jack_A]

Опять же непонятен формат представления аргумента и результата. Покажи на паре примеров - что на входе и что хочется на выходе. Чувствуется, что число разных значений будет небольшим и сведется к кратенькой таблице, без всяких алгоритмов и п/п . Какая точность нужна? Хотя раз речь о 2 байтах - какая уж там точность... И результат не от 0, а от 0,20163 .
Для дела надо или для баловства (зачета) ?

[trofim2]

Аргумент от $8000 до $FFFF, на выходе логарифм. Доработка милливольтметра для непосредственного отсчета в дБ.
Кратенькая таблица на получится, а после последнего зачета прошло более 40 лет.

[Z_h_e]

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

[trofim2]

Этим и занимаюсь.
Есть такая книжка "Вычисление элементарных функций в ЭКВМ", вроде получается неплохо.

[AQ29]

[uquote="Jack_A",url="/forum/viewtopic.php?p=3106011#p3106011"]Какая точность нужна? Хотя раз речь о 2 байтах - какая уж там точность.[/uquote]
Ежели писать на нормальном макроассемблере, думаю, без труда получите требуемую точность.
Вот пример.
Логарифм вызывается одной командой. Аргумент и результат логарифма - двухбайтные переменные Точность - 0,5 %, диапазон - в 64 раза (от 1024 до 64000 с копейками). Думаю, без проблем можно получить и большую точность, скажем, 0,1 %, только нужен доступ к соответствующей расчётной программе.
Думаю, в основном, ответы по теме логарифма не связаны с профессионалами, пишущими на макроассемблере.

[Jack_A]

Давно такого потока сознания на форуме не наблюдал... Особенно впечатлило :

только нужен доступ к соответствующей расчётной программе.

Так вроде ТС и ищет эту "соответствующую расчётную программу"
Или:

Логарифм вызывается одной командой.

я даже подозреваю, эта команда CALL - вызов соответствующей подпрограммы. Вот и выдал бы человек, учитывая его космических высот квалификацию, текст проги - на посрамление нам, неразумным.
trofim2 - $8000 - это 1, $FFFF - это 2 ? Логарифм $0000 ... $FFFF - это 0..1 ?
Согласен с Z_h_e : таблица на несколько опорных точек, в промежутках - апроксимация. И насколько я понял, тут нужен не логарифм, а антилогарифм: для заданного отсчета в дБ ищем точку, куда его поместить на линейной шкале.

[trofim2]

Логарифм получил с достаточной, для меня, точностью. Разбираюсь с масштабированием.
Где то так:


; input ah:al = $8000 .. $FFFF
; out ah:al = 0 .. $3FFF


Log_2:
pushw Z
pushw X
pushw B
push cl
ldiw Z,(TablLog2*2)
ldiw X,(1<<15)
clr rl
clr rh
ldi cl,16
lgrt_a: movw bl,xl
ldi Tmp,17
sub Tmp,cl
lgrt_b: lsrw B
djnz Tmp,lgrt_b
addw X,B
brcs lgrt_e
cpw X,A
brcs lgrt_c
lgrt_e: subw X,B
adiw zl,2
rjmp lgrt_d
lgrt_c:
lpmw B,Z+
addw R,B
lgrt_d: djnz cl,lgrt_a
movw al,rl
pop cl
popw B
popw X
popw Z
ret


TablLog2:
.dw 9583,5274,2784,1433 ;16383*Lg(1+(1/2)^^(i+1))/lg(2) i=0..15
.dw 727,366,184,92
.dw 46,23,12,6
.dw 3,1,1,0

[Jack_A]

Что-то не могу понять - какого МК это ассемблер и что он делает в теме про AVR?

Логарифм получил с достаточной, для меня, точностью.

Кстати, точность -- по заявлению авторов -- или алгоритм откомпилирован и проверен в симуляторе, подтвердив заявленную точность ?
Ну, успехов, земляк
Прибор с цифровым отсчетом ? Ну тогда точно нужен логарифм, а не анти- . Признаю.
К слову: код оформлен ужасно, точнее, никак не оформлен, потому читать его захочет только очень мазохист.