AVR toolchain своими руками

DI HALT:
В догонку к прошлому посту про AVR Studio в Linux досылаю и про сборку avr-libc там же. Вынесено из комментов к предыдущему посту. Спасибо Dark SavanT

Если есть возможность поставить готовый тулчейн из пакета, лучше воспользоваться ей.
преимущество самосборного в том, что все что надо, лежит там где сказано и не засоряет /usr/*. Но тут мы теряем автоматические обновления из пакетов. Короче, думайте сами, решайте сами.

Поехали!
В минимальной комплектации нам понадобятся:

  • binutils — это ассемблер, линкер, objdump и еще куча необходимых для сборки бинарника вещей
  • gcc — собственно сам компилятор.
  • avr-libc — стандартная библиотека С для AVR архитектуры.
  • avrdude — программа для прошивки. Хальт про нее не раз писал.

для того, чтобы это все безобразие собралось, нужен установленный в системе gcc, bash, awk, binutils, libc, может что-то еще забыл.

делаем каталог для сборки:

mkdir build
cd build

качаем исходники

wget -c http://ftp.gnu.org/gnu/binutils/binutils-2.20.tar.gz 
wget -c http://ftp.gnu.org/gnu/gcc/gcc-4.4.2/gcc-4.4.2.tar.bz2 
wget -c http://mirror.vocabbuilder.net/savannah/avr-libc/avr-libc-1.6.7.tar.bz2

поддиректории для сборки отдельных компонентов

mkdir build/binutils 
mkdir build/gcc 
mkdir build/libc 

распаковываем

tar zxvf binutils-2.20.tar.gz
tar jxvf avr-libc-1.6.7.tar.bz2 
tar jxvf gcc-4.4.2.tar.bz2 

устанавливаем переменные окружения:
PREFIX — для того, чтобы make install скопировал бинарники в нужную директорию
PATH — для того, чтобы собрать libc компилятором для avr

export PREFIX=/opt/avrchain 
export PATH=$PATH:$PREFIX/bin

Собираем binutils

cd build/binutils 
../../configure --prefix=$PREFIX --target=avr --disable-nls
make install

Собираем gcc

cd ../gcc
../../gcc-4.4.2/configure --prefix=$PREFIX --target=avr --enable-languages=c --disable-nls --disable-libssp --with-dwarf2
make install

Собираем avr-libc

cd ../libc

../avr-libc-1.6.7/configure --prefix=$PREFIX --host=avr

make install

Проверим

[savant@savant-laptop avrchain]$ avr-gcc --version
avr-gcc (GCC) 4.4.2
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

должны получить такой вывод.

А теперь что-нибудь соберем.
Я не запаривался и взял простой пример из AVR Курса

Вариант №1: все руками

Компилим:

avr-gcc -g -mmcu=atmega8 Pinboard_1.c -o demo.o

Линкуем:

avr-gcc -g -mmcu=atmega8 -o demo.out demo.o

Получаем .hex фаил для заливки в МК

avr-objcopy -j .text -O ihex ./demo.out demo.hex

Вариант №2: Makefile
создаем рядом с исходником Makefile такого вида:

CC=avr-gcc
OBJCOPY=avr-objcopy

CFLAGS=-g -mmcu=atmega8
    
all : demo.out
        $(OBJCOPY) -j .text -O ihex demo.out rom.hex
    
demo.out : demo.o
        $(CC) $(CFLAGS) -o demo.out -Wl,-Map,demo.map demo.o
    
demo.o : 
        $(CC) $(CFLAGS) -Os -c Pinboard_1.c -o demo.o

далее говорим make и в итоге получаем hex фаил для заливки в контроллер. Как дальше жить, сами знаете, чай не маленькие, avrdude пользовать умеете.

26 thoughts on “AVR toolchain своими руками”

    1. Их густо, кучу вариаций приводить ИМХО бессмысленно. Тут задача показать как собрать toolchain и с его помощью собрать hex. для этого сгодится и ванильный gcc с binutils.

  1. >преимущество самосборного в том, что все что надо, лежит там где сказано и не засоряет /usr/*.
    Очень сомнительное преимущество. Современные пакетные менеджеры не только скачивают и распаковывают пакеты, но и решают проблему dependency hell, занимаются вопросами обновления.
    Весь цивилизованный мир давно отказался от пути make && make install (уже лет 5 не слышал подобной ереси). На любом Linux-форуме на такое предложения три шкуры спустят.
    Если хотите компилить сами — учитесь собирать пакеты под свой дистрибутив.

    Да, во всех известных мне дистрибутивах используются десятки патчей на GCC. И не потому, что патчить это модно — а потому, что они действительно нужны.

    Нет, это конешн личное дело каждого, но, имхо, не стоит рассказывать новичкам, не знающим debian-way (suse-way, your-distr-way, нужное подчеркнуть) как устроить у себя на машине бардак и dependency hell. Ведь есть дистрибутивный GCC, он лежит там где должен лежать, не верите — почитайте Filesystem Hierarchy Standard (FHS). И дистрибутивным GCC собирается вся система. Про бинутилс я вообще молчу.

    1. тут на любителя. Я себе для embedded разработки toolchain’ы собираю сам и кладу отдельно от основного дерева, в /opt, дабы они не засоряли собой /usr/* и не конфиликтовали(изредка бывает).

      Патчи на GCC и прочее опять же на любителя и весь зоопарк патчей к gcc приводить я считаю бессмысленно. Кому надо, тот пропатчит нужными патчами.

      насчет dependency hell — перечитать статью, смотреть префиксы и $PATH.

    2. По поводу «компилить сами», ИМХО тут просто вопрос правильно выбора дистрибутива. В смысле, что для этого есть Gentoo, даже если не получается настроить сборку как тебе хочется USE флагами, то очень просто сделать локальный оверлей с теми параметрами, которые хочется =)

    3. ubuntu-way — в системе по умолчанию нет пакета build-essentials, его надо ставить отдельно.

      насчет сборки пакетов под дистр, да, это правильно, но мне в статье расписывать сборку под все стопиццот дистров какие только есть? make install универсален, а пуритане и сами догадаются себе собрать пакет.

      1. ubuntu-way он же debian-way это сборка пакетов и установка dpkg. Как это делается рассказывается на соответствующих сайтах, и обсуждается на соответствующих форумах. Давайте не уходить в оффтопик

  2. Маленький косячёк в тексте:
    Собираем binutils
    cd build/binutils
    ../../configure —prefix=$PREFIX —target=avr —disable-nls
    надо:
    ../../binutils-2.20/configure —prefix=$PREFIX —target=avr —disable-nls

    и для сборки avr-libc надо:
    ../../avr-libc-1.6.7/configure —prefix=$PREFIX —host=avr

    1. Не. Так надо:
      ../../binutils-2.20/./configure –prefix=$PREFIX –target=avr –disable-nls
      и
      ../../avr-libc-1.6.7/./configure –prefix=$PREFIX –host=avr
      )))

    1. Ууу… я этим занимался пару недель назад — гемор ещё тот. В юнихах всё делается ГОРАЗДО проще, а под виндами столько плясок с бубном…
      А вообще, всё описано в мане по avr-libc — http://www.nongnu.org/avr-libc/user-manual/install_tools.html. Я собирал в MSYS, который, для удобства, запускал в Console.
      Если интересно подробнее — обращайтесь.

  3. Собирал тулчейн для ARM-ов, под MinGW и MSYS, на удивление кроме нескольких мелочей проблем не возникло. Процесс сборки мало чем отличается от сборки под другие платформы. Здесь главное понять смысл, что в какой пакет входит и как используется.

  4. Кстати, тут не упомянуто, но мне для начала потребовалось собрать зависимости GMP и MPRF, не совсем понял нафига они GCC вообще нужны. :-)

      1. Может быть стоит отключить все ненужное?
        GMP — вроде как библиотека увеличенной точности для работы с большими числами

    1. Для обработки чисел в compile-time, упрощение выражений содержащих константы например, gmp и mpfr делают это одинаково на всех платформах, что и требуется. Кстати, теперь ещё и mpc для комплексных чисел надо похоже.

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

        Кстати, натыкался в каком-то компиляторе (если не ошибаюсь, Keil Realview MDK) на проблему, там в дефайне у меня значение выходило за 32бита, потом делилось и в итоговом приложении приравнивалось 32битной переменной. В итоге не работало, как оказалось, препроцессор в нем дефайны считал именно в 32х битных переменных и расчет производится неверно.

  5. при сборке gcc кроме как так у меня не получилось никак:
    tar -xvf gcc-4.4.2.tar.bz2
    cd gcc-4.4.2
    mkdir build
    cd build
    ../configure configure —prefix=$PREFIX —target=avr —enable-languages=»C,C++» —disable-nls
    make
    make install
    иначе при сборке был вылет с кучей ошибок.
    Ещё по хорошему следовало бы сделать коментарии к мэйкфайлу, но кому это надо в принципе сами найдут.

  6. Здравствуйте. Собрал binutils, gcc, avr-libc. avr-gcc ругается на параметр -mmcu= или выдаёт
    /tmp/ccLilHLP.s: Assembler messages:
    /tmp/ccLilHLP.s:20: Error: too many memory references for `in’
    /tmp/ccLilHLP.s:21: Error: too many memory references for `in’
    /tmp/ccLilHLP.s:28: Error: no such instruction: `ldi r24,lo8(0)’
    /tmp/ccLilHLP.s:29: Error: no such instruction: `ldi r25,hi8(0)’

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

  7. Для работы с ассемблером 8bit AVR существует очень полезный компилятор avra. Он присутствует во многих дистрибутивах (не всегда свежая версия). Для обновления желательно зайти на официальный сайт и пересобрать более актуальную.
    Официальный сайт http://avra.sourceforge.net/
    На данный момент поддерживаются следующие устройства: ATtiny10 ATtiny11 ATtiny12 ATtiny13 ATtiny13A ATtiny15 ATtiny22 ATtiny24 ATtiny24A ATtiny25 ATtiny26 ATtiny28 ATtiny44 ATtiny44A ATtiny45 ATtiny84 ATtiny85 ATtiny2313 ATtiny2313A ATtiny4313 AT90S1200 AT90S2313 AT90S2323 AT90S2333 AT90S2343 AT90S4414 AT90S4433 AT90S4434 AT90S8515 AT90C8534 AT90S8535 ATmega8 ATmega161 ATmega162 ATmega163 ATmega16 ATmega323 ATmega328P ATmega32 ATmega603 ATmega103 ATmega104 ATmega128 ATmega48 ATmega88 ATmega168 ATmega8515 AT94K
    Поддержку новых добавить достаточно просто. Для этого надо соответствующим образом модифицировать device.c, указав объёмы памяти, указатель на начало RAM и поддерживаемые инструкции.
    Рассмотрим простейший пример
    ————— test.asm ———————-
    .include «/usr/share/avra/m8def.inc» ; Используем ATMega16
    lds r16, 5
    out PORTB, r16
    nop
    nop
    —————————————————
    компилируем:
    avra test.asm
    и при удачной компиляции получаем сообщение о результате:
    Used memory blocks:
    Code : Start = 0x0000, End = 0x0004, Length = 0x0005

    Assembly complete with no errors.
    Segment usage:
    Code : 5 words (10 bytes)
    Data : 0 bytes
    EEPROM : 0 bytes

    на выходе у нас будет объектный файл, hex EEPROM и hex кода, которые заливаются в микроконтроллер или отправляются в симулятор
    Обнаружено также, что компилятор не может обработать слишком длинные строчки комментария! По крайней мере, необходимо исправить файл m16def.inc, разделив длинный комментарий или удалив его.

Добавить комментарий

Ваш e-mail не будет опубликован.

Перед отправкой формы:
Human test by Not Captcha