Юрий Ревич - Занимательная микроэлектроника

А что, спросите вы, язык ассемблера учить не надо? Практически не надо, потому что ассемблер— это, вообще говоря, не язык, а просто несколько правил оформления последовательности команд МК в текстовом представлении в «понятную» компилятору программу. Основные правила изложены в этой главе далее. Фирменное описание ассемблера для AVR занимает несколько страничек (сравните с фолиантами для изучения С) и входит в AVR Studio, отдельно его можно скачать с сайта Atmel. Функциональность команд наизусть заучивать отнюдь не требуется, т. к. даже профессионалы во время работы кладут перед собой открытый справочник по командам. Причем для каждого типа МК и правила написания, и мнемоника одинаковых по содержанию команд может быть различной, но в принципе все ассемблеры похожи и переход от одного к другому не настолько трудоемок, как это стараются представить разработчики «многокилобаксовых» компиляторов с языка С. Куда больше времени занимает изучение самой структуры контроллеров и работы их отдельных узлов.

То, что для ассемблера выучить действительно потребуется — это реализация некоторых типовых приемов программирования, таких как различные циклы с условными и безусловными переходами, арифметические функции, деление на локальные и глобальные переменные и т. п. Это и служит основным аргументом в пользу языков высокого уровня, где эти вещи уже сделаны за вас. Я бы выразился так: выбор между С и ассемблером зависит от вашей предыдущей подготовки. Если вы вообще никогда не сталкивались с программированием, но разбираетесь в электронике и функционировании узлов МК, то с ассемблером вам будет освоиться намного легче, ведь вы просто напрямую взаимодействуете с этими самыми узлами. Если же, наоборот, вы легко программируете на С, и зачем-то вам потребовалось освоить контроллеры, то выбирайте С, собственно, для этого упомянутые компиляторы и создавались.

Заметки на полях

«Программирование без GOTO» — лозунг знаменитого Дейкстры, классика процедурного программирования, к ассемблеру, к сожалению, абсолютно неприложим. Дейкстра имел в виду, что большое количество операторов перехода на метку очень сильно усложняет чтение программы и ведет к лишним ошибкам (подобные программы Дейкстра называл «спагетти» — из-за многочисленных линий переходов, сопровождающих графическое представление такой программы в виде блок-схемы). Но после компиляции все эти хорошо знакомые знатокам Pascal циклы while, do или repeat, until , равно как и оператор выбора (case), и даже — с некоторыми нюансами — обращение к процедурам, все равно превращаются в набор условных или безусловных переходов на определенные адреса в памяти программ. В ассемблере это приходится делать, что называется, «ручками». Разумеется, считать адреса (как при программировании в машинных кодах в начале 1950-х) вручную не нужно, в программе просто ставится метка, как и в языках высокого уровня (только в ассемблере еще проще, чем даже в каноническом Бейсике — в случае процедуры-подпрограммы метка заодно служит ее именем). Тем не менее сложности тут могут быть, и все зависит от склада вашего ума, некоторым (как автору этих строк) в хитросплетениях условных и безусловных переходов разобраться не составляет особенного труда, и иногда такое представление кажется даже более наглядным. Другие от этого «стонут и плачут», и им, конечно, следует обращаться к языку С.

При первоначальном изучении микроконтроллеров я бы решительно рекомендовал ассемблер. Как писал упоминавшийся в начале главы классик программирования Дональд Кнут, «каждый, кто всерьез интересуется компьютерами, должен рано или поздно изучить по крайней мере один машинный язык». Ассемблер — это первично, а все остальное вторично. Но автор этих строк вовсе не является упрямым снобом и прекрасно понимает, что сколько-нибудь крупные проекты (когда число строк кода начинает измеряться тысячами и более) на ассемблере будет создавать весьма затруднительно, по крайней мере, создавать «с нуля», не используя уже готовые модули. Но даже если вы в конце концов перейдете на С, советую эту книгу все же изучить до конца, чтобы познакомиться с AVR, а сам язык в приложении к AVR неплохо изложен в [4].

В этой книге вы встретите только ассемблерные программы. Мы ведь не будем писать для AVR операционные системы, и к тому же максимально попытаемся использовать готовые модули. А разобраться в работе этих модулей, когда они представлены в виде «голых» команд процессора, значительно проще. Не будем мы здесь и разбирать работу в AVR Studio — бесплатном пакете от Atmel, предназначенном для отладки программ [10] Есть и еще более мощная штука — Algorithm Builder, который, в соответствии с новыми веяниями, позволяет проектировать программу в виде блок-схемы. (впрочем, программы на ассемблере в нем можно и создавать, а вот на С — только отлаживать, если нет дополнительного компилятора из перечисленных ранее). Вообще-то этот пакет в некоторых случаях оказывается очень целесообразен, особенно в совокупности с различными отладочными модулями (т. н. «китами», Kit’s, которые, в отличие от самого пакета, отнюдь не бесплатны). В нем удобно отлаживать сложные линейные (т. е. не использующие прерываний) процедуры, например, какое-нибудь деление четырехбайтных чисел. И если у вас хватит терпения и усидчивости, чтобы разобраться с еще одной «прослойкой» между вами и микросхемой, то вы ничего не потеряете. Но я не буду загромождать книгу не столь обязательными описаниями промежуточного софта, созданного исключительно для удобства, а покажу, как можно любую вашу схему превратить в отладочный модуль без лишних сложностей. Если вы заинтересовались AVR Studio, то вам сюда [3].

Заметки на полях

Автор этих строк — приверженец стиля разработки программ, который подозрительно напоминает широко известную в программистской среде «разработку, управляемую тестированием». Индустрия ПО приучает программистов к иному стилю: условно говоря, когда все создается «на бумаге». Сначала утверждается общий проект (для чего даже есть специальные люди — программные архитекторы), рисуются блок-схемы, разные программисты пишут отдельные куски кода (отлаживая их, конечно, но только «теоретически», без привязки к реальной рабочей среде), потом это объединяется в некий «проект», наконец, собирается альфа-версия и начинается тестирование готовой программы. Это привлекательный способ, особенно в случае разработки больших проектов, потому что он хорошо управляется в рамках стандартных бизнес-процессов. Именно в расчете на этот способ поточного производства программ создаются компиляторы со строжайшей проверкой типов данных и инструменты вроде AVR Studio, чтобы отловить мелкие ошибки по максимуму еще на начальной стадии. Но общие ошибки на уровне алгоритмов все равно отловить сразу не удается, и потом не удивляйтесь, откуда в конечном продукте низкоуровневые баги, которые следовало бы исправить еще на стадии блок-схемы. Хороший пример дает скандал с гибелью американской станции Mars Climate Orbiter, произошедшей из-за нестыковки в единицах измерения длины различных модулей бортовой навигационной программы.