но, по крайней мере, создавать «с нуля», не используя уже готовые модули. Но даже если вы в конце концов перейдете на С, советую эту книгу все же изучить до конца, чтобы познакомиться с AVR, а сам язык в приложении к AVR неплохо изложен в [4].
В этой книге вы встретите только ассемблерные программы. Мы ведь не будем писать для AVR операционные системы, и к тому же максимально попытаемся использовать готовые модули. А разобраться в работе этих модулей, когда они представлены в виде «голых» команд процессора, значительно проще. Не будем мы здесь и разбирать работу в AVR Studio — бесплатном пакете от Atmel, предназначенном для отладки программ[10] (впрочем, программы на ассемблере в нем можно и создавать, а вот на С — только отлаживать, если нет дополнительного компилятора из перечисленных ранее). Вообще-то этот пакет в некоторых случаях оказывается очень целесообразен, особенно в совокупности с различными отладочными модулями (т. н. «китами», Kit’s, которые, в отличие от самого пакета, отнюдь не бесплатны). В нем удобно отлаживать сложные линейные (т. е. не использующие прерываний) процедуры, например, какое-нибудь деление четырехбайтных чисел. И если у вас хватит терпения и усидчивости, чтобы разобраться с еще одной «прослойкой» между вами и микросхемой, то вы ничего не потеряете. Но я не буду загромождать книгу не столь обязательными описаниями промежуточного софта, созданного исключительно для удобства, а покажу, как можно любую вашу схему превратить в отладочный модуль без лишних сложностей. Если вы заинтересовались AVR Studio, то вам сюда [3].
Заметки на полях
Автор этих строк — приверженец стиля разработки программ, который подозрительно напоминает широко известную в программистской среде «разработку, управляемую тестированием». Индустрия ПО приучает программистов к иному стилю: условно говоря, когда все создается «на бумаге». Сначала утверждается общий проект (для чего даже есть специальные люди — программные архитекторы), рисуются блок-схемы, разные программисты пишут отдельные куски кода (отлаживая их, конечно, но только «теоретически», без привязки к реальной рабочей среде), потом это объединяется в некий «проект», наконец, собирается альфа-версия и начинается тестирование готовой программы. Это привлекательный способ, особенно в случае разработки больших проектов, потому что он хорошо управляется в рамках стандартных бизнес-процессов. Именно в расчете на этот способ поточного производства программ создаются компиляторы со строжайшей проверкой типов данных и инструменты вроде AVR Studio, чтобы отловить мелкие ошибки по максимуму еще на начальной стадии. Но общие ошибки на уровне алгоритмов все равно отловить сразу не удается, и потом не удивляйтесь, откуда в конечном продукте низкоуровневые баги, которые следовало бы исправить еще на стадии блок-схемы. Хороший пример дает скандал с гибелью американской станции Mars Climate Orbiter, произошедшей из-за нестыковки в единицах измерения длины различных модулей бортовой навигационной программы.
Способ «разработки, управляемой тестированием» (его еще иногда называют «экстремальным программированием») намного сложнее в организации, потому что предполагает определенный уровень подготовки и заинтересованности исполнителей, и с большим трудом может быть формализован в терминах календарных планов. При этом способе любой (в идеале) кусок кода тестируется сразу после написания прямо в рабочей среде, и конечный проект собирается из таких уже по максимуму отлаженных фрагментов. Остается только отладить их взаимодействие, что также выполняется немедленно по ходу сборки. Когда вы начинаете какую-то программу с неизвестным ранее алгоритмом — создайте сначала отдельную вспомогательную программу, где фрагменты этого алгоритма можно детально проверить. Это значительно дольше, чем писать программу сразу (и что еще важнее — здесь очень трудно рассчитать время заранее), но позволяет сэкономить кучу времени на последующем доведении программы до ума. Именно для такой цели и удобна система, которую я опишу в главе 16, когда вы имеете немедленную обратную связь от вашего устройства.
Обратите внимание на следующий момент: в этой концепции документация пишется не до, а после создания и отладки собственно программы. Это полезно вдвойне, поскольку документацию не приходится непрерывно править и в ней оказывается меньше ошибок, а программа при написании документации к ней лишний раз анализируется, и очень часто бывает, что на этой стадии в ней также обнаруживаются незамеченные ошибки и недоработки. Поэтому мой совет всем без исключения разработчикам таков: даже если вы делаете устройство в одном экземпляре и для собственного удовольствия, всегда потом составляйте детальное описание программы. Это пригодится не только для того, чтобы что-то «починить» или усовершенствовать спустя некоторое время, когда детали забудутся, но и для того, чтобы лучше «отловить» ошибки и добавить забытые, но необходимые «фичи». По аналогичным причинам текст программы обязательно следует сопровождать комментариями.
Если у вас еще нет AVR-ассемблера (т. е. самой программы-компилятора), то, возможно, AVR Studio вам придется установить, т. к. это самый надежный способ добыть последнюю версию ассемблера. Скачайте AVR Studio с сайта Atmel (например, отсюда http://atmel.ru/Software/Software.htm, к сожалению, последние версии пакета стали довольно «монструозными» — более 40 Мбайт), установите его, разыщите файл avrasm32.exe или более современный avrasm2.exe (он находится в папке…\Atmel\AVR Tools\AvrAssembler) и скопируйте его в подготовленную заранее другую папку. Оттуда же целиком целесообразно скопировать папку Appnotes, во-первых, из-за собственно «аппнот», которые представляют собой рекомендации по реализации отдельных функций и выгодно отличаются от представленных на сайте Atmel форматом ASM. По сути, это готовые модули для встраивания в вашу программу (на сайте они находятся в формате PDF, а исходные коды приходится скачивать отдельно). Учтите, что в них могут быть ошибки, о чем мы еще будем упоминать, и применять их надо с оглядкой.
Во-вторых, в этой папке находятся файлы макроопределений (с расширением inc) для всех моделей AVR, поддерживаемых данной версией ассемблера, даже для тех, что уже не выпускаются. Если не скопировать папку, их пришлось бы скачивать с сайта Atmel поодиночке, а для старых типов искать где-то на стороне. Эти файлы необходимы, иначе вы не сможете откомпилировать ни одной программы, поскольку сам ассемблер абсолютно не подозревает о существовании таких вещей, как PortA или регистр DDRC, а «знает» только числовые адреса соответствующих регистров. Соответствие между этими мнемоническими обозначениями и адресами и устанавливается с помощью inc-файлов, причем для разных моделей эти адреса могут различаться. Можно на всякий случай извлечь также описание AVR-ассемблера в формате СНМ (на английском, естественно). После копирования саму AVR Studio можно удалить.
Ранее существовал и довольно примитивный ассемблер под Windows (wavrasm.exe), но затем, видимо, в корпорации решили его не развивать, обойдясь AVR Studio. Так что нам, сермяжным, придется обустроить среду для создания программ самостоятельно — это делается один раз, и потом вы вообще сможете забыть про существование avrasm.exe. Для этого потребуется еще как минимум текстовый редактор. Можно обойтись Блокнотом или многочисленными его более функциональными заменителями, вроде Edit Plus (MS Word не подойдет решительно), но тогда нам придется отдельно каждый раз запускать процесс компиляции из командной строки. Обычно это делается с помощью FAR или других клонов Norton Commander, что неудобно и сильно замедляет процесс, Потому лучше использовать специальный редактор, который позволит запускать процесс компиляции прямо из своего окна, и к тому же имеет возможность «подсветки» синтаксиса. Так как специально для AVR редакторов никто не делает, они чаще всего по умолчанию «заточены» под Intel-ассемблер, но «подсветку» нередко можно настроить «под себя».
Заметки на полях
Редакторов для написания ассемблерного кода довольно много, как правило, они в той или иной степени «самодеятельные» и бесплатные (исключение — очень профессиональный и известный с давних времен, но платный MultiEdit). Тут важно только выбрать самый удобный, иначе можно попасть в ситуацию, когда будет еще хуже, чем с Блокнотом. Например, широко разрекламированный на множестве ресурсов ASMEdit (некоего Матвеева), первое, что у меня сделал — еще в процессе инсталляции «повесил» Windows 98[11] до полной неработоспособности, а когда я все же «достучался» до исполняемого файла, то запустить его оказалось невозможным, т. к. окно свернулось в углу экрана в маленький квадратик и распахиваться не желало. Я разыскал более старую версию (ASMEdit 1.2), она установилась нормально (если не считать грамматических ошибок в инсталляторе), и тут выяснилось, что: а) настройка запуска компиляции из командной строки настолько сложна, что требует чуть ли не написания отдельной программы; б) настройка «подсветки» синтаксиса крайне примитивна. К тому же программа без спроса ассоциирует с собой расширение asm и «замусоривает» перечень ассоциаций еще полудюжиной расширений для неведомых целей, которые потом приходится вычищать вручную. Я это так подробно рассказываю потому, что у этого редактора есть одно удобное свойство: сообщения компилятора перенаправляются в окно редактора, как это было в wavrasm, и не требуется просматривать отдельные консольные окна. Если вам удастся «справиться» с ASMEdit, то вам сильно повезло.
Я перебрал в свое время несколько программ, но ни одна меня не устроила в такой степени, как творение некоего Анатолия Вознюка, которое я использую с 1999 года. Сам Анатолий знаменит также своим шедевром под названием Small CD Writer, давно скрывается инкогнито, сайт его больше не откликается, а программы не развиваются (в частности, Small CD Writer так и «не умеет» корректно писать на DVD). Но в разбираемом редакторе под названием ASM Editor (последняя версия 2.2), собственно, больше и развивать нечего. Доступен он на множестве «софтоотстойников» в Интернете* только не перепутайт