Введение

Ни для кого не секрет, что микроконтроллеры семейства AVR прочно вошли в практику домашних поделок. Кроме того, уже несколько лет наблюдается массовое (на грани эпидемии) увлечение отладочными платами типа Arduino, построенными на базе все тех же AVR. Не буду судить, хорошо это или плохо, ибо статей на эту тему на ресурсе более чем достаточно. Хочу уберечь и моего читателя от споров на тему «что такое Arduino и хорошо это или плохо». Статья не об этом.

Рано или поздно для любого «ардуиньщика» (при условии что он хочет выйти на более высокий профессиональный уровень) наступает момент когда в рамках платформы Arduino ему становится тесно и он начинает задумываться о том а что же в действительности происходит под капотом. И ответы на все его вопросы уже есть, например в виде замечательного курса «AVR. Учебный курс» от глубокоуважаемого DIHALT. Если вы пользователь OS Windows, то и недостатка в инструментах разработки у вас не будет, достаточно бесплатной Atmel Studio, закрывающей все вопросы разработки ПО для МК AVR.

Хоть я и тимлид в коллективе разработчиков ПО прикладного уровня, вопросы «железа» которое в нашей конторе делается на базе AVR с недавних пор стали интересовать меня очень остро. Возникло желание хорошо разобраться во всех аспектах разработки ПО для МК. И так как я являюсь убежденным приверженцем использования в разработке OS на базе ядра Linux, меня заинтересовал вопрос, а как там в линуксах: можно/нельзя ли писать и отлаживать ПО, зашивать его в кристалл с тем же (или примерно тем же) уровнем удобства, который нам доступен в Windows. Тех кого тоже интересует этот вопрос, и в особенности тех, кому тема поста кажется надуманной, приглашаю под кат.

Что касается разработки на C/C++, в среде линукс с этим особых проблем и нет, в виду общей ориентированности этой системы на использование данного языка и наличия достойного набора инструментария. Однако, тот же DIHALT, например, утверждает что программирование для МК неотделимо от знания ассемблера, в чем я с ним соглашусь, в виду логичности его тезисов, изложенных в «Учебном курсе» и собственного (пусть небольшого) опыта системной разработки под x86.

Руководствуясь тезисом, что от асма AVR нам никуда не уйти и сидим мы под линуксом, попробуем посмотреть на то, как можно писать и отлаживать программы. Я использую дистрибутив Arch Linux, поэтому в своем повествовании буду опираться на его экосистему.

1. Выбираем компилятор

Сразу скажу, что связку Atmel Studio + wine я предлагать не буду. Не люблю я wine (хоть и пользуюсь по необходимости). Остановимся на нативных средствах, прежде всего компиляторов, обзор которых в сети и личные ковырялки дали выход на триумвират gavrasm, avra и avr-as. Выбор произошел по двум противоречивым критериям: поддержка синтаксиса предлагаемого Atmel и возможность отладки прошивки по шагам в эмуляторе. Последнее для меня более важно, а в плоскости курса @DIHAL так прям вообще необходимо для понимания процесса работы микроконтроллера. Общность синтаксиса с компиляторами от Atmel дает, опять таки с моей точки зрения, лишь возможность без труда адаптировать проекты Atmel Studio к работе в линуксах, что весьма сомнительное преимущество, ибо тот же avr-as существует и под Windows. Предлагаю читателю обзор перечисленной троицы.

gavrasm и avra

Поддерживают синтаксис Atmel. Первый нашелся в AUR и устанавливается командой

$ yaourt -S gavrasm

Второй так же доступен в AUR

$ yaourt -S avra

Программа вида

test.S

;---- Определяем целевое устройство
        .device atmega16
;---- Сегмент данных
        .dseg
;---- Сегмент кода
        .cseg
        .org 0x0000

        ldi r16, 10
M1:
        inc r16
        rjmp M1

;---- Сегмент EEPROM
        .eseg

Собирается обоими компиляторами сразу в *.hex и результат работы выглядит примерно одинаково. Чтобы не возмущать благородных донов длинными портянками, помещаю результаты компиляции под спойлеры



Анализируя результаты можно сказать, что:

1. Генерируется файл в формате Intel HEX, пригодный сразу для прошивки в МК
2. Синтаксис совместим с Atmel

Определенно в синтаксисе avra есть отличия, например

        .device atmel16

