Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Вопросы по Eclipse, CDT, Zylin embedded CDT
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > GNU/OpenSource средства разработки
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
ARV
пока что я вижу очень подозрительное поведение make, заключающееся в том, что не проверяется "свежесть" файлов, подлежащих компиляции. по-моему, make должна сравнивать дату исходника и дату объектника, и если они не совпадают, перекомпилировать исходник. разве нет? я же вижу, что проверяется только main.c, причем при его обновлении перекомпилируется весь проект, а не только обновленные файлы, что тоже как-то странно. если в makefile эта ситуация лечится какими-то скриптовыми возможностями - подскажите, какими, ибо по GNU-make я скачал талмуд, чтение которого отнимет у меня месяц, т.к. искать я буду неизвестно что...
другие глубинные процессы вряд ли могут меня заинтересовать на данном этапе.
dimka76
Цитата(ARV @ Apr 24 2011, 10:27) *
а вот вопрос у меня совсем непонятный... собираю проект, расставив галочки - пользуюсь этим плагином. но вот вопрос: если я изменяю любой файл проекта, кроме основного, Build начинается и заканчивается линковщикомм - то есть собирается все из старых объектников без компиляции измененного файла. более того, если делаю Clean - объектники удаляются, после чего запускается линкер - и снова все ништяк sad.gif и только если в главном файле вставить пробел и сохранить файл - начинается пересборка проекта, как положено...

я чего-то не понимаю или в чем дело-то?


P.S. пользуюсь Yagarto


В эклипсе есть настройка сохранять все перед сборкой.
Она тут Menu->Window->Preferences->General->Workspace и поставить галку на Save automatically before build

Цитата(ARV @ Apr 25 2011, 8:23)
пока что я вижу очень подозрительное поведение make, заключающееся в том, что не проверяется "свежесть" файлов, подлежащих компиляции. по-моему, make должна сравнивать дату исходника и дату объектника, и если они не совпадают, перекомпилировать исходник. разве нет?
................


Если вы имеете ввиду рукописный маке, а не сгенерированный плагином, то у меня была похожая ситуация, только у меня перекомпилировались всегда все файлы, даже те которые не менялись.
Я правда не велики спец в области make файлов. Взял другой маке, с которым все работало правильно (компилировались только измененые файлы или ничего не компилировалось если не менялось, а только линковалось),подправил немного под себя и теперь пользуюсь только им.

Если интересно, то вот он.
Нажмите для просмотра прикрепленного файла
И еще. Как я понял, должны создаваться файлы зависимостей, например main.o.d. Вот на основе их он принимает решение перекомпилировать или нет. И это должно указываться в маке файле.
ARV
Цитата(dimka76 @ Apr 25 2011, 10:20) *
В эклипсе есть настройка сохранять все перед сборкой.
Она тут Menu->Window->Preferences->General->Workspace и поставить галку на Save automatically before build
это не помогает...

Цитата(dimka76 @ Apr 25 2011, 10:20) *
Если вы имеете ввиду рукописный маке, а не сгенерированный плагином, то у меня была похожая ситуация, только у меня перекомпилировались всегда все файлы, даже те которые не менялись.
Я правда не велики спец в области make файлов. Взял другой маке, с которым все работало правильно (компилировались только измененые файлы или ничего не компилировалось если не менялось, а только линковалось),подправил немного под себя и теперь пользуюсь только им.
как раз интересует сгенерированный плагином makefile. точнее, причины такого поведения и методы борьбы (рукописание файлов оставляю на самый последний крайний случай)

Цитата(dimka76 @ Apr 25 2011, 10:20) *
Как я понял, должны создаваться файлы зависимостей, например main.o.d. Вот на основе их он принимает решение перекомпилировать или нет. И это должно указываться в маке файле.
и как это должно указываться?
dimka76
Цитата(ARV @ Apr 25 2011, 10:36) *
и как это должно указываться?


Я не знаю.
Посмотрите тот файл, который я приложил выше. Может вам удастся оттуда выудить информацию.

А у вас файлы такие как main.o.d появляются?
alx2
Цитата(ARV @ Apr 25 2011, 11:36) *
и как это должно указываться?

