это с точки зрения компилятора кроме makefile нет ничего. но в этой теме обсуждают Eclipse и иже с ним. насколько я смог понять, упомянутые ранее сложные makefile генерирует плугин CDT - поправьте, если я не прав. так вот, в моем случае почему-то этот плугин не добавляет в makefile сорцы на ассемблере.я, конечно, понимаю, что совет "пиши makefile ручками" снимает все проблемы, но тогда надо продолжить "редактируй файлы в блокноте" - почему нет? если я не умею пользоваться Eclipse - подскажите, чего я еще не знаю про него. Если проблема в самом Eclipse - то это другой вопрос, и надо его решать. как раз благодаря тому, что от проблемы все бегут в ручную правку makefile плагин может не развиваться многие годы...


к сожалению, только дома я могу проверять свои догадки и пытаться найти решение... поэтому пока что жду советов и т.п.

Поправляем. Не прав. Это делает
И вы это интуитивно вроде бы понимаете, ибо Но поскольку вы, похоже, единственный, кто расставляет галочки - то увы, придется разбираться самостоятельно.

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

И обратите внимание - в мире GCC принято, что .S и .s - разные файлы. Первый gcc сначала обрабатывает сишным препроцессором и лишь потом передает ассемблеру as, а второй - сразу передает в as.

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

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

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

галочки ставлю не я один, это же очевидно: плугин написан не по моему заказу

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

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

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

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

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

Что може влиять на это?

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

А по поводу отладки...
У меня на SAM7S256 таких проблем не было.
Может в GDB скрипе скрыта проблема.
На сколько я понимаю перед отладкой, J-Link по скрипту выполняет аппаратную конфигурацию.
Видимо эти аппаратные настройки и создают Ваши проблемы.
Естественно когда процессор работает самостоятельно, этого не происходит

Используете GDB (DSF) Hardware Debugging? или стандартный? У меня при использовании первого есть вкладка Register, в ней и смотрю.

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

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

У меня 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-я регистры описаны в структурах.
Что бы посмотреть их содержимое, необходимо создавать указатели на структуры только ради того, что бы посмотреть регистр при отладке.
Честно говоря это не удобно, так как при при необходимости посмотреть другую группу регистров надо прерывать отладку для того что бы создавать новую переменную указатель на новую структуру с описанием новых регистров.

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

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

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

А по поводу Вашей проблемы...
Вы скрипты дебаггера посмотрите.
Может они портят все настройки периферии контроллера при отладке.
В этом случае не в плагине дело.

по-моему ваша проблема в том, что в вашем случае REG_NAME - это макрос препроцессора, т.е. он не существует среди той отладочной информации, с которой способен работать отладчик. если вы определите переменные-указатели с соответствующими именами, тогда вы сможете смотерть их содержимое по символьным именами, а не адресам

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

Решение в виде плагина для эклипса сюда так и просится.

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

Ну видимо это единственный простой вариант...
Спасибо за ответ