Перейти к содержанию
    

Вопросы по Eclipse, CDT, Zylin embedded CDT

Ребята!!! Дайте мне пожалуйста ответ...

 

Каким образом Вы мониторите периферийные регистры при отладке? (J-Link+GDB+Zylin)

 

Пока я нащупал два варианта, но они очень неудобны

1. В окне "Expressions" вбиваю адрес регистра в виде *((unsigned int *) (адрес регистра)))

2. В Memory Monitor вбиваю адрес регистра

 

Какие еще есть методы?

 

Заранее спасибо

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Зависимость указывается так:

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="[email protected]" -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 неверно отрабатывает?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает?

Посмотрите какие версии make работают во всех Ваших случаях.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает?

Вряд ли... У меня их тоже куча установлена, все свалены в одну кучу, и никаких проблем. От версии make в принципе тоже не должно зависеть (если это не Borland make конечно:) ). Хотя что-то припоминаю про кривой make в составе WinAVR. Но всё же думаю, что какой-то глючок в плагине. Попробуйте пересоздать проект по-новой.

Или уж сделайте небольшое усилие и напишите свой makefile (ведь совсем немного осталось наверное?). И перестаньте зависеть от плагинов.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

напишите свой makefile (ведь совсем немного осталось наверное?). И перестаньте зависеть от плагинов.

О чём и речь.

Ан нет! Уж если и тратить попусту время, то на борьбу с плагинами! Как говорится: "Взялся за гуж - не забудь принять душ".

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я бы хотел прежде услышать критику вышеприведенных makefile, чтобы понять, наконец, чем плох плагин.

прошу поэтому помощи у тех, кто собаку съел в этих скриптах - что может быть проще, чем просмотреть и указать проблемы? и мне наука...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Науку Вам уже указали и не только я. А плохость плагинов хотя бы в том, что они: "# Automatically-generated file. Do not edit!"

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Науку Вам уже указали и не только я. А плохость плагинов хотя бы в том, что они: "# 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?

я вижу, что нет "цели" для ассемблерного файла... почему?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я бы хотел прежде услышать критику вышеприведенных makefile

Они слишком запутаны, в них трудно разбираться человеку. Ибо они не рассчитаны на это.

Я честно пытался, но явных ляпов не увидел. Но я не увидел в нём файла startup_stm32f10x_md_vl.s. По идее там должно быть что-то типа

A_SRCS += startup_stm32f10x_md_vl.s

и

OBJS += startup_stm32f10x_md_vl.o

Не хватает также правила для компиляции ассемблерных файлов, типа

src/%.o: ../src/%.s

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Они слишком запутаны, в них трудно разбираться человеку. Ибо они не рассчитаны на это.

Я честно пытался, но явных ляпов не увидел. Но я не увидел в нём файла startup_stm32f10x_md_vl.s. По идее там должно быть что-то типа

A_SRCS += startup_stm32f10x_md_vl.s

и

OBJS += startup_stm32f10x_md_vl.o

Не хватает также правила для компиляции ассемблерных файлов, типа

src/%.o: ../src/%.s

 

спасибо! эти самые мысли (сложно, ляпов нет, но нет правил и указания ассемблерного файла) пришли и мне в голову. остается теперь решить чисто эклипсовый вопрос: почему ассемблерные файлы не добавились в проект автоматически, хотя все прочие делают это автоматом?

 

 

е еще вопрос по компиляции: -fnostartup что означает? его надо или не надо использовать?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

чисто эклипсовый вопрос: почему ассемблерные файлы не добавились в проект автоматически, хотя все прочие делают это автоматом?

В том-то и дело, что это вопрос не к эклипсе, а к плагину. Ибо эклипса сама по себе не делает различий между файлами.

еще вопрос по компиляции: -fnostartup что означает? его надо или не надо использовать?

-nostartfiles? Это ключ линкера, отменяет линковку библиотечного стартапа. Если есть свой стартап (а у вас он есть), то этот ключ нужен.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

-nostartfiles? Это ключ линкера, отменяет линковку библиотечного стартапа. Если есть свой стартап (а у вас он есть), то этот ключ нужен.
спасибо. а когда этот ключ не нужен?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну например, если компилим под виндовс. Или под линукс. А на маленьких платформах практически всегда свой стартап.

Хотя нет, под msp-gcc я использовал штатный, было нормально:)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

я тут вычитал, что не подхватывание ассемблерных файлов - это проблема CDT-плугина, а не ARM-овского... предлагают лечить странными методами: некоторые пишут, надо добавить в список "поддерживаемых" файлов "*.S", а другие говорят, что "по неизвестным причинам CDT не обрабатывает *.s файлы, хотя в списке поддерживаемых такая маска указана дефолтно, зато помогает переименовывание исходника в *.S - то есть с заглавной буквой".

 

самое интересное в том, что добавить к списку поддерживаемых файлов *.S невозможно, т.к. пишет, что такой тип уже зарегистрирован (видимо, сравнение масок ведется без учета регистра). и как быть с этим?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А в чем заключается "неподхватывание"? Вот я добавляю к проекту папку, там есть *.c и *.S файлы. Все они открываются в редакторе, если щёлкнуть по ним мышкой. Все сохраняются при запуске компиляции. Что ещё нужно?

Всё, что касается компиляции, зависимостей и прочего - это в ведении моего makefile, там я сам всё что надо прописываю.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...