В зависимости от причин ошибки могут быть разные. Либо утилита make вообще не запускается, либо в процессе обработки makefile выдаются ошибки наподобие "Системе не удается найти указанный путь.". Первое, что нужно сделать в таких случаях - попытаться найти причину ошибки. Если причина известна, то будет понятен возможный способ её решения. Рассмотрим возможные варианты.
1. Самый простой случай, когда make вообще не запускается:
"make" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
Это сообщение сигнализирует о том, что операционная система не может найти утилиту make. Либо вообще не установлен тулчейн, либо по какой-то причине в системной переменной %Path% не прописан путь до утилиты make. Решение простое - убедиться, что установлен нужный тулчейн, где утилита make присутствует, и проверить, что в переменной окружения %Path% правильно задан путь для запуска утилиты make.
Для компиляции makefile-проектов для AVR (например, из библиотеки LUFA) нужен либо тулчейн WinAVR, либо AVR Studio, либо Atmel Studio.
2. В процессе работы make возникают ошибки. Нужно внимательно изучить выводимые сообщения, и по ним разбираться в причинах проблем. Самый частый случай - в системе установлено несколько разных тулчейнов, где присутствует утилита make.exe, и когда Вы выполняете команду make, то запускается утилита из не того тулчейна, который нужен.
К сожалению, в этом случае сообщения об ошибке утилиты make может быть не информативным, например:
Системе не удается найти указанный путь.
Найдите на жестком диске все исполняемые файлы make.exe, и если их несколько, то отредактируйте записи в переменной Path таким образом, чтобы make.exe нужного тулчейна запускалась в приоритете, т. е. чтобы её запись пути поиска находилась первой в списке путей.
Если у Вас установлено несколько версий WinAVR, то нужно удалить старые пути запуска из переменной окружения Path, чтобы оставить только пути до той версии WinAVR, с которой Вы сейчас работаете. Такое может произойти, если на компьютере переустанавливался WinAVR (например, раньше был WinAVR-20080610, а теперь стал WinAVR-20100110). Необходимо ОБЯЗАТЕЛЬНО очистить переменную окружения %Path% от старых путей, иначе пути включаемых файлов include будут вычисляться компилятором gcc неправильно. Нельзя допускать, чтобы старые пути WinAVR соседствовали в %Path% с новыми, даже если новые пути идут первыми. Например, из-за этого глюка я долго не мог разобраться, почему компилятор и линковщик никак не могут найти функцию eeprom_update_byte. Для проверки, какие реально включаемые пути использует компилятор (где он ищет h-файлы), используйте опцию -print-search-dirs (см. пункт 4).
Для быстрого переключения путей Path на разные версии WinAVR удобно использовать командные файлы с настроенной командой set на разные значение переменной окружения Path. Также существует очень удобная утилита Rapid Environment Editor site:rapidee.com, которая позволяет легко просматривать, изменять записи переменной Path, добавлять новые записи, изменять их положение в списке. Имейте в виду, чтобы редактировать системные записи переменной Path, необходимо запустить эту утилиту с правами администратора.
3. Изучать сообщение об ошибке нужно очень внимательно, чтобы понять причину проблемы. Вот еще один пример, где совсем не очевидно, что проблема кроется в отсутствии папки obj в корневом каталоге проекта.
c:\asm\lufa-LUFA-170418\Demos\Device\ClassDriver\GenericHID>make
' [INFO] :' Begin compilation of project \"GenericHID\"...
""
avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_1750) 5.4.0
Copyright (C) 2015 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.
Для разборок с запутанными операторами условной компиляции (#ifdef, #ifndef, #else и проч.) удобно использовать директивы #warning "сообщение" и #error "сообщение". Они позволяют точно определить, какую ветку в исходном тексте компилятор просмотрел, а какую отбросил.
Когда непонятно, почему не включается какой-нибудь заголовочный файл, удобно воспользоваться опцией -print-search-dirs, которая показывает пути поиска компилятором файлов. Эту опцию можно добавить в makefile к общим флагам компилятора, например так:
make: *** No rule to make target `opendous-jtag.elf', needed by `elf'. Stop.
make: *** Нет правила для сборки цели `opendous-jtag.elf', требуемой для `elf'. Останов.
Исправление ошибки:
1. Открыть makefile текстовым редактором, найти строку "elf:". В этой строке будет прописано имя цели, например:
...elf:
$(TARGET).elf...
2. make ругается на отсутствие этой цели $(TARGET).elf. Проверьте, правильно ли задана у Вас переменная TARGET, она должна быть задана строкой наподобие:
# Target file name (without extension).
TARGET= opendous-jtag
3. Если цель у Вас задана правильно, то возможно ошибка в описании действий по обработке цели. Найдите в makefile место, где обрабатывается цель elf. Это может быть блок текста наподобие следующего:
Здесь % означает "любой текст". Обычно такой знак используется для задания файлов определенного типа, например *.c, *.cpp, *.o и т. д. В некоторых случаях (например, в тулчейнах Atmel) такой паттерн обрабатывается неправильно, и не может быть автоматически сопоставлен с целью $(TARGET).elf. Поменяйте "%.elf:" на "$(TARGET).elf:", получится следующее:
------ Rebuild All started: Project: usbasploader, Configuration: default AVR ------
Build started.
Project "usbasploader.cproj" (ReBuild target(s)):
Target "PreBuildEvent" skipped, due to false condition; ('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreRebuild" in file "C:\Program Files\Atmel\Atmel Studio 6.0\Vs\Compiler.targets" from project
"C:\asm\USBasp-bootloader\usbasploader.cproj" (target "ReBuild" depends on it):
Using "RunCompilerTask" task from assembly "C:\Program Files\Atmel\Atmel Studio 6.0\Vs\Compiler.Task.dll".
Task "RunCompilerTask"
C:\Program Files\Atmel\Atmel Studio 6.0\make\make.exe -C "C:\asm\USBasp-bootloader" -f "Makefile" clean all
c:\Program Files\Atmel\Atmel Studio 6.0\make\rm.exe: cannot remove `*.o': Invalid argument
make: Entering directory `C:/asm/USBasp-bootloader'
rm -f usbasploader.hex main.bin *.o usbdrv/*.o main.s usbdrv/oddebug.s usbdrv/usbdrv.s
c:\Program Files\Atmel\Atmel Studio 6.0\make\rm.exe: cannot remove `usbdrv/*.o': Invalid argument
make: Leaving directory `C:/asm/USBasp-bootloader'
make: *** [clean] Error 1
Done executing task "RunCompilerTask" -- FAILED.
Done building target "CoreRebuild" in project "usbasploader.cproj" -- FAILED.
Done building project "usbasploader.cproj" -- FAILED.
Build FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========
Ошибку можно устранить, если в тулчейне Atmel Studio заменить утилиту rm.exe (обычно находится в папке c:\Program Files\Atmel\Atmel Studio 6.0\make) на rm.exe другой версии, которую можно взять из пакета WinAVR (обычно находится в папке c:\WinAVR-20100110\utils\bin).
USBtoSerial.c:1:0: error: unrecognized argument to -mmcu= option: 'ATmega32U4'
USBtoSerial.c:1:0: note: See --target-help for supported MCUs
Причина в регистре символов опции MCU, которая была указана через makefile (или через командную строку). В опции -mcmu тип микроконтроллера должен быть указан маленькими буквами, т. е. вместо ATmega32U4 нужно указать atmega32u4.
#это ошибочно указанный для avr-gcc тип микроконтроллера:
Часто задаваемый вопрос, который звучит примерно так: "Скажите пожалуйста, можно ли каким нибудь образом конвертировать проект, скомпилированный с помощью MinGW, в проект AVR Studio или в Atmel Studio?".
Здесь под "проектом MinGW" подразумевается обычный проект на основе makefile, который компилируется из командной строки командами make clean / make hex (и т. п.). Ответ на этот вопрос - можно, и довольно легко. Дело в том, и AVR Studio, и Atmel Studio ВСЕГДА использует для компиляции внешний компилятор gcc и среду компиляции на основе makefile (это называется тулчейн, он может быть установлен как отдельно в виде WinAVR, так и в составе Atmel Studio). Причем есть два способа такой компиляции - либо makefile генерируется для проекта на лету средой AVR Studio/Atmel Studio, либо подключается внешний makefile (это настраивается в свойствах проекта AVR Studio/Atmel Studio).
Таким образом, Вы можете, во-первых - подключить к проекту внешний makefile (возьмите его из "проекта, скомпилированного с помощью MinGW"). Однако такой makefile должен быть составлен по особым правилам (в частности, имя target должно совпадать с названием проекта), так что обратитесь к документации Atmel или сделайте makefile на основе готового примера. Это можно условно назвать "конвертировать проект MinGW в проект AVR Studio или Atmel Studio".
Во-вторых, если не подключать внешний makefile, то можно просто тупо посмотреть все опции, которые настроены в "проекте MinGW" (т. е. заданы в makefile), и создать аналогичные опции в среде настроек свойств обычного проекта AVR Studio (или Atmel Studio). Например, нужно задать такие же:
- тип процессора (обычно это опция DEVICE makefile). - тактовую частоту ядра (F_CPU). - библиотека для отладочного вывода printf (PRINTF_LIB и т. п.). - настройка опций генерации кода gcc - оптимизация и т. д. (CFLAGS).
Второй способ трудно назвать "конвертацией", потому что проект Вы будете настраивать вручную, подсматривая опции для настройки в готовом makefile "проекта MinGW". Однако и тут ничего сложного в принципе нет.
При перекомпиляции проекта Atmel Studio выдает ошибку наподобие "Целевой объект "PreBuildEvent" пропущен из-за невыполненного условия; выражение ('$(PreBuildEvent)'!='') равно (''!='')", и проект не компилируется.
Это просто глюк IDE Atmel Studio, связанный с ошибочной обработкой пустого списка событий до запуска сборки проекта (Pre-build event). Глюк можно обойти, если добавить ничего не значащее событие, которое есть, но ничего не делает. Для этого откройте свойства проекта, перейдите на закладку Build Events, нажмите кнопку Edit Pre-build и добавьте в список Pre-build event command line командную строку наподобие sleep 0, нажмите OK, сохраните проект.
После этого проект будет компилироваться нормально.
../usart.c:46:6: error: attempt to use poisoned "SIG_USART_RECV"
ISR (SIG_USART_RECV)
^
In file included from ../usart.c:1:0:
../usart.c: In function 'SIG_USART_RECV':
../usart.c:46:6: warning: 'SIG_USART_RECV' appears to be a misspelled signal handler [enabled by default]
ISR (SIG_USART_RECV)
^
make: *** [usart.o] Error 1
Build failed with 1 errors and 1 warnings...
Проект раньше нормально компилировался тулчейном WinAVR, и такая ошибка стала появляться при попытке компиляции тулчейном Atmel Studio. Проблема была решена возвратом к тулчейну WinAVR-20100110.
-MF dep/usart.o.d -c ../usart.c
../usart.c:47: warning: 'SIG_USART_RECV' appears to be a misspelled signal handler
Предупреждение стало появляться при переводе проекта с ATmega168 (настройка в makefile: MCU = atmega168) на ATmega328 (MCU = atmega328). Вот в этом месте кода возникало предупреждение (выделено жирным шрифтом):
Ошибка связана с тем, что в подключаемом файле, где определены векторы прерывания процессора, по-разному даны имена векторов прерываний для микроконтроллеров ATmega168 и ATmega328. Для того, чтобы узнать правильное имя вектора прерывания, откройте файл avr\include\avr\io.h тулчейна, найдите там строку с условием препроцессора, где проверяется тип процессора (в нашем примере надо найти __AVR_ATmega328__):
...
#elif defined (__AVR_ATmega328P__) || defined (__AVR_ATmega328__)
# include < avr/iom328p.h >
...
Строка #include < avr/iom328p.h > укажет на заголовочный файл, где определены регистры и вектора прерывания для процессора ATmega328. Откройте файл iom328p.h, и в секции определения векторов прерываний найдите нужное имя вектора прерывания (в данном примере имя вектора приема USART будет USART_RX_vect):
Когда программа скомпилирована с оптимизацией, есть некоторые трудности в использовании отладчика при просмотре переменных. Причина в том, что компилятор для переменных часто использует временные регистры, которые иногда не сохраняют свое значение в том месте, где нужно просмотреть переменную.
Как решить проблему, не прибегая к выключению отладки (опции -O0 и т. п.)? Иногда выключить отладку не представляется возможным. ИМХО самый простой способ - присвоить переменной атрибут volatile, тогда компилятор не будет её оптимизировать, и выделит для этой переменной отдельную ячейку памяти.
voidplacetimesectors (void)
{
volatile u8 ss, mm, hh;
RGB_t color;
ss = BCDtoBIN(rtc.reg.ss);
mm = BCDtoBIN(rtc.reg.mm);
hh = BCDtoBIN(rtc.reg.hh &0x1F);
Теперь переменные ss, mm и hh будут легко доступны при пошаговой отладки. Этот совет хорошо подходит для большинства компиляторов, как IAR, так и GCC.
Также для AVR GCC (начиная с версии 4.4) можно отключить оптимизацию для блока кода с помощью директивы pragma:
#pragma GCC push_options
#pragma GCC optimize ("O0")
//Код, где будет отключена оптимизация
...
#pragma GCC pop_options
Для функции можно отключить оптимизацию добавлением атрибута __attribute__((optimize("O0"))), например так:
void__attribute__((optimize("O0"))) foo(unsignedchar data) {
// не модифицируемый компилятором код
...
}
Среда AVR Studio при запуске компиляции проекта выдает ошибку: avr-gcc: CreateProcess: No such file or directory. Проблема здесь в том, что AVR Studio не может найти тулчейн (компилятор avr-gcc.exe и утилиту make.exe). Возможные причины:
1. Тулчейн не установлен. 2. В переменной окружения %Path% отсутствуют пути запуска для avr-gcc.exe и make.exe.
Как исправить: нужно установить тулчейн. Тулчейн это либо пакет WinAVR, либо тулчейн, который можно скачать и установить в составе Atmel Stidio или отдельно. Если у Вас есть уже установленная копия тулчейна, то достаточно добавить в переменную %Path%. полный путь до утилит avr-gcc.exe и make.exe.
Возможно, что для некоторых все вышесказанное кажется абракадаброй. Поэтому если Процесс по шагам (на примере AVR Studio 4.19, Windows 7 64-bit):
1. Скачайте архив [1].
2. Распакуйте из архива папку WinAVR-20100110 на диск C:
3. На этом шаге надо настроить (или проверить правильность) путей поиска в переменной %Path%. Кликните Пуск -> Панель управления -> Система -> Дополнительные параметры системы -> Переменные среды... -> нижний список Системные переменные -> Найдите в списке строку с переменной Path и выберите её -> нажмите на нижнюю кнопку Изменить... -> Проверьте, что в строке ввода пути есть пути C:\WinAVR-20100110\bin (в этой папке находится avr-gcc.exe) и C:\WinAVR-20100110\utils\bin (в этой папке находится make.exe). После того, как внесли изменения, кликните OK, OK и еще раз OK.
Примечание: помните, что отдельные записи в переменной Path отделяются друг от друга точкой с запятой. Если Вы затрудняетесь с редактированием переменных окружения, то прогуглите этот вопрос, в Интернете полно материала по теме.
Примерно так должна выглядеть переменная %Path% после редактирования (это результат выполнения команды echo %Path%, добавленные пути выделены жирным шрифтом):
4. Запустите AVR Studio, откройте проект, который у Вас компилировался с ошибкой. Откройте свойства проекта, перейдите в раздел Custom Options, снимите галочку Use AVR Toolchain, и с помощью кнопочек "..." добейтесь, чтобы для avr-gcc у Вас был путь:
Например, для ATmega16 следующий код скомпилируется нормально:
out_SFR_IO_ADDR(TIMSK), R24
Но для ATmega328 подобный код выдаст ошибку "Error: number must be positive and less than 64":
out_SFR_IO_ADDR(TIMSK1), R24
Такая ошибка происходит из-за того, что сделана попытка обратиться к регистру SFR (регистр специального назначения, Special Function Register) командой in или out, при этом адрес SFR превысил значение 63. У регистра TIMSK1 адрес равен 0x6F (десятичное 111), что как раз адрес превышает 63.
Исправить ошибку можно, если вместо out применить команду sts (in заменяется на lds):
К вопросу Q012-150508: "Проблема была решена возвратом к тулчейну WinAVR-20100110". Можно было и не возвращаться. В файле io.h в секторе vector есть имена *_vector, их и надо использовать.
Комментарии
------ Build started: Project: GccApplication1, Configuration: Debug AVR ------
Using "RunCompilerTask " task from assembly "C:Program Files (x86)AtmelAtmel Studio 6.2ExtensionsAppl icationAvrGCC.dll".
Task "RunCompilerTask "
Shell Utils Path C:Program Files (x86)AtmelAtmel Studio 6.2shellUtils
C:Program Files (x86)AtmelAtmel Studio 6.2shellUtilsmake .exe all
make: *** [GccApplication 1.o] Error 1
Done executing task "RunCompilerTask " -- FAILED.
Done building target "CoreBuild" in project "GccApplication1.cproj" -- FAILED.
Done building project "GccApplication1.cproj" -- FAILED.
Build FAILED.
========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
RSS лента комментариев этой записи