дает указание на МК, скрывая от программиста явное указание ссылок на *.inc файл макроопределений. Существует и ряд других нюансов, о которых проще прочесть в документации или в хорошей обзорной статье Valber'а на русском языке. Об особенностях gavrasm можно почитать тут.

Оба рассмотренных компилятора имеют существенный фатальный недостаток — они не генерируют отладочной информации. Хотя в документации по avra такая возможность заявлена

Debugging support AVRA creates a coff file everytime the assembly was sucessful. This file allows AVR Studio or any coff compatible debugger to simulate or emulate the program.

но *.cof файл в выхлопе неизменно оказывается пустым. Отсутствие отладочной информации исключает адекватную отладку по шагам, остро необходимую начинающим. Так что от этих (к слову довольно старых альтернатив) переходим к другому, более могучему компилятору из семейства GNU

avr-as

Установка этого инструментария доступна из официальных репозиториев любого достаточно популярного дистрибутива. В случае с Arch Linux

$ sudo pacman -S avr-gcc avr-libc avr-binutils

GNU assembler (gas) является бэкэндом к компилятору gcc и обычно явно не вызывается. Связано это с идеологией *nix систем, ориентированных на разработку на C/C++, в которой ассемблеру отводится роль младшего нелюбимого сына. Вместе с тем это обеспечивает глубокую интеграцию ассемблерного кода в программы на C/C++ что, редко, но бывает необходимо. К тому же, если говорить об архитектурах x86/x86_64 синтаксис «гнутого» ассемблера (AT&T) разительно отличается от принятой Intel-нотации (хотя на gas можно использовать и интел-синтаксис, компилятор дает такую возможность). Чего стоит обратный по отношению к интел-нотации порядок операндов в командах, например

Применительно к AVR gas не отходит от нотации Atmel в части оформления команд — порядок операнд здесь привычный, например команда:

ldi r16, 10

в gas для AVR выглядит привычно. Другое дело макросы и директивы компилятора, они отличаются от Atmel. Приведенная выше тестовая программа будет выглядеть так:

test.S

#include	"/usr/avr/include/avr/io.h"	

/* Секция данных */
	.data

/* Секция кода */
	.section .text

	.org 0x0000

/* Точка входа, обязательная при вызове avr-gcc вместо avr-as */
	.global main

main:

	ldi r16, 10
M1:
	inc r16
	rjmp M1

Как видно из исходника секция кода определяется директивой предпроцессора .section .text (аналог .cseg). Аналогом .dseg служит .data. Единственное, чего я пока не понял и не узрел в документации, как определяется содержимое EEPROM (аналог .eseg). Надеюсь среди читателей найдется добрый гуру, который натолкнет меня на ответ. Новичкам же, подобным мне, советую покурить документацию тут и вот здесь для уяснения специфики использования gas для AVR.

Мы же теперь соберем hex-файл, пригодный для прошивки МК. Команда:

$ avr-as -mmcu=atmega16 -o test.o test.S

генерирует объектный файл для соответствующего контроллера (в нашем случае ATMega 16). Далее данный объектный файл преобразуется в hex

$ avr-objcopy -O ihex test.o test.hex

Получая на выходе hex-файл вида

test.hex
:060000000AE00395FECFAB
:00000001FF

Тем не менее, мы не ответили на главный вопрос и не обозначили преимущество gas по возможности организации пошаговой отладки. Для этого прежде всего

2. Выбираем отладчик

В линуксах нет достойной альтернативы GDB. Для его использования применительно к МК AVR ставим фронтэнд

$ sudo pacman -S avr-gdb

Данный отладчик обладает всем комплексом противоречий, пугающих новичков: при справедливо заявленной термоядерной мощи порог вхождения его довольно высок. Чтобы разучиться боятся gdb и начать в нем работать очень рекомендую статью величайшего и могучего и, к сожалению, ныне покойного (земля тебе пухом, Мыщъх!) Николая Лихачева aka Крис Касперски «Погружение в технику и философию GDB».

Первое, что нужно для использования gdb — собрать код соответствующим образом, сгенерировав ELF-образ, содержащий отладочные символы

$ avr-as -mmcu=atmega16 -g --gstabs -o test.o test.S

Ключи -g и --gstabs генерируют соответственно отладочные символы и добавляют возможность использовать образ для удаленной отладки в gdb. Компонуем полученный объектный файл в ELF

$ avr-ld -m avr4 -o test.elf test.o

Полученный образ мы используем для отладки нашего теста. Из него же можно сгенерировать и hex-файл

$ avr-objcopy -j .text -j .data -O ihex test.elf test.hex

явно указывая ключем -j включаемые в прошивку секции, ключем -O ihex формат вывода (intel HEX). Получаем тот же файл, что и в предыдущем случае:

test.hex
:060000000AE00395FECFAB
:00000001FF

Осталось загрузить полученный код в эмулятор и проверить доступные возможности отладки.

3. Эмулятор AVR в Linux

Этот вопрос сложнее прочих. Мною было найдено два достойных кандидата: simavr, имеющийся в официальных репозиториях арча и устанавливаемый простым:

$ sudo pacman -S simavr

и более популярный симулятор simulavr, который не был найден даже в AUR, при том что основная масса полезной инфы в сети именно о нем. Собрать из исходников с целью создания PKGBUILD для AUR у меня не вышло, хотя я перебрал все адекватные ветки в официальном репозитории. Пришлось прибить зверский костыль, скачав DEB-пакет для Debian, превратив его в пакет для арча с помощью утилиты debtap.

 $ debtap simulavr_0.1.2.2-7+b2_amd64.deb

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

Версия эта довольно древняя, а текущий релиз (судя по дате последнего коммита в репозитории) ушел довольно далеко.

Что же касается simavr, то он ставится без проблем, поддерживает большее число МК, но на попытки подключения к нему отладчиком выдает в консоль сообщения о крэше эмулятора и разобраться с этим мне пока не удалось. Тут я снова апеллирую к сведующему в вопросе читателю и рассчитываю на подсказку.

Пока же мы используем для отладки костыльно поставленный simulavr

4. Пошаговая отладка на связке GDB + simulavr

Итак, сначала отладим программу хардкорно — из консоли запустим эмулятор

$ simulavr -d atmega16 -c 8000000 -g -P simulavr-disp

запускаем эмулятор ATMega 16 (ключ -d) на частоте 8 МГц (ключ -с) с опцией удаленной отладки и возможность красивого просмотра регистров контроллера (опция -P, которая по данным из сети в свежайшей версии эмулятора убрана). Видим окошко терминала с содержимым регистров и памяти



наблюдаем в консоли запуска сообщение

Waiting on port 1212 for gdb client to connect...

сообщающее нам о том, что эмулятор ждет подключения отладчика на порту 1212 (порт можно указать при запуске ключем -p). В другой консоли стартуем отладчик:

$ avr-gdb -q -tui

первый ключ уберет пафосный выхлоп gdb при запуске, вторая группа ключей активирует просмотр исходников в процессе отладки в применена мной для наглядности (на деле эта опция неудобна по ряду причин). В консоли мы увидим следующее:



Подлючаемся к эмулятору

(gdb) target remote:1212

Загружаем ELF-образ в эмулятор (да, именно его а не hex, на чем я обжегся в самом начале) d 'vekznjh

(gdb) load test.elf

Загружаем отладочные символы:

(gdb) file test.elf

ответив «yes» на заданный вопрос, получая следующую картину:



Что же, мы видим наш исходник и отладчик, готовый к приему команд. Даем команду next

(gdb) n

и видим как отладчик бодро переместился по коду.



можем посмотреть изменившееся состояние регистров контроллера как в консоли эмулятора



так и в окне отладчика:

(gdb) info registers
.
.
.
r16            0xa      10
.
.
.
SREG           0x0      0
SP             0x0      0x0 <main>
PC2            0x2      2
pc             0x2      0x2 <M1>

С этого момента нам доступен весь богатейший инструментарий, предоставляемый отладчиком gdb. Однако, что линуксоиду хорошо то виндузятнику смерть меня упрекнут мол «чувак, в Atmel Studio есть нормальная отладка с отображением исходников, перемещением по коду хоткеями и просмотром значений вразумительным графическим способом» и будут правы, поэтому попытаемся хотя бы частично решить проблему дружественности отладки, совместив её с разработкой

5. Пошаговая отладка в IDE Eclipse

IDE Eclipse известна давно. За время своего существования она прочно утвердилась в разных областях разработки ПО и может «тупо всё», благодаря обширному набору плагинов, расширяющих её функциональность. В свое время я восторгался ей, но время это прошло, так как в обыденной работе у неё есть масса мелких нюансов, раздувающихся в недостатки (на работе в продакшене я предпочел для того же C/C++ QtCreator в силу специфики деятельности, о чем не жалею).

