.def temp = r16 ;регистр r16 есть переменная temp
.def counter = r16 ;регистр r16 есть переменная counter
Изменение temp будет автоматически означать изменение counter и наоборот. Иногда этим пользуются, если в разных частях программы один регистр применяется для разных по смыслу вещей (и вы можете встретить такие примеры в фирменных «аппнотах»). В общем случае к такой возможности следует прибегать лишь в исключительных случаях — слишком много ошибок можно наделать.
С помощью директивы equ, вообще говоря, можно определять довольно сложные выражения, но этим пользуются редко, гораздо чаще ее применяют для определения переменных, которые располагаются не в регистрах, а в области SRAM. Например, следующая последовательность директив и команд запишет содержимое регистра counter в SRAM по адресу $60 (для большинства моделей, кроме старших Mega, это первый свободный адрес после занятых адресами регистров):
.equ memory_address = $60
…
clr ZH
ldi ZL,memory_address
st Z,counter
В заключение темы еще раз напомним, что имена переменных (как и команд, и меток) нечувствительны к регистру букв, что еще один плюс для AVR-ассемблера по отношению к языку С, где они по умолчанию различаются, и у начинающих это приводит к множеству ошибок.
С некоторыми командами мы уже познакомились, но еще не знаем толком, что они означают. Теперь я постараюсь разобрать основные команды и их использование. Подчеркну, что речь идет только о части самых употребительных и концептуально важных команд, потому что всего команд для AVR от 90 до 133 (в зависимости от контроллера), и только их подробное описание, например в [2], занимает почти 70 страниц, гораздо больше, чем описание собственно AVR-ассемблера. С теми командами, которые выпадут из рассмотрения здесь, мы познакомимся по ходу дела в дальнейшем. Выборочный перечень базовых команд с их описанием, достаточный для составления большинства законченных программ, вы также найдете в Приложении 4. Однако в любом случае при написании собственных программ вам будет необходимо иметь справочник по командам, в роли которого может выступать как [1, 2], так и англоязычный документ PDF с описанием конкретного контроллера, который легко добывается с сайта Atmel. Учтите, что в неофициальных пособиях могут быть ошибки, так в [1, 2] они встречаются в достаточном количестве, хотя в последних изданиях их, возможно, и исправили.
Формат команды
Прежде всего, заметим, что команды (инструкции, операции — мы будем употреблять эти слова как синонимы) контроллера записываются в определенном формате. Сначала идет собственно мнемоническое название команды, которое может состоять из двух (ld, st), трех (mov, ldi, sei, add) или четырех (breq, brne, sbiw) символов. Затем после пробела (любого их числа, допустимы также знаки табуляции), если это предусмотрено форматом команды, идут операнды: имена регистров или константы (а также выражения), над которыми производится операция (на самом деле это не имена, а адреса, но мы не будем забывать про включение inc-файлов и создание собственных определений, и оперировать только с именами, так будет гораздо меньше ошибок).
Если операндов два (больше не бывает), то они перечисляются через запятую (с любым числом пробелов до или после нее, или вообще без них). Причем тут действует важное правило: во всех ассемблерах второй операнд является первым по смыслу действия (т. е. источником), а первый — приемником (результатом). Например, команда ldi temp, 1 расшифровывается, как «загрузить единицу в регистр temp», а операция sub temp, counter вычитает counter из temp, а не наоборот, и результат помещает также в temp.
Заметки на полях
Такая запись (действие— приемник— источник) стандартна для всех ассемблеров, и называется прямой польской записью: когда сначала просят налить чай (действие), потом указывают, в какой стакан (первый операнд, он же результат), и только после этого сообщают, где находится чайник (второй операнд). В отличие от обычной инфиксной, когда сначала указывается стакан (первый операнд), в который нужно налить чай (действие), ах да, вот из этого чайника (второй операнд). Если кто-то пробовал пользоваться некоторыми старыми моделями настольных калькуляторов, то там использовалась обратная польская запись, когда сначала указываются оба операнда, а потом действие (стакан и чайник, затем указывается, что нужно налить из второго в первый). Это наиболее удобно для компьютерных устройств (потому что позволяет без лишних сложностей реализовать операции вычисления по формулам со скобками любой степени вложенности), но отнюдь не для человека, т. к. счет на таких калькуляторах требовал специальной тренировки. В то же время ассемблерный порядок операндов обычно не доставляет трудностей при обучении, и довольно логичен: сначала главный операнд, который будет изменяться, а потом тот, с помощью которого и производятся изменения.
Выходные файлы
Есть, конечно, команды, которые вообще не требуют операндов (как уже знакомые нам пор или sei), или используют всего один операнд (cir), но вне зависимости от этого каждая команда AVR будет занимать в памяти ровно два байта (кроме немногих команд, вроде упоминавшейся jmp, которые работают с операндами большого размера, оттого занимают четыре байта). Такое готовое представление — командное слово, или код операции (КОП) — и записывается в виде числа компилятором в выходной файл, имеющий расширение hex, который необходим программатору для дальнейшей записи в контроллер. Кроме HEX-файлов, есть еще и другие форматы записи готовых программ (самый известный — бинарный), но hex-формат для микроконтроллеров самый распространенный, и мы будем рассматривать только его.
Рассматриваемый НЕХ-формат придуман фирмой Intel (есть и другие «гексы»). Отличается такой формат тем, что содержит числа в текстовом представлении (в шестнадцатеричной записи). Поэтому в случае чего его можно даже править в обычном текстовом редакторе (что исключено для бинарных файлов, содержащих числа, а не символы). Кстати, точно в таком же формате осуществляется запись констант в EEPROM, если это требуется.
Рассмотрим НЕХ-формат подробнее. На рис. 13.6 представлен файл короткой программы, открытый в обычном Блокноте. На первый взгляд тут «сам черт ногу сломит», но на самом деле все достаточно просто, хотя чтение затрудняется тем, что строки не поделены на отдельные байты. Разбираться будет проще, если вы скопируете этот файл под другим именем и расставите в нем пробелы после каждой пары символов. Мы же рассмотрим данный файл как есть.
Рис. 13.6. Файл формата HEX в Блокноте
Основную часть файла занимают информационные строки, содержащие непосредственно КОП. Они состоят из ряда служебных полей и собственно данных. Каждая строка начинается двоеточием, после которой идет число байт в строке. Кроме первой и последней, везде стоит, как видите, число 10 (десятичное 16), т. е. в каждой строке будет ровно 16 информационных байт (исключая служебные). После количества байт идет два байта адреса памяти, указывающие куда писать (в первой строке 0000, во второй это будет, естественно, 0010, т. е. предыдущий адрес плюс 16, и т. д.). Наконец, после адреса идет еще один служебный байт, обозначающий тип данных, который в информационных строках равен 00 (а в первой и последней — 02 и 01, о чем далее). Только после этого начинаются собственно байты данных, которые означают соответствующие КОП, записанные пословно (КОП для AVR, напоминаю, занимают в основном два байта, и память в этих МК также организована пословно), причем так, что младший байт идет первым. Таким образом, запись в первой информационной строке «ЗАС0» в привычном нам «арабском» порядке, когда самый старший разряд располагается слева, должна выглядеть, как СОЗА (если помните, я в главе 7 упоминал об этой несуразице).
В первой строке служебный байт типа данных равен 02, и это означает, что данные в ней представляют сегмент памяти, с которого должна начинаться запись (в данном случае 0000). Заканчивается hex-файл всегда строкой «:00000001ff» — значение типа данных 01 означает конец записи, и данных больше не ожидается. А что означает FF?
Самым последним байтом в каждой строке идет контрольная сумма (дополнение до 2) для всех остальных байт строки, включая служебные. Алгоритм ее вычисления очень простой: нужно вычесть из числа 256 значения всех байтов строки (можно не обращая внимание на перенос), и взять младший байт результата. Соответственно, проверка целостности строки еще проще: нужно сложить значения всех байтов (включая контрольную сумму), и младший байт результата должен равняться нулю. Так, в первой строке число информационных байтов всего два (первое значение в строке), плюс служебный байт типа данных, равный также двум, итого контрольная сумма всегда равна 256 — 2–2 = 252 = $FC. В последней строке одни нули, кроме типа данных, равного 1, соответственно, контрольная сумма равна 256 — 1 = 255 = $FF.
Теперь попробуем немного расшифровать данные. Первое слово в первой информационной строке, как мы выяснили, равно $С03А. Если мы возьмем фирменное описание команд, то обнаружим, что значению старшей тетрады в КОП, равной $С (1100 в двоичной системе), соответствует команда rjmp, но ведь так и должно быть, мы же договорились, что любая программа начинается с безусловного перехода на метку RESET. Теперь очевидно, что остальные биты в этом значении ($03А) представляют абсолютный адрес в программе, где в ее тексте стояла метка reset. Попробуем его найти, для этого вспомним, что адреса отсчитываются по словам, а не по байтам, т. е. число $ЗА (58) надо умножить на 2 (получится 116 = $74), и искать в этой области. Разыщем строку с адресом $0070, отсчитаем три пары байт от начала данных, и найдем там фрагмент «F894», который в нормальной записи будет выглядеть, как $94F8, а это, как легко убедиться по справочнику, есть код команды