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 пользовать умеете.
а как же патчи на gcc и binutils?
Их густо, кучу вариаций приводить ИМХО бессмысленно. Тут задача показать как собрать toolchain и с его помощью собрать hex. для этого сгодится и ванильный gcc с binutils.
>преимущество самосборного в том, что все что надо, лежит там где сказано и не засоряет /usr/*.
Очень сомнительное преимущество. Современные пакетные менеджеры не только скачивают и распаковывают пакеты, но и решают проблему dependency hell, занимаются вопросами обновления.
Весь цивилизованный мир давно отказался от пути make && make install (уже лет 5 не слышал подобной ереси). На любом Linux-форуме на такое предложения три шкуры спустят.
Если хотите компилить сами — учитесь собирать пакеты под свой дистрибутив.
Да, во всех известных мне дистрибутивах используются десятки патчей на GCC. И не потому, что патчить это модно — а потому, что они действительно нужны.
Нет, это конешн личное дело каждого, но, имхо, не стоит рассказывать новичкам, не знающим debian-way (suse-way, your-distr-way, нужное подчеркнуть) как устроить у себя на машине бардак и dependency hell. Ведь есть дистрибутивный GCC, он лежит там где должен лежать, не верите — почитайте Filesystem Hierarchy Standard (FHS). И дистрибутивным GCC собирается вся система. Про бинутилс я вообще молчу.
тут на любителя. Я себе для embedded разработки toolchain’ы собираю сам и кладу отдельно от основного дерева, в /opt, дабы они не засоряли собой /usr/* и не конфиликтовали(изредка бывает).
Патчи на GCC и прочее опять же на любителя и весь зоопарк патчей к gcc приводить я считаю бессмысленно. Кому надо, тот пропатчит нужными патчами.
насчет dependency hell — перечитать статью, смотреть префиксы и $PATH.
опять же, первая строка статьи:
[quote]
Если есть возможность поставить готовый тулчейн из пакета, лучше воспользоваться ей.
[/quote]
По поводу «компилить сами», ИМХО тут просто вопрос правильно выбора дистрибутива. В смысле, что для этого есть Gentoo, даже если не получается настроить сборку как тебе хочется USE флагами, то очень просто сделать локальный оверлей с теми параметрами, которые хочется =)
ubuntu-way — в системе по умолчанию нет пакета build-essentials, его надо ставить отдельно.
насчет сборки пакетов под дистр, да, это правильно, но мне в статье расписывать сборку под все стопиццот дистров какие только есть? make install универсален, а пуритане и сами догадаются себе собрать пакет.
ubuntu-way он же debian-way это сборка пакетов и установка dpkg. Как это делается рассказывается на соответствующих сайтах, и обсуждается на соответствующих форумах. Давайте не уходить в оффтопик
Маленький косячёк в тексте:
Собираем 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
да, так правильно. когда копировал с консоли, прокололся.
Не. Так надо:
../../binutils-2.20/./configure –prefix=$PREFIX –target=avr –disable-nls
и
../../avr-libc-1.6.7/./configure –prefix=$PREFIX –host=avr
)))
Кстати, никто не подскажет, как пересобрать WinAVR из исходников?
Ууу… я этим занимался пару недель назад — гемор ещё тот. В юнихах всё делается ГОРАЗДО проще, а под виндами столько плясок с бубном…
А вообще, всё описано в мане по avr-libc — http://www.nongnu.org/avr-libc/user-manual/install_tools.html. Я собирал в MSYS, который, для удобства, запускал в Console.
Если интересно подробнее — обращайтесь.
Собирал тулчейн для ARM-ов, под MinGW и MSYS, на удивление кроме нескольких мелочей проблем не возникло. Процесс сборки мало чем отличается от сборки под другие платформы. Здесь главное понять смысл, что в какой пакет входит и как используется.
Кстати, тут не упомянуто, но мне для начала потребовалось собрать зависимости GMP и MPRF, не совсем понял нафига они GCC вообще нужны. :-)
судя по гуглу, gcc эти либы нужны для компилятора фортрана. Это странно.
Может быть стоит отключить все ненужное?
GMP — вроде как библиотека увеличенной точности для работы с большими числами
Для обработки чисел в compile-time, упрощение выражений содержащих константы например, gmp и mpfr делают это одинаково на всех платформах, что и требуется. Кстати, теперь ещё и mpc для комплексных чисел надо похоже.
Да, это, наверное, единственное, где они могут требоваться компилятору. Получается, что он может считать константы произвольной точности.
Кстати, натыкался в каком-то компиляторе (если не ошибаюсь, Keil Realview MDK) на проблему, там в дефайне у меня значение выходило за 32бита, потом делилось и в итоговом приложении приравнивалось 32битной переменной. В итоге не работало, как оказалось, препроцессор в нем дефайны считал именно в 32х битных переменных и расчет производится неверно.
при сборке 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
иначе при сборке был вылет с кучей ошибок.
Ещё по хорошему следовало бы сделать коментарии к мэйкфайлу, но кому это надо в принципе сами найдут.
Да, указывают gcc собирать только в каталоге, отдельном от его родного…
Здравствуйте. Собрал 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)’
Я так понял, что он использует не тот ассемблер, который нужно. Как исправить, подскажите.
А это что за херь? — lo8(0)
Ну, lo8, как я понимаю, специфический оператор линуховского ассеблера: «lo8 Takes the least significant 8 bits of a 16-bit integer» (http://www.nongnu.org/avr-libc/user-manual/assembler.html). Сама программа на си — пустой главный цикл. Может быть, он return 0 пытается обработать.
А, гнутый асм. Не, я с ним не работал никогда. Но где то в we были посты по работе с ним.
Для работы с ассемблером 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, разделив длинный комментарий или удалив его.