Тем не менее, с точки зрения решаемой нами задачи она вполне удовлетворяет её требованиям. Для работы с AVR в Eclipse потребуется установка следующих плагинов



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

Eclipse по своей сути ориентирован на C/C++ разработку, поэтому для создания ассемблерного проекта воспользуемся генерацией проекта через имеющийся Makefile, который и напишем для нашего теста. Вот он

Makefile

# Декларируем необходимые переменные
DEVICE = atmega16
TARGET = test
OBJECTS = $(TARGET).o
ELF = $(TARGET).elf
HEX = $(TARGET).hex

# Задаем правила компиляции
COMPILE = avr-as -mmcu=$(DEVICE) -g --gstabs

# Главная цель - HEX-файл прошивки
all:	hex

# Правило сборки объекрных молулей: беруться все исходники 
# с расширением *.S и компилятся в объектные модули *.o
.S.o:
           $(COMPILE) -c $< -o $@
	
# Правило очитски - удаляем все продукты сборки
clean:
           rm -f $(HEX) $(ELF) $(OBJECTS)
	
# Компоновка всех объектных модулей в ELF
elf:   $(OBJECTS)
        avr-ld -m avr4 -o $(ELF) $(OBJECTS)

# Преобразование ELF в HEX
hex: elf
        avr-objcopy -j .text -j .data -O ihex $(ELF) $(HEX)

Написав этот опус открываем Eclipse и создаем новый проект File -> New -> Project, выбирая сишный проект на основе Makefile



жмем Next, в следующем окне выбирая расположение каталога с исходниками и Makefile



Шлепаем Finish и видим наш проект во всей красе



Идем в меню Project -> Build all и получаем все необходимые нам бинарники:

19:34:51 **** Build of configuration Default for project test ****
make all 
avr-as -mmcu=atmega16 -g --gstabs -c test.S -o test.o
avr-ld -m avr4 -o test.elf test.o
avr-objcopy -j .text -j .data -O ihex test.elf test.hex

19:34:51 Build Finished (took 128ms)

Теперь настроим запуск эмулятора, как внешнего инструмента проекта зайдя в Run -> External Tools, создав новую конфигурацию с настройками соответствующими приведенным скринам





Тут мы сообщаем среде, что хотим запускать эмулятор с нужными нам параметрами командной строки, поместив пункт запуска в меню Run > External Tools.

Применяем настройки, идем в меню Run > External Tools > atmega16 и наблюдаем запуск эмулятора:



Хорошо, теперь настроим конфигурацию отладки нашего проекта. Идем в меню Run > Debug Configuratuions и настраиваем аппаратную отладку через GDB.



не забывая указать тип соединения с сервером симуляции:



и указав, какие действия следует выполнить при запуске отладки:



Обязательно ставим галки на Load image и Load Symbols — это позволяет отладчику загрузить прошивку в эмулятор и прочесть отладочные символы. Ставим точку останова на метку M1.

Жмем кнопки Apply и Debug и… вуаля!



Отладчик послушно стал на указанной точке останова. Доступен просмотр дампа памяти и содержимого регистров. Жмем F5 (или F6) и трассируем наш код по шагам.



Теперь можно хоть до посинения трассировать код, смотреть значения регистров и переменных, править код, снова трассировать, в общем заниматься привычным процессом разработки.

Заключение

Что хочу сказать в финале? Я уже тысячу раз говорил о том, что все мои статьи на ресурсах хабр и гиктаймс — отражение личного опыта и рупор субъективного мнения. Решена задача — организация разработки ПО для контроллеров AVR в среде Linux. Эта статья — продукт долгого гугления и сбора информации из разрозненных сетевых источников. Цель её — натолкнуть новичка на поиск в нужном направлении. Статья не претендует на академичность, она лишь продукт моих собственных копаний и попытка поделится собранной информацией, а так же привлечь заинтересованных людей к интересной мне теме.

Тут много о чем не сказано, например о прошивке через avrdude, который (sic!) есть кроссплатформенная утилита прошивки для семейства AVR. Если у читателей будет желание, а у меня возможность, мы рассмотрим и её, помигаем светодиодами, пошлем слово «жопа» «счастье» через USART и так далее. Тема неисчерпаема и достойна продолжения. Время покажет.

А пока, благодарю моего читателя за внимание и надеюсь на новую встречу!