SergeyDDD 0 26 апреля, 2011 Опубликовано 26 апреля, 2011 · Жалоба Ребята!!! Дайте мне пожалуйста ответ... Каким образом Вы мониторите периферийные регистры при отладке? (J-Link+GDB+Zylin) Пока я нащупал два варианта, но они очень неудобны 1. В окне "Expressions" вбиваю адрес регистра в виде *((unsigned int *) (адрес регистра))) 2. В Memory Monitor вбиваю адрес регистра Какие еще есть методы? Заранее спасибо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 26 апреля, 2011 Опубликовано 26 апреля, 2011 · Жалоба Зависимость указывается так: 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 неверно отрабатывает? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mdmitry 0 26 апреля, 2011 Опубликовано 26 апреля, 2011 · Жалоба есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает? Посмотрите какие версии make работают во всех Ваших случаях. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 26 апреля, 2011 Опубликовано 26 апреля, 2011 · Жалоба есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает? Вряд ли... У меня их тоже куча установлена, все свалены в одну кучу, и никаких проблем. От версии make в принципе тоже не должно зависеть (если это не Borland make конечно:) ). Хотя что-то припоминаю про кривой make в составе WinAVR. Но всё же думаю, что какой-то глючок в плагине. Попробуйте пересоздать проект по-новой. Или уж сделайте небольшое усилие и напишите свой makefile (ведь совсем немного осталось наверное?). И перестаньте зависеть от плагинов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 26 апреля, 2011 Опубликовано 26 апреля, 2011 · Жалоба напишите свой makefile (ведь совсем немного осталось наверное?). И перестаньте зависеть от плагинов. О чём и речь. Ан нет! Уж если и тратить попусту время, то на борьбу с плагинами! Как говорится: "Взялся за гуж - не забудь принять душ". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 26 апреля, 2011 Опубликовано 26 апреля, 2011 · Жалоба я бы хотел прежде услышать критику вышеприведенных makefile, чтобы понять, наконец, чем плох плагин. прошу поэтому помощи у тех, кто собаку съел в этих скриптах - что может быть проще, чем просмотреть и указать проблемы? и мне наука... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
IgorKossak 0 26 апреля, 2011 Опубликовано 26 апреля, 2011 · Жалоба Науку Вам уже указали и не только я. А плохость плагинов хотя бы в том, что они: "# Automatically-generated file. Do not edit!" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 26 апреля, 2011 Опубликовано 26 апреля, 2011 · Жалоба Науку Вам уже указали и не только я. А плохость плагинов хотя бы в том, что они: "# 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? я вижу, что нет "цели" для ассемблерного файла... почему? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 27 апреля, 2011 Опубликовано 27 апреля, 2011 · Жалоба я бы хотел прежде услышать критику вышеприведенных makefile Они слишком запутаны, в них трудно разбираться человеку. Ибо они не рассчитаны на это. Я честно пытался, но явных ляпов не увидел. Но я не увидел в нём файла startup_stm32f10x_md_vl.s. По идее там должно быть что-то типа A_SRCS += startup_stm32f10x_md_vl.s и OBJS += startup_stm32f10x_md_vl.o Не хватает также правила для компиляции ассемблерных файлов, типа src/%.o: ../src/%.s Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 27 апреля, 2011 Опубликовано 27 апреля, 2011 · Жалоба Они слишком запутаны, в них трудно разбираться человеку. Ибо они не рассчитаны на это. Я честно пытался, но явных ляпов не увидел. Но я не увидел в нём файла startup_stm32f10x_md_vl.s. По идее там должно быть что-то типа A_SRCS += startup_stm32f10x_md_vl.s и OBJS += startup_stm32f10x_md_vl.o Не хватает также правила для компиляции ассемблерных файлов, типа src/%.o: ../src/%.s спасибо! эти самые мысли (сложно, ляпов нет, но нет правил и указания ассемблерного файла) пришли и мне в голову. остается теперь решить чисто эклипсовый вопрос: почему ассемблерные файлы не добавились в проект автоматически, хотя все прочие делают это автоматом? е еще вопрос по компиляции: -fnostartup что означает? его надо или не надо использовать? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 27 апреля, 2011 Опубликовано 27 апреля, 2011 · Жалоба чисто эклипсовый вопрос: почему ассемблерные файлы не добавились в проект автоматически, хотя все прочие делают это автоматом? В том-то и дело, что это вопрос не к эклипсе, а к плагину. Ибо эклипса сама по себе не делает различий между файлами. еще вопрос по компиляции: -fnostartup что означает? его надо или не надо использовать? -nostartfiles? Это ключ линкера, отменяет линковку библиотечного стартапа. Если есть свой стартап (а у вас он есть), то этот ключ нужен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 27 апреля, 2011 Опубликовано 27 апреля, 2011 · Жалоба -nostartfiles? Это ключ линкера, отменяет линковку библиотечного стартапа. Если есть свой стартап (а у вас он есть), то этот ключ нужен.спасибо. а когда этот ключ не нужен? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 27 апреля, 2011 Опубликовано 27 апреля, 2011 · Жалоба Ну например, если компилим под виндовс. Или под линукс. А на маленьких платформах практически всегда свой стартап. Хотя нет, под msp-gcc я использовал штатный, было нормально:) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ARV 0 27 апреля, 2011 Опубликовано 27 апреля, 2011 · Жалоба я тут вычитал, что не подхватывание ассемблерных файлов - это проблема CDT-плугина, а не ARM-овского... предлагают лечить странными методами: некоторые пишут, надо добавить в список "поддерживаемых" файлов "*.S", а другие говорят, что "по неизвестным причинам CDT не обрабатывает *.s файлы, хотя в списке поддерживаемых такая маска указана дефолтно, зато помогает переименовывание исходника в *.S - то есть с заглавной буквой". самое интересное в том, что добавить к списку поддерживаемых файлов *.S невозможно, т.к. пишет, что такой тип уже зарегистрирован (видимо, сравнение масок ведется без учета регистра). и как быть с этим? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 27 апреля, 2011 Опубликовано 27 апреля, 2011 · Жалоба А в чем заключается "неподхватывание"? Вот я добавляю к проекту папку, там есть *.c и *.S файлы. Все они открываются в редакторе, если щёлкнуть по ним мышкой. Все сохраняются при запуске компиляции. Что ещё нужно? Всё, что касается компиляции, зависимостей и прочего - это в ведении моего makefile, там я сам всё что надо прописываю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться