Введение


Ни для кого не секрет, что микроконтроллеры семейства 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 и результат работы выглядит примерно одинаково. Чтобы не возмущать благородных донов длинными портянками, помещаю результаты компиляции под спойлеры

Выхлоп gavrasm
$ gavrasm test.S
+------------------------------------------------------------+
| gavrasm gerd's AVR assembler Version 3.5 (C)2015 by DG4FAC |
+------------------------------------------------------------+
Compiling Source file: test.S
-------
Pass:        1
14 lines done.

Pass 1 ok.
-------
Pass:        2
14 lines done.


3 words code, 0 words constants, total=3 =  0.0%

No warnings!
Compilation completed, no errors. Bye, bye ...

$ ls -l
итого 12
-rw-rw----+ 1 maisvendoo users  52 июл 29 15:46 test.hex
-rw-rw----+ 1 maisvendoo users 741 июл 29 15:46 test.lst
-rw-rw----+ 1 maisvendoo users  92 июл 29 15:46 test.S


Содержимое hex-файла прошивки
:020000020000FC
:060000000AE00395FECFAB
:00000001FF

Содержимое файла листинга

gavrasm Gerd's AVR assembler version 3.5 (C)2015 by DG4FAC
----------------------------------------------------------
Source file: test.S
Hex file: test.hex
Eeprom file: test.eep
Compiled: 29.07.2017, 15:46:38
Pass: 2
1: .device atmega16
2:
3: .dseg
4:
5: .cseg
6: .org 0x0000
7:
8: 000000 E00A ldi r16, 10
9: M1:
10: 000001 9503 inc r16
11: 000002 CFFE rjmp M1
12:
13: .eseg
14:

Program : 3 words.
Constants : 0 words.
Total program memory: 3 words.
Eeprom space : 0 bytes.
Data segment : 0 bytes.
Compilation completed, no errors.
Compilation endet 29.07.2017, 15:46:38


Выхлоп avra
$ avra -l test.lst test.S 
AVRA: advanced AVR macro assembler Version 1.3.0 Build 1 (8 May 2010)
Copyright (C) 1998-2010. Check out README file for more info

   AVRA is an open source assembler for Atmel AVR microcontroller family
   It can be used as a replacement of 'AVRASM32.EXE' the original assembler
   shipped with AVR Studio. We do not guarantee full compatibility for avra.

   AVRA comes with NO WARRANTY, to the extent permitted by law.
   You may redistribute copies of avra under the terms
   of the GNU General Public License.
   For more information about these matters, see the files named COPYING.

Pass 1...
Pass 2...
done

Used memory blocks:
   Code      :  Start = 0x0000, End = 0x0002, Length = 0x0003

Assembly complete with no errors.
Segment usage:
   Code      :         3 words (6 bytes)
   Data      :         0 bytes
   EEPROM    :         0 bytes
$ ls -l
итого 16
-rw-rw----+ 1 maisvendoo users 92 июл 29 15:46 test.S
-rw-rw----+ 1 maisvendoo users  0 июл 29 15:55 test.S.cof
-rw-rw----+ 1 maisvendoo users 13 июл 29 15:55 test.S.eep.hex
-rw-rw----+ 1 maisvendoo users 55 июл 29 15:55 test.S.hex
-rw-rw----+ 1 maisvendoo users 61 июл 29 15:55 test.S.obj

Содержимое hex-файла
:020000020000FC
:060000000AE00395FECFAB
:00000001FF

Листинг генерируется дополнительным ключем -l при сборке
$ cat test.lst

AVRA Ver. 1.3.0 test.S Sat Jul 29 16:02:05 2017

.device atmega16

.dseg

.cseg
.org 0x0000

C:000000 e00a ldi r16, 10
M1:
C:000001 9503 inc r16
C:000002 cffe rjmp M1

.eseg


Segment usage:
Code : 3 words (6 bytes)
Data : 0 bytes
EEPROM : 0 bytes

Assembly completed with no errors.


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

  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 и так далее. Тема неисчерпаема и достойна продолжения. Время покажет.

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

Комментарии (16)


  1. 3draven
    29.07.2017 22:21
    +1

    AVR мертв. ARM дешевле и среды удобные.


    1. maisvendoo
      29.07.2017 22:55
      +1

      Ну как сказать мертв. Используется ещё, а камни, даже в DIP-корпусе делают до сих пор. Я тоже за ARM, но практика, сцуко, вещь сложная


      1. dlinyj
        01.08.2017 18:04

        Хватит заниматься некрофилией! Есть нормальные процы. Давайте на С51 или Zilog делать?


  1. Antzor
    29.07.2017 22:30

    Спасибо за статью. Про процесс прошивки тоже интересно почитать. Так что пишите обязательно.


  1. DuMOHsmol
    29.07.2017 23:40

    Спасибо за статью! Вот бы ещё кто-нибудь мурзилку по STM32+Makefile+Eclipse накатал.


    1. maisvendoo
      29.07.2017 23:44

      Не поверите, но на днях из Китая мне пришла STM32 Discovery и руки чешутся честно говоря. К тому же жду Pinboard II от DIHALT, на которую хочу запилить обзор. Но вопрос упирается в свободное время. Сейчас я в отпуске и пишу, с понедельника снова в бой на работу… Учту Ваше пожелание, но о сроках умолчу


      1. DuMOHsmol
        29.07.2017 23:50

        Заранее спасибо! Собственно с Makefile там проблем нет (их CubeMX генерировать умеет), а вот отладку в Eclipse я как-то не осилил.


        1. asakasinsky
          30.07.2017 01:31
          +1

          Рекомендую. В «свободном» доступе тоже можно найти

          Carmine Noviello. Mastering STM32

          A step-by-step guide to the most complete ARM Cortex-M platform, using a free and powerful development environment based on Eclipse and GCC

          https://leanpub.com/mastering-stm32


    1. makser1
      30.07.2017 21:33
      +1

      Уже есть готовый бесплатный рабочий пакет http://www.openstm32.org/System+Workbench+for+STM32
      Им пользуюсь, последние версии весьма стабильны, вряд ли получится сделать такую связку лучше.


      1. DuMOHsmol
        30.07.2017 21:49

        Насколько я понял, оно работает со своим собственным форматом проекта, хотелось бы использовать именно Makefile, чтобы произвольный человек мог собрать прошивку без IDE. Или же там можно приткнуть мейкфайл?


        1. makser1
          31.07.2017 15:23

          Там есть импорт из Makefile, но я его не пробовал


  1. so1ov
    30.07.2017 01:31

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

    С кем не бывает =)


  1. mksma
    30.07.2017 22:47

    Спасибо за статью. С недавних пор тоже заинтересовался темой программирования на ассемблере и начал эксперементировать с Arduino Uno. Правда писал на GNU Assembler и компилировал в avr-gcc. В статье очень подробно описан процесс отладки, но микроконтроллеры обычно используются с датчиками. Собственно вопрос, возможно ли эмулировать датчик или для отладки работы датчиков нужен hardware debugger?


  1. pulsatrix
    30.07.2017 22:47

    Какое-то время назад тоже пытался программить арудуину на ассемблере. По Дихальту, конечно же. Для удобства составил список ссылок на статьи по avr.
    https://www.cyberowl.xyz/zzz/


  1. San66
    31.07.2017 19:04

    Следующая статья будет про программирование 8051 в машинных кодах из под DOS?
    Ассемблер конечно иногда пригождается, когда надо где-то сильно соптимизировать, или понять, как скомпилился код из более высокоуровневого языка, Но писать нуля на нем имхо совершенно безперспективно.


    1. maisvendoo
      31.07.2017 19:19

      программирование 8051 в машинных кодах из под DOS?

      Не могу понять, сарказм это или пафос?

      Почитайте DIHALT вот тут написано четко и предельно ясно по полочкам разложено о месте ассемблера в разработке под МК