Библиотека программиста

Все, что необходимо начинающему и опытному программисту

Все принятые в технических описаниях Atmel наименования регистров и прочие необходимые константы вводят точно таким же способом и собирают в специальных файлах с расширением inc, о которых мы уже упоминали— такие файлы придаются к каждой модели контроллера (например, 2313def.inc— для модели AT90S2313, tn2313def.inc— для модели ATtiny2313, m8535def.inc — для модели ATmega8535 и т. п.). Сам ассемблер абсолютно не "подозревает" о существовании таких вещей, как PortA или DDRC, а "знает" только числовые адреса соответствующих регистров (единственное, о чем ассемблер "осведомлен от рождения", — это о существовании РОН с названиями гО— г31). Соответствие между этими мнемоническими обозначениями и адресами и устанавливается с помощью inc-файлов, причем для разных моделей эти адреса могут различаться. Для того чтобы включить эти соответствия в текст вашей программы, и служит директива include:
.include "2313def.inc"

В данном случае подключается файл с определениями констант и адресов для контроллера AT90S2313 (разумеется, если файл находится не в текущем каталоге, то следует указать полный путь). Подобной строкой должен начинаться текст любой AVR-программы, иначе ассемблер может вас "не понять". Разумеется, директивой include можно вставить в ваш текст содержимое любого другого файла, например, содержащего типовые процедуры (и мы этим будем широко пользоваться). Имя файла здесь может быть абсолютно произвольным — по директиве include компилятор, "не думая", разыщет файл с указанным именем (напомним, что он должен находиться в текущем каталоге, или для него должен быть указан полный путь), скопирует из него текст и вставит этот текст в том месте вашей программы, где расположена директива. И только потом начнет разбираться. Потому с директивами include следует быть аккуратным — если файл содержит команды, а не только определения, то вставлять его нужно уже не в начале текста, а после всех векторов прерываний (см. далее), иначе выполнение программы начнется с него. Довольно полезна директива device, которая ставится в начале программы и отдельно указывает ассемблеру на применяемую модель МК:
.device AT90S2313

Если inc-файлы указывают ассемблеру на истинные адреса регистров для конкретной модели, то эта директива не позволит использовать команды, которые данной моделью не поддерживаются, например, если вы попробуете применить команду push для моделей Tiny с аппаратным стеком, то компилятор выдаст сообщение об ошибке. Ясно, что если вы будете внимательно читать описание перед работой с конкретным устройством, то эта директива не потребуется.
Разберем еще директиву .db (define byte), которая позволяет хранить константы как во flash-памяти программ, так и в EEPROM. Для того чтобы показать, куда именно писать данные, совместно с .db можно указать директиву .eseg (для EEPROM). Если эта директива отсутствует, то без специальных указаний данные по директиве .db будут сохраняться в памяти программ (пример см. в разделе "Команды пересылки данных" главы б). Если же они используются, то для указания того, что область данных EEPROM в тексте закончилась и следует опять перейти к памяти программ, необходимо поставить директиву .cseg (code segment). Естественно, располагать в зоне действия директивы .eseg что-либо, кроме констант, определенных директивой .db, бессмысленно. Все сказанное иллюстрируется, например, фрагментом текста, заимствованным из "аппноты" Atmel № 240 (листинг 5.3).

Применение директивы .org мы рассмотрим далее в этой главе, а здесь только отметим следующее. Согласно листингу 5.3, все, что перечислено через запятую после директивы .db, будет помещено в область EEPROM, начиная с нулевого адреса. Если директивой .org этот нулевой адрес не указывать, то размещение будет осуществлено все равно с него, за исключением случая, когда где-то еще в тексте ранее встречалась директива . eseg, тогда размещение произойдет по порядку адресов. То же самое относится и к директиве .org о в сегменте кода— если это самое начало программы (как показывает здесь наличие в первой строке вектора сброса), то ее ставить необязательно.

Отметим, что содержимое EEPROM для контроллеров AVR предлагается загружать через отдельный файл того же формата (hex), как и для кода программы. Для того чтобы такой файл создавался при наличии директивы .eseg в коде программы, требуется указать специальную опцию компилятора, тогда строка в нашем bat-файле (см. раздел "Обустройство ассемблера" данной главы) будет выглядеть так:
c:\avrtools\avrasm32 -е %1.еер -fl %l.asm
В этом случае в той же папке, где находится hex-файл, создастся файл с расширением еер, который будет содержать данные для загрузки в EEPROM.

Если директива .eseg в тексте программы не встречается, то в созданном еер-файле данных не окажется, и он будет автоматически-удален компилятором по окончании процесса.
Заметим, что кроме .db, имеется еще директива .dw, которая позволяет располагать данные в памяти программ или EEPROM сразу двухбайтовыми словами.
Для размещения данных в SRAM есть директива .dseg. Разумеется, специальных опций компилятора тут не требуется, зато почему-то данные по директиве'.dseg помечаются не директивой .db (или .dw), a .byte, которая имеет иной синтаксис — после нее должна идти константа, указывающая число резервируемых байтов. Других параметров не допускается, потому .byte может применяться только для выделения места под переменные в SRAM, но не для инициализации ее содержимого.
К тому же есть некоторая путаница с адресацией в отношении SRAM — счетчик адресов здесь по умолчанию равен не нулю, как в других случаях, а 32 (поскольку адреса 0-31 заняты РОН), но с этого адреса вообще-то начинается файл регистров ввода-вывода, а не собственно SRAM. Все эти неудобства приводят к тому, что такой способ загрузки данных используют значительно реже остальных— по сути единственное преимущество в том, что нам не приходится думать в процессе программирования об адресах в SRAM, а можно просто располагать данные по метке (причем адресация здесь побайтовая, а не пословная, как в памяти программ). Это облегчает жизнь, например, при переходе от одной модели МК к другой. Но заполнять память конкретными значениями все равно приходится программно, так что много мы не выигрываем.

<< Назад         В начало         Далее >>

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru