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

akl · Сообщение **akl** » Сб апр 15, 2017 14:48:25

Alek Lem писал(а):...

Это как раз и имелось ввиду, т.к. ещё не встречал архитектуры с порядком следования байт отличным от формата младший-старший. Например, код команды LPM Load Program Memory 0x95C8 в листинге видится как 0xC895.

Спойлер

LPM.png: (18.91 КБ) 636 скачиваний

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

Реклама

Alek Lem

akl, спасибо.

Z_h_e писал(а):
Alek Lem писал(а):Ведь адрес ROM умеет отсчитывать, на сколько я знаю, только счетчик команд (регистр адреса).
Счетчик команд ничего не считывает, он хранит адрес для выборки команд.

Я и не писал, что он что-то считывает...Он считает -- поэтому и "счетчик"

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

Ок, не буду морочить голову. Теперь вопрос более прикладной. Командой .db заносится массив чисел, который в процессе работы программы, выгружается, например, в порты. Но с тем же успехом, я мог бы занести этот массив в ячейки ОЗУ (которые идут после адресов РОН и РВВ) и считывать массив оттуда.

Реклама

akl · Сообщение **akl** » Сб апр 15, 2017 14:52:05

Зачем ОЗУ, предначенном для врЕменного хранения данных использовать для хранения констант.

Alek Lem

Ясно, для экономии ОЗУ и единообразия логики работы с данными. Просто я сперва решил, что косвенная адресация -- это необходимость, а оказалось, что для удобства.

Реклама

trofim2

Из ОЗУ выборка быстрее

Реклама

akl · Сообщение **akl** » Сб апр 15, 2017 15:11:39

Да, быстрее, но всю скорость съест загрузка.

Реклама

trofim2

Так и остальное надо оптимизировать.
Копейка - рубль бережет.

BOB51

Если речь о неизменных константах - предпочтение ПЗУ, если в процессе работы программы данные изменяются - предпочтение массиву в ОЗУ. При том, что в некоторых ситуациях размещение будет равноценным (просто прийдется использовать иные наборы команд для доступа и использования данных).

trofim2

Здесь я полностью согласен, если не критично время выполнения.

Alek Lem писал(а):Я спрашивал, как именно происходит отсчет адреса в ROM побайтно командой plm ? Ведь адрес ROM умеет отсчитывать, на сколько я знаю, только счетчик команд (регистр адреса).

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

Z_h_e

Starichok51 писал(а):тем более, что есть команды длиной больше 1 слова. поэтому счетчик команд считает команды, а не слова.

Я не соглашусь с такой формулировкой. Организация памяти программ в AVR n*16. Я не видел подробной схемы организации памяти и шин AVR, но все указывает на то (по моему разумению) что шина данных для памяти программ 16 битная, возможность (физическая) чтения данных побайтно отсутствует. Считайте что ячейки памяти 16 битные. Записи побайтной тоже нет.

Т.е. счетчик команд адресует именно слова (а не считает команды) и не потому что нет команд однобайтных, а потому что ячейки памяти 16 битные. Изменение счетчика команд производит декодер команд.

Z_h_e писал(а):возможность (физическая) чтения данных побайтно отсутствует.

присутствует.
меня не волнует, как команда lpm выбирает всего один байт из программной памяти. скорее всего, точно также, как из ОЗУ - побайтно, а не из слова.
а что нет записи в программную память - это всем известно.

да, счетчик команд выбирает слова. но сколько слов он выберет, зависит от длины команды. именно поэтому он считает КОМАНДЫ, а не слова.
и в отладчике ты НИКОГДА не сможешь сделать точку останова внутри двухсловной команды.

Z_h_e

Starichok51 писал(а):присутствует.
меня не волнует, как команда lpm выбирает всего один байт из программной памяти. скорее всего, точно также, как из ОЗУ - побайтно, а не из слова.

То что программиста не должен волновать этот вопрос, я обозначал. В ДШ указано что организация памяти программ 16 битная. Равно как при 8ми битной организации, не читает ядро ниблами, так и тут не читает байтами. Кроме того, не кажется странным, что МК выбирает 16битную команду за один такт, а один байт данных читает аж за три? Точно также биториентированные команды не работают с битами по факту. Выборка байта из СОЗУ и модификация бита, запись байта обратно или Вы думаете для каждого бита есть свой адрес ? Это ж какая шина адреса должна быть?

Starichok51 писал(а):да, счетчик команд выбирает слова. но сколько слов он выберет, зависит от длины команды. именно поэтому он считает КОМАНДЫ, а не слова.

Счетчик ничего не выбирает, это всего-лишь указаетель. Этим занимается декодер команд и значение программного счетчика тоже меняет декодер команд, в зависимости от команды и ее результата.

Starichok51 писал(а):отладчике ты НИКОГДА не сможешь сделать точку останова внутри двухсловной команды

Конечно нельзя, первый раз вижу что такое можно даже обсуджать.

Starichok51 писал(а):а что нет записи в программную память - это всем известно.

Есть, но только по словно, опять же из-за 16 битной организации флеш, перед этим стирая страницы.

BOB51

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

afz · Сообщение **afz** » Ср апр 19, 2017 04:29:36

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

Z_h_e

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

BOB51

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

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

Demiurg

akl писал(а):Директива .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 битах ?