Зависимость указывается так:
Код
file.o: file.c file.h
Это означает, что file.o зависит от файлов file.c и file.h и при модификации любого из них будет создаваться заново.
Еще у make есть ключ -d, включающий отладочный вывод. Там выводится огромное количество ненужной информации, но среди всего этого можно увидеть и понять, почему make ведет себя не так, как ожидается.
SergeyDDD
Ребята!!! Дайте мне пожалуйста ответ...

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

Пока я нащупал два варианта, но они очень неудобны
1. В окне "Expressions" вбиваю адрес регистра в виде *((unsigned int *) (адрес регистра)))
2. В Memory Monitor вбиваю адрес регистра

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

Заранее спасибо
ARV
Цитата(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 неверно отрабатывает?

mdmitry
Цитата(ARV @ Apr 26 2011, 14:01) *
есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает?

Посмотрите какие версии make работают во всех Ваших случаях.
AHTOXA
Цитата(ARV @ Apr 26 2011, 16:01) *
есть подозрение, что make из Yagarto работает не так, либо проблема в чем-то похожем, например, в том, что у меня стоит WinAVR, MinGW и Yagarto, и все прописаны в path... может такое быть, что "чужая" make неверно отрабатывает?

Вряд ли... У меня их тоже куча установлена, все свалены в одну кучу, и никаких проблем. От версии make в принципе тоже не должно зависеть (если это не Borland make конечноsm.gif ). Хотя что-то припоминаю про кривой make в составе WinAVR. Но всё же думаю, что какой-то глючок в плагине. Попробуйте пересоздать проект по-новой.
Или уж сделайте небольшое усилие и напишите свой makefile (ведь совсем немного осталось наверное?). И перестаньте зависеть от плагинов.
IgorKossak
Цитата(AHTOXA @ Apr 26 2011, 18:14) *
напишите свой makefile (ведь совсем немного осталось наверное?). И перестаньте зависеть от плагинов.

О чём и речь.
Ан нет! Уж если и тратить попусту время, то на борьбу с плагинами! Как говорится: "Взялся за гуж - не забудь принять душ".
ARV
я бы хотел прежде услышать критику вышеприведенных makefile, чтобы понять, наконец, чем плох плагин.
прошу поэтому помощи у тех, кто собаку съел в этих скриптах - что может быть проще, чем просмотреть и указать проблемы? и мне наука...
IgorKossak
Науку Вам уже указали и не только я. А плохость плагинов хотя бы в том, что они: "# Automatically-generated file. Do not edit!"
ARV
Цитата(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?
я вижу, что нет "цели" для ассемблерного файла... почему?
AHTOXA
Цитата(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

ARV
Цитата(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 что означает? его надо или не надо использовать?

AHTOXA
Цитата(ARV @ Apr 27 2011, 10:59) *
чисто эклипсовый вопрос: почему ассемблерные файлы не добавились в проект автоматически, хотя все прочие делают это автоматом?

В том-то и дело, что это вопрос не к эклипсе, а к плагину. Ибо эклипса сама по себе не делает различий между файлами.
Цитата(ARV @ Apr 27 2011, 10:59) *
еще вопрос по компиляции: -fnostartup что означает? его надо или не надо использовать?

-nostartfiles? Это ключ линкера, отменяет линковку библиотечного стартапа. Если есть свой стартап (а у вас он есть), то этот ключ нужен.
ARV
Цитата(AHTOXA @ Apr 27 2011, 09:35) *
-nostartfiles? Это ключ линкера, отменяет линковку библиотечного стартапа. Если есть свой стартап (а у вас он есть), то этот ключ нужен.
спасибо. а когда этот ключ не нужен?
AHTOXA
Ну например, если компилим под виндовс. Или под линукс. А на маленьких платформах практически всегда свой стартап.
Хотя нет, под msp-gcc я использовал штатный, было нормальноsm.gif
ARV
я тут вычитал, что не подхватывание ассемблерных файлов - это проблема CDT-плугина, а не ARM-овского... предлагают лечить странными методами: некоторые пишут, надо добавить в список "поддерживаемых" файлов "*.S", а другие говорят, что "по неизвестным причинам CDT не обрабатывает *.s файлы, хотя в списке поддерживаемых такая маска указана дефолтно, зато помогает переименовывание исходника в *.S - то есть с заглавной буквой".

самое интересное в том, что добавить к списку поддерживаемых файлов *.S невозможно, т.к. пишет, что такой тип уже зарегистрирован (видимо, сравнение масок ведется без учета регистра). и как быть с этим?
AHTOXA
А в чем заключается "неподхватывание"? Вот я добавляю к проекту папку, там есть *.c и *.S файлы. Все они открываются в редакторе, если щёлкнуть по ним мышкой. Все сохраняются при запуске компиляции. Что ещё нужно?
Всё, что касается компиляции, зависимостей и прочего - это в ведении моего makefile, там я сам всё что надо прописываю.
ARV
Цитата(AHTOXA @ Apr 27 2011, 11:54) *
Всё, что касается компиляции, зависимостей и прочего - это в ведении моего makefile, там я сам всё что надо прописываю.
это с точки зрения компилятора кроме makefile нет ничего. но в этой теме обсуждают Eclipse и иже с ним. насколько я смог понять, упомянутые ранее сложные makefile генерирует плугин CDT - поправьте, если я не прав. так вот, в моем случае почему-то этот плугин не добавляет в makefile сорцы на ассемблере.я, конечно, понимаю, что совет "пиши makefile ручками" снимает все проблемы, но тогда надо продолжить "редактируй файлы в блокноте" - почему нет? если я не умею пользоваться Eclipse - подскажите, чего я еще не знаю про него. Если проблема в самом Eclipse - то это другой вопрос, и надо его решать. как раз благодаря тому, что от проблемы все бегут в ручную правку makefile плагин может не развиваться многие годы...


к сожалению, только дома я могу проверять свои догадки и пытаться найти решение... поэтому пока что жду советов и т.п.
Сергей Борщ
QUOTE (ARV @ Apr 27 2011, 12:58) *
насколько я смог понять, упомянутые ранее сложные makefile генерирует плугин CDT - поправьте, если я не прав.
Поправляем. Не прав. Это делает
QUOTE (IgorKossak @ Mar 16 2011, 21:06) *
http://sourceforge.net/projects/gnuarmeclipse/
Формирователь мейкфайлов путём расставления галочек в формах для пяти разных популярных тулчейнов.
И вы это интуитивно вроде бы понимаете, ибо
QUOTE (ARV @ Apr 24 2011, 09:27) *
а вот вопрос у меня совсем непонятный... собираю проект, расставив галочки - пользуюсь этим плагином.
Но поскольку вы, похоже, единственный, кто расставляет галочки - то увы, придется разбираться самостоятельно.

А CDT - совершенно другой плагин.

И обратите внимание - в мире GCC принято, что .S и .s - разные файлы. Первый gcc сначала обрабатывает сишным препроцессором и лишь потом передает ассемблеру as, а второй - сразу передает в as.
ARV
я полностью в курсе разницы между s и S файлами.
на счет плугина - спасибо за поправку. просто я счел, что раз для AVR и ARM генерируются практически одинаковые makefile (отличия только в опциях компилятора и собственно, самих запускаемых экзешниках), я подумал, что их формирует что-то другое, общее для С/С++ вообще - а это вроде бы CDT... исходники-то не зависят от платформы - их надо просто компилировать независимо от тулчейна, а эти самые опции в соответствии с галочками добавляет сам рассматриваемый плугин...

однако, позволю себе напомнить, что эта ветка обсуждения касается именно Eclipse и его плугинов, а вовсе не makefile.

и проблема существует, иначе как объяснить это http://sourceforge.net/projects/gnuarmecli...0/topic/2943416 или это http://embdev.net/topic/129910#2141252 ???

галочки ставлю не я один, это же очевидно: плугин написан не по моему заказу sm.gif
Ingener001
Привет всем!
Начинаю осваивать Eclipse и GCC. Много инфы нашёл в сети и на этом форуме, но предстоит найти ещё больше...

Использую Eclipse, Yagarto, Segger GDB server, J-Link, всё свежее, недавно установленное.

Пока изучаю готовые проекты из сети.

Вопрос следующий:
при отладке проекта через GBD на плате, в среде всё идёт ожидаемо, т.е. я могу запустить программу, остановить, делать шаги по коду, смотрю содержимое регистров и т.д. Но на железе, при этом, нет никакой реакции, светодиоды не моргают и т.п. При этом, если закрыть GDB сервер, и после перезагрузки\выключении питания, плата начинает моргать всем что запрограммировано. Код в контроллере тот же, что был загружен при отладке.

Так происходит не со всеми проектами. К примеру: Официальное FreeRTOS демо ARM7_LPC2368_Eclipse работает и отлаживается без вопросов. Нажимаю Старт, светодиоды моргают, браузером смотрю статус. С другой стороны, официальный демо-проект Segger LPC2378_GDB (копируется при установке драйверов), ведёт себя как описано выше.
Настройки Debug в Eclipse при этом одинаковые.

Что може влиять на это?
SergeyDDD
Цитата(Ingener001 @ May 4 2011, 10:32) *
смотрю содержимое регистров


У меня такой же софтовый набор и я тоже новичок в Eclipse+Yagarto+Segger GDB server+J-Link
У меня к Вам вопрос.
Где и как Вы смотрите содержимое регистров?
Почему то местные гуру игнорируют мой вопрос sad.gif
Пока я нащупал два варианта, но они очень неудобны
1. В окне "Expressions" вбиваю адрес регистра в виде *((unsigned int *) (адрес регистра)))
2. В Memory Monitor вбиваю адрес регистра
Хотелось бы в отладчике указывать имена регистров, а не их адреса.
Как делаете Вы?

А по поводу отладки...
У меня на SAM7S256 таких проблем не было.
Может в GDB скрипе скрыта проблема.
На сколько я понимаю перед отладкой, J-Link по скрипту выполняет аппаратную конфигурацию.
Видимо эти аппаратные настройки и создают Ваши проблемы.
Естественно когда процессор работает самостоятельно, этого не происходит
DmitryM
Цитата(SergeyDDD @ May 6 2011, 13:10) *
У меня такой же софтовый набор и я тоже новичок в Eclipse+Yagarto+Segger GDB server+J-Link
У меня к Вам вопрос.
Где и как Вы смотрите содержимое регистров?
Почему то местные гуру игнорируют мой вопрос sad.gif
Пока я нащупал два варианта, но они очень неудобны
1. В окне "Expressions" вбиваю адрес регистра в виде *((unsigned int *) (адрес регистра)))
2. В Memory Monitor вбиваю адрес регистра
Хотелось бы в отладчике указывать имена регистров, а не их адреса.
Как делаете Вы?

Используете GDB (DSF) Hardware Debugging? или стандартный? У меня при использовании первого есть вкладка Register, в ней и смотрю.
SergeyDDD
Цитата(DmitryM @ May 7 2011, 11:09) *
Используете GDB (DSF) Hardware Debugging? или стандартный? У меня при использовании первого есть вкладка Register, в ней и смотрю.


Zylin Embedded debug
Почему GDB (DSF) Hardware Debugging? Чем он хорош?

На сколько я разобрался, на вкладке Registers можно увидеть только регистры самого процессора R1-R12, CPSR и т.д.
Меня интересуют периферийные регистры, которые отображены в память.
DmitryM
Цитата(SergeyDDD @ May 7 2011, 16:20) *
Zylin Embedded debug
Почему GDB (DSF) Hardware Debugging? Чем он хорош?

На сколько я разобрался, на вкладке Registers можно увидеть только регистры самого процессора R1-R12, CPSR и т.д.
Меня интересуют периферийные регистры, которые отображены в память.

У меня Eclipse Helios SR1, Zylin не устанавливал. периферийные регистры смотрю через переменную-структуру. Да, во вкладке регистры отображаются имеено регистры процессора, а не периферии. Откуда эклипсу то знать про периферийные регистры?
SergeyDDD
Цитата(DmitryM @ May 9 2011, 09:38) *
У меня Eclipse Helios SR1, Zylin не устанавливал. периферийные регистры смотрю через переменную-структуру. Да, во вкладке регистры отображаются имеено регистры процессора, а не периферии. Откуда эклипсу то знать про периферийные регистры?

Я согласен, эклипс не может знать.

Какой вид должна иметь переменная либо переменная структура, что бы ее можно было увидеть в вкладке "Expressions"

Допустим я регистры определяю как: #define REG_NAME (*((volatile unsigned int *) (0x...)))
При аппаратной отладке в "Debug" в окошке "Expressions" ввожу REG_NAME.
Вместо содержимого регистра вижу - <error(s)_during_the_evaluation>
Тем не менее если в окне "Debug" вбить *((volatile unsigned int *) (0x...)), тогда содержимое отображается верно.
Но отлаживаться по адресам регистров, а не по их именах неудобно.

В заголовочниках Atmel-я регистры описаны в структурах.
Что бы посмотреть их содержимое, необходимо создавать указатели на структуры только ради того, что бы посмотреть регистр при отладке.
Честно говоря это не удобно, так как при при необходимости посмотреть другую группу регистров надо прерывать отладку для того что бы создавать новую переменную указатель на новую структуру с описанием новых регистров.
Ingener001
to SergeyDDD: я имел в виду окно Registers, там действительно только CPU. Попробуйте создать указатель на интересующий вас регистр. Сам не пробовал, но думаю получится. Если получится, можно будет описать структурный тип с периферией и создать указатель с этим типом. Благо регистры периферии все рядом по типам. Вроде как в IAR'е что то подобное сделано...

Проблема, кот. я описал выше однотипна при любом плагине отладчика. ХЕЛП!
SergeyDDD
Цитата(Ingener001 @ May 10 2011, 09:37) *
to SergeyDDD: я имел в виду окно Registers, там действительно только CPU. Попробуйте создать указатель на интересующий вас регистр. Сам не пробовал, но думаю получится. Если получится, можно будет описать структурный тип с периферией и создать указатель с этим типом. Благо регистры периферии все рядом по типам. Вроде как в IAR'е что то подобное сделано...

Проблема, кот. я описал выше однотипна при любом плагине отладчика. ХЕЛП!


С указателями все понятно.
Но не хочется их создавать только ради отладки.
Ситуацию я описал выше.
Неужели все пользуются указателями и это единственный способ?
Ребята!!! Просвятите кто как отлаживает периферию...

А по поводу Вашей проблемы...
Вы скрипты дебаггера посмотрите.
Может они портят все настройки периферии контроллера при отладке.
В этом случае не в плагине дело.
ARV
по-моему ваша проблема в том, что в вашем случае REG_NAME - это макрос препроцессора, т.е. он не существует среди той отладочной информации, с которой способен работать отладчик. если вы определите переменные-указатели с соответствующими именами, тогда вы сможете смотерть их содержимое по символьным именами, а не адресам
SergeyDDD
Цитата(ARV @ May 10 2011, 11:45) *
по-моему ваша проблема в том, что в вашем случае REG_NAME - это макрос препроцессора, т.е. он не существует среди той отладочной информации, с которой способен работать отладчик. если вы определите переменные-указатели с соответствующими именами, тогда вы сможете смотерть их содержимое по символьным именами, а не адресам


Догадывался об этом...
Неужели выходит что альтернативы указателям нет?

Решение в виде плагина для эклипса сюда так и просится.
ARV
большинство здешних завсегдатаев резко отрицательно настроены против специальных плагинов sm.gif
а просится тут отдельный модуль с описанием всех [нужных] регистров, который просто надо будет присоединить к проекту на время отладки...
SergeyDDD
Цитата(ARV @ May 10 2011, 12:37) *
большинство здешних завсегдатаев резко отрицательно настроены против специальных плагинов sm.gif
а просится тут отдельный модуль с описанием всех [нужных] регистров, который просто надо будет присоединить к проекту на время отладки...


Ну видимо это единственный простой вариант...
Спасибо за ответ
Сергей Борщ
QUOTE (SergeyDDD @ May 10 2011, 12:08) *
Неужели выходит что альтернативы указателям нет?
Есть на уровне идеи. Описать в программе как extern структуры, соответствующие периферии, а адреса им назначить в скрипте или командной строке линкера. Попробуйте, отпишитесь. Я не вижу, почему не должно работать. Примерно такое:
CODE
ioAT91SAM7S64.h:
.....

extern AT91S_PIO PIOA;


LDFLAGS += -DPIOA=0xFFFFF400

SergeyDDD
Цитата(Сергей Борщ @ May 10 2011, 13:49) *
Есть на уровне идеи. Описать в программе как extern структуры, соответствующие периферии, а адреса им назначить в скрипте или командной строке линкера. Попробуйте, отпишитесь. Я не вижу, почему не должно работать.


Не стреляет...
И в заголовнике написал "extern AT91S_PIO PIOA;"
В командной строке "LDFLAGS += -DPIOA=0xFFFFF400" выдает ошибку (Yagarto).
Поэтому попробовал два варианта:
1. "LDFLAGS += -defsym PIOA=0xFFFFF400"
2. В скрипте линкера я указал следующее "PIOA = 0xFFFFF400;"

Ни первый ни второй вариант не работают.
При отладке в закладке "Expressions" символ DPIOA имеет значение "0"
Или я может где то ошибся?
Petka
Цитата(SergeyDDD @ May 10 2011, 17:40) *
Не стреляет...

ИМХО тогда надо в скрипте линкера прописать эти адреса. Тогда гарантированно будет работать.
Ingener001
Цитата(SergeyDDD @ May 10 2011, 12:42) *
Вы скрипты дебаггера посмотрите.
Может они портят все настройки периферии контроллера при отладке.
В этом случае не в плагине дело.


В том то и дело, что скрипт один и тот же в разных проектах, и в нём нет инициализации регистров кроме маппинга...
SergeyDDD
Цитата(Petka @ May 10 2011, 17:02) *
ИМХО тогда надо в скрипте линкера прописать эти адреса. Тогда гарантированно будет работать.


в скрипте я указывал адрес: "PIOA = 0xFFFFF400;"
для символа в исходниках: "extern AT91S_PIO PIOA"

или это делается по другому?
примерчик можете накидать?
Сергей Борщ
QUOTE (SergeyDDD @ May 10 2011, 16:40) *
В командной строке "LDFLAGS += -DPIOA=0xFFFFF400" выдает ошибку (Yagarto).
Да, тут я ошибся. Имел ввиду LDFLAGS+= -Wl,--defsym,PIOA=0xFFFFF400
Проверить прямо сейчас не могу.

SergeyDDD
Цитата(Сергей Борщ @ May 10 2011, 20:28) *
Да, тут я ошибся. Имел ввиду LDFLAGS+= -Wl,--defsym,PIOA=0xFFFFF400
Проверить прямо сейчас не могу.


-Wl - это что за опция?
На ней выдается ошибка...

Ребята!!!
У кого получилось - дайте знать...
Сергей Борщ
QUOTE (SergeyDDD @ May 11 2011, 08:33) *
-Wl - это что за опция?
Это указание gcc передать следующую за ней опцию линкеру.
QUOTE (SergeyDDD @ May 11 2011, 08:33) *
На ней выдается ошибка...
"ВСЕ НЕ РАБОТАЕТ!" lol.gif Вы бы хоть текст ошибки приводили. Не все тут в состоянии угадать его телепатически. Если ошибка типа "неизвестная опция" - значит у вас в makefile линкер ld вызывается явно, а не посредством драйвера gcc.
QUOTE (SergeyDDD @ May 11 2011, 08:33) *
У кого получилось - дайте знать...
Будет время - попробую. Сейчас, увы, куча работы. Пробуйте самостоятельно. Уж описание опции -Wl можно было нагуглить.
SergeyDDD
Цитата(Сергей Борщ @ May 11 2011, 10:31) *
Это указание gcc передать следующую за ней опцию линкеру.
Если ошибка типа "неизвестная опция" - значит у вас в makefile линкер ld вызывается явно, а не посредством драйвера gcc
Уж описание опции -Wl можно было нагуглить.

Спасибо понял.
Я действительно в make прописал линковку через ld и соответственно опцию -Wl искал в документации по линкеру LD.

Описание символа следующее:
extern AT91S_PIO PIOA;

Командная строка ликера выглядит так:
arm-none-eabi-ld -Map Output.map -TOutput_RAM.ld -defsym PIOA=0xFFFFF400 -o Output.out Startup.o AppMain.o

Тем не менее символ PIOA при отладке имеет нулевое значение.
Petka
Цитата(SergeyDDD @ May 10 2011, 18:47) *
или это делается по другому?
примерчик можете накидать?

Да, по другому:
в скрипте линкера (тот файл, что вы указываете в опциях линкера после ключа "-T") добавляете секцию:
Код
/* Memory Definitions */                                                                        
MEMORY                                                                                          
{                                                                                              
  FLASH  (rx) : ORIGIN = 0x00000000, LENGTH = 0x00080000                                        
  RAM    (rw) : ORIGIN = 0x40000000, LENGTH = 0x00010000                                        
  USBRAM (rw) : ORIGIN = 0x7FD00000, LENGTH = 0x00004000                                        
  ETHRAM (rw) : ORIGIN = 0x7FE00000, LENGTH = 0x00004000                                        
  RTCRAM (rw) : ORIGIN = 0xE0084000, LENGTH = 0x00000800                                        
  /* Добавим ниже область памяти с периферией. В моём случае в качестве периферии будет контроллер VIC */
  VIC    (rw) : ORIGIN = 0xFFFFF000, LENGTH = 0x00000FFF                                        

}

....
....
....

/* Section Definitions */                                                                      
                                                                                                
SECTIONS                                                                                        
{                                                                                              
  /* В описании секций добавим секцию где будут размещаться регистры периферии VIC */
  vic (NOLOAD):                                                                                
  {                                                                                            
    *(vic)                                                                                      
  } > VIC                                                                                      
  /* Указываем что секция размещается в области памяти, принадлежащей VIC */

....
....
....


Далее в коде программы описывем регистры:

Код
....
#include <stdint.h>
....
/* Описываем регистры, и указываем что они размещены в секции "vic" */
volatile uint32_t __attribute__((section("vic"))) REG_VICIRQStatus;                            
volatile uint32_t __attribute__((section("vic"))) REG_VICFIQStatus;                            
volatile uint32_t __attribute__((section("vic"))) REG_VICRawIntr;                              
volatile uint32_t __attribute__((section("vic"))) REG_VICIntSelect;                            
volatile uint32_t __attribute__((section("vic"))) REG_VICIntEnable;                            
volatile uint32_t __attribute__((section("vic"))) REG_VICIntEnClr;                              
volatile uint32_t __attribute__((section("vic"))) REG_VICSoftInt;                              
volatile uint32_t __attribute__((section("vic"))) REG_VICSoftIntClr;                            
volatile uint32_t __attribute__((section("vic"))) REG_VICProtection;                            
volatile uint32_t __attribute__((section("vic"))) REG_VICSWPrioMask;                            
...


Пересобираем программу и наслаждаемся отладкой периферии =)
Проверил код и отладку. Работает.
SergeyDDD
2Petka

Вот спасибо!!!!!
Буду пробовать
klen
Цитата(Petka @ May 12 2011, 11:04) *
.....
volatile uint32_t __attribute__((section("vic"))) REG_VICSWPrioMask;
...
Пересобираем программу и наслаждаемся отладкой периферии =)
Проверил код и отладку. Работает.


так так так...... этож я могу туда и структуры и битовые поля засунуть! и тогда отладчик будет парсить и значение битов! поробую прокрутить фарш через мясорубку.... отпишусь
идея новая но косяков пока не вижу...
Petka
Цитата(klen @ May 16 2011, 10:27) *
так так так...... этож я могу туда и структуры и битовые поля засунуть! и тогда отладчик будет парсить и значение битов! поробую прокрутить фарш через мясорубку.... отпишусь
идея новая но косяков пока не вижу...

Обязательно отпишитесь о результатах.
klen
Цитата(Petka @ May 16 2011, 12:28) *
Обязательно отпишитесь о результатах.


получилось но криво. в линкер ничего пихать не надо.
я залез в объявление структуры DAC_TypeDef (stm32f10x.h)

если компилировать с помощью c++ то проблен нет вообще

заменяем объявление поля структуры на (пример для регистра СR ЦАПа)
Код
typedef struct
{
  __IO uint32_t CR;
  __IO uint32_t SWTRIGR;
  __IO uint32_t DHR12R1;
  .....
} DAC_TypeDef;

на
Код
typedef struct
{
    union CR {
      __IO uint32_t val;
        struct
                  {
                    uint32_t EN1 : 1;
                    uint32_t BOFF1 : 1;
                    uint32_t TEN1 : 1;
                    uint32_t TSEL1 : 3;
                    uint32_t WAWE1 : 2;
                    uint32_t MAMP1 : 4;
                    uint32_t DMAEN1 : 1;
                    uint32_t Reserve1 : 3;

                    uint32_t EN2 : 1;
                    uint32_t BOFF2 : 1;
                    uint32_t TEN2 : 1;
                    uint32_t TSEL2 : 3;
                    uint32_t WAWE2 : 2;
                    uint32_t MAMP2 : 4;
                    uint32_t DMAEN2 : 1;
                    uint32_t Reserve2 : 3;
                  } CR_BITS;
                CR& operator= (const uint32_t src) { val = src; return *this; }
        };
  __IO uint32_t SWTRIGR;
  __IO uint32_t DHR12R1;
  .....
} DAC_TypeDef;


итогом становится то что двойное слово теперь интерпретируется как битовое поле объедененное с этим словом. отладчик бодро отрисовывает содержание полей.
в этом способе есть ложка дегтя - посколькоу __IO uint32_t CR превратился в enum {...} то в коде использующем DAC_TypeDef операция DAC->CR=XXX будет неактуальна, потому что нельзя присвоить целого типа в объект объединения типа, поэтому приходится перегрузит операцию присваивания с помощью CR& operator= (const uint32_t src). Это сразуже ствит крест на возможности скомпилировать с помощю компилятора С.

теперь вариант с компиллером С. в принципе можно объявить структуру анонимной без перегрузки присваивания но уже с полем __IO uint32_t CR :
Код
typedef struct
{
        union {
      __IO uint32_t CR;
        struct
                  {
                    uint32_t EN1 : 1;
                    uint32_t BOFF1 : 1;
                    uint32_t TEN1 : 1;
                    uint32_t TSEL1 : 3;
                    uint32_t WAWE1 : 2;
                    uint32_t MAMP1 : 4;
                    uint32_t DMAEN1 : 1;
                    uint32_t Reserve1 : 3;

                    uint32_t EN2 : 1;
                    uint32_t BOFF2 : 1;
                    uint32_t TEN2 : 1;
                    uint32_t TSEL2 : 3;
                    uint32_t WAWE2 : 2;
                    uint32_t MAMP2 : 4;
                    uint32_t DMAEN2 : 1;
                    uint32_t Reserve2 : 3;
                  } CR_BITS;
        };
  __IO uint32_t SWTRIGR;
  __IO uint32_t DHR12R1;
  .....
} DAC_TypeDef;


в этом случае DAC->CR=XXX проходит естественно на ура но..... отладчик теперь не знает имени объединения , потому что его нет - оно анонимное. приплыли.

если на то что нада периписать все обращения вызовы DAC->CR=XXX на DAC->CR.val = XXX закрыть глаза ( например библиотечные где уже с этим регистром чтото делается ) то проблем вообще нет - в данном случае называем объединение конкретным именем CR и все работает.
разумется в скрипт линкера ничего сувать не требуется, он вообще тут непричем, адрес региста из дефайна берется а не из адреса секции.

никакх
ARV
подскажите, как работать с репозиторием Google Code?
я сделал следующее:
1. создал проект на code.google.com
2. скачал и установил Subclipse плагин к Eclipse
теперь пробую сделать для своего проекта Team - Share Project: в появляющемся оконце ввожу то, что написано в закладке Source в интерфейсе code.google.com (это примерно такое: https://my-project.googlecode.com/svn/trunk/ my_project --username my_name@my_post.com) - получаю в итоге ошибку "Затребованное имя допустимо и оно найдено в базе данных, но для имени отсутствуют связанные с ним даные"... что это значит? когда и где вводится пароль на запись в репозиторий? как вообще правильно подключаться к SVN-репозиторию?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.