| |
|
  |
 Вопросы по Eclipse, CDT, Zylin embedded CDT, предлагаю обсуждать тут, может потом FAQ выжмем |
|
|
|
|
 Apr 26 2011, 10:01
|
Профессионал
Группа: Свой
Сообщений: 1 143
Регистрация: 30-09-08
Из: Новочеркасск
Пользователь №: 40 581
|
Цитата(alx2 @ Apr 26 2011, 09:05)  Зависимость указывается так: Код file.o: file.c file.h Это означает, что file.o зависит от файлов file.c и file.h и при модификации любого из них будет создаваться заново. внимательно изучаю автосгенерированные make-файлы и не вижу причин, почему у меня поведение компилятора не совсем правильное... вот такие файлы лежат в папке таргета: makefileКод ################################################################################
# Automatically-generated file. Do not edit!
################################################################################
-include ../makefile.init
RM := rm -rf
# All of the sources participating in the build are defined here
-include sources.mk
-include subdir.mk
-include src/subdir.mk
-include src/Utilities/subdir.mk
-include src/STM32F10x_StdPeriph_Driver/src/subdir.mk
-include objects.mk
ifneq ($(MAKECMDGOALS),clean)
ifneq ($(strip $(C_DEPS)),)
-include $(C_DEPS)
endif
ifneq ($(strip $(ASM_DEPS)),)
-include $(ASM_DEPS)
endif
ifneq ($(strip $(S_UPPER_DEPS)),)
-include $(S_UPPER_DEPS)
endif
endif
-include ../makefile.defs
# Add inputs and outputs from these tool invocations to the build variables
SECONDARY_FLASH += \
test3.hex \
SECONDARY_LIST += \
test3.lst \
SECONDARY_SIZE += \
test3.siz \
# All Target
all: test3.elf secondary-outputs
# Tool invocations
test3.elf: $(OBJS) $(USER_OBJS)
@echo 'Building target: $@'
@echo 'Invoking: ARM Yagarto Windows GCC C Linker'
arm-none-eabi-gcc -nostartfiles -Xlinker --gc-sections -Wl,-Map,test3.map -mcpu=cortex-m3 -mthumb -g3 -gdwarf-2 -o"test3.elf" $(OBJS) $(USER_OBJS) $(LIBS)
@echo 'Finished building target: $@'
@echo ' '
test3.hex: test3.elf
@echo 'Invoking: ARM Yagarto Windows GNU Create Flash Image'
arm-none-eabi-objcopy -O ihex test3.elf "test3.hex"
@echo 'Finished building: $@'
@echo ' '
test3.lst: test3.elf
@echo 'Invoking: ARM Yagarto Windows GNU Create Listing'
arm-none-eabi-objdump -h -S test3.elf >"test3.lst"
@echo 'Finished building: $@'
@echo ' '
test3.siz: test3.elf
@echo 'Invoking: ARM Yagarto Windows GNU Print Size'
arm-none-eabi-size --format=berkeley test3.elf
@echo 'Finished building: $@'
@echo ' '
# Other Targets
clean:
-$(RM) $(SECONDARY_SIZE)$(OBJS)$(C_DEPS)$(ASM_DEPS)$(SECONDARY_FLASH)$(EXECUTABLES)$(SECONDARY_LIST)$(S_UPPER_DEPS) test3.elf
-@echo ' '
secondary-outputs: $(SECONDARY_FLASH) $(SECONDARY_LIST) $(SECONDARY_SIZE)
.PHONY: all clean dependents
.SECONDARY:
-include ../makefile.targets sources.mkКод ################################################################################
# Automatically-generated file. Do not edit!
################################################################################
ELF_SRCS :=
O_SRCS :=
C_SRCS :=
S_UPPER_SRCS :=
OBJ_SRCS :=
ASM_SRCS :=
SECONDARY_SIZE :=
OBJS :=
C_DEPS :=
ASM_DEPS :=
SECONDARY_FLASH :=
EXECUTABLES :=
SECONDARY_LIST :=
S_UPPER_DEPS :=
# Every subdirectory with source files must be described here
SUBDIRS := \
src \
src/Utilities \
src/STM32F10x_StdPeriph_Driver/src \ objects.mkКод ################################################################################
# Automatically-generated file. Do not edit!
################################################################################
USER_OBJS :=
LIBS := в подпапках с исходниками тоже есть subdir.mkКод ################################################################################
# Automatically-generated file. Do not edit!
################################################################################
# Add inputs and outputs from these tool invocations to the build variables
C_SRCS += \
../src/core_cm3.c \
../src/main.c \
../src/stm32f10x_it.c \
../src/system_stm32f10x.c
OBJS += \
./src/core_cm3.o \
./src/main.o \
./src/stm32f10x_it.o \
./src/system_stm32f10x.o
C_DEPS += \
./src/core_cm3.d \
./src/main.d \
./src/stm32f10x_it.d \
./src/system_stm32f10x.d
# Each subdirectory must supply rules for building sources it contributes
src/%.o: ../src/%.c
@echo 'Building file: $<'
@echo 'Invoking: ARM Yagarto Windows GCC C Compiler'
arm-none-eabi-gcc -DUSE_STM32_DISCOVERY -DUSE_STDPERIPH_DRIVER -DSTM32F10X_MD_VL -I"G:\PRJ\ARM\test3\src\STM32F10x_StdPeriph_Driver\inc" -I"G:\PRJ\ARM\test3\src\STM32F10x_StdPeriph_Driver\src" -I"G:\PRJ\ARM\test3\src\Utilities" -I"G:\PRJ\ARM\test3\src" -O0 -ffunction-sections -fdata-sections -Wall -Wa,-adhlns="$@.lst" -c -fmessage-length=0 -MMD -MP -MF"$(@:%.o=%.d)" -MT"$(@:%.o=%.d)" -mcpu=cortex-m3 -mthumb -g3 -gdwarf-2 -o"$@" "$<"
@echo 'Finished building: $<'
@echo ' ' на сколько я могу судить, зависимости создаются и должны учитываться. почти такой же формат имеет скрипт, генерируемый Eclipse для WinAVR - отличия в небольших нюансах, но, как я думаю, они не должны влиять - сборка WinAVR идет отлично - только измененные файлы и т.п. есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает?
--------------------
Я бы взял частями... но мне надо сразу.
|
|
|
|
|
|
|
|
Apr 26 2011, 14:54
|
Начинающий профессионал
Группа: Свой
Сообщений: 1 215
Регистрация: 25-10-06
Из: СПб
Пользователь №: 21 648
|
Цитата(ARV @ Apr 26 2011, 14:01) есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает? Посмотрите какие версии make работают во всех Ваших случаях.
--------------------
Наука изощряет ум; ученье вострит память. Козьма Прутков
|
|
|
|
|
|
|
|
Apr 26 2011, 15:14
|
фанат дивана
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684
|
Цитата(ARV @ Apr 26 2011, 16:01) есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает? Вряд ли... У меня их тоже куча установлена, все свалены в одну кучу, и никаких проблем. От версии make в принципе тоже не должно зависеть (если это не Borland make конечно  ). Хотя что-то припоминаю про кривой make в составе WinAVR. Но всё же думаю, что какой-то глючок в плагине. Попробуйте пересоздать проект по-новой. Или уж сделайте небольшое усилие и напишите свой makefile (ведь совсем немного осталось наверное?). И перестаньте зависеть от плагинов.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
|
|
|
Apr 26 2011, 17:44
|
Профессионал
Группа: Свой
Сообщений: 1 143
Регистрация: 30-09-08
Из: Новочеркасск
Пользователь №: 40 581
|
Цитата(IgorKossak @ Apr 26 2011, 21:33) Науку Вам уже указали и не только я. А плохость плагинов хотя бы в том, что они: "# Automatically-generated file. Do not edit!" да в том-то и дело, что вместо науки вы декларируете ущербность моего подхода, а в пользу своего только говорите "я так делаю - и доволен". я не буду спорить с очевидным - полный контроль лучше частичного, но если мне достаточно уметь крутить руль, чтобы ехать - настоящий механик, не вылезающий из-под капота, меня не поймет... так и здесь: мне пока хватит галочек. тем более что с некомпиляцией я разобрался. остается вопрос более "страшный": Цитата c:/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.0/../../../../arm-none-eabi/bin/ld.exe: warning: cannot find entry symbol _start; defaulting to 00008000
Finished building target: test3.elf
Invoking: ARM Yagarto Windows GNU Create Flash Image
arm-none-eabi-objcopy -O ihex test3.elf "test3.hex"
Finished building: test3.hex
Invoking: ARM Yagarto Windows GNU Create Listing
arm-none-eabi-objdump -h -S test3.elf >"test3.lst"
Finished building: test3.lst
Invoking: ARM Yagarto Windows GNU Print Size
arm-none-eabi-size --format=berkeley test3.elf
text data bss dec hex filename
0 0 0 0 0 test3.elf
Finished building: test3.siz куда пропал _start? почему не компилируется ассемблерный файл startup_stm32f10x_md_vl.s? я вижу, что нет "цели" для ассемблерного файла... почему?
--------------------
Я бы взял частями... но мне надо сразу.
|
|
|
|
|
|
|
|
Apr 27 2011, 03:47
|
фанат дивана
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684
|
Цитата(ARV @ Apr 26 2011, 23:29) я бы хотел прежде услышать критику вышеприведенных makefile Они слишком запутаны, в них трудно разбираться человеку. Ибо они не рассчитаны на это. Я честно пытался, но явных ляпов не увидел. Но я не увидел в нём файла startup_stm32f10x_md_vl.s. По идее там должно быть что-то типа Код A_SRCS += startup_stm32f10x_md_vl.s и Код OBJS += startup_stm32f10x_md_vl.o Не хватает также правила для компиляции ассемблерных файлов, типа Код src/%.o: ../src/%.s
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
|
|
|
Apr 27 2011, 04:59
|
Профессионал
Группа: Свой
Сообщений: 1 143
Регистрация: 30-09-08
Из: Новочеркасск
Пользователь №: 40 581
|
Цитата(AHTOXA @ Apr 27 2011, 07:47) Они слишком запутаны, в них трудно разбираться человеку. Ибо они не рассчитаны на это. Я честно пытался, но явных ляпов не увидел. Но я не увидел в нём файла startup_stm32f10x_md_vl.s. По идее там должно быть что-то типа Код A_SRCS += startup_stm32f10x_md_vl.s и Код OBJS += startup_stm32f10x_md_vl.o Не хватает также правила для компиляции ассемблерных файлов, типа Код src/%.o: ../src/%.s спасибо! эти самые мысли (сложно, ляпов нет, но нет правил и указания ассемблерного файла) пришли и мне в голову. остается теперь решить чисто эклипсовый вопрос: почему ассемблерные файлы не добавились в проект автоматически, хотя все прочие делают это автоматом? е еще вопрос по компиляции: -fnostartup что означает? его надо или не надо использовать?
--------------------
Я бы взял частями... но мне надо сразу.
|
|
|
|
|
|
|
|
Apr 27 2011, 05:35
|
фанат дивана
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684
|
Цитата(ARV @ Apr 27 2011, 10:59) чисто эклипсовый вопрос: почему ассемблерные файлы не добавились в проект автоматически, хотя все прочие делают это автоматом? В том-то и дело, что это вопрос не к эклипсе, а к плагину. Ибо эклипса сама по себе не делает различий между файлами. Цитата(ARV @ Apr 27 2011, 10:59) еще вопрос по компиляции: -fnostartup что означает? его надо или не надо использовать? -nostartfiles? Это ключ линкера, отменяет линковку библиотечного стартапа. Если есть свой стартап (а у вас он есть), то этот ключ нужен.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
|
|
|
Apr 27 2011, 06:33
|
Профессионал
Группа: Свой
Сообщений: 1 143
Регистрация: 30-09-08
Из: Новочеркасск
Пользователь №: 40 581
|
я тут вычитал, что не подхватывание ассемблерных файлов - это проблема CDT-плугина, а не ARM-овского... предлагают лечить странными методами: некоторые пишут, надо добавить в список "поддерживаемых" файлов "*.S", а другие говорят, что "по неизвестным причинам CDT не обрабатывает *.s файлы, хотя в списке поддерживаемых такая маска указана дефолтно, зато помогает переименовывание исходника в *.S - то есть с заглавной буквой".
самое интересное в том, что добавить к списку поддерживаемых файлов *.S невозможно, т.к. пишет, что такой тип уже зарегистрирован (видимо, сравнение масок ведется без учета регистра). и как быть с этим?
--------------------
Я бы взял частями... но мне надо сразу.
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
