http://sourceforge.net/projects/gnuarmeclipse/
Формирователь мейкфайлов путём расставления галочек в формах для пяти разных популярных тулчейнов.

Добрый день. Подскажите, пожалуйста, как привязать к Eclipse компилятор для mips(kgp или gcc). Какие параметры и где в настройках эклипса указать?

Я указываю имя компилятора в Project->Propertities->C/C++ build->Discovery Options. Все остальные настройки делаю в makefile. Проект создаю как C/C++ project, Makefile project, other toolchain. Путь к папке bin компилятора должен быть прописан в path, чтобы не указывать абсолютные пути и переносить проект между компьютерами.

Спасибо, за быстрый ответ!
Сергей, если Вы пишите под mips процессоры, не могли бы Вы посоветовать компилятор, и какие именно параметры указываете в makefile. И еще, makefile пишите самостоятельно, или его в какой-то степени Eclipse может сгенерировать?

Нет, я использую ARM7, AVR, MSP430. makefile самописные. Всякие генераторы с галочками не признаю.

Ребята!
Возник у меня один вопрос, который на форуме задается не первый раз, но на него почему то никто не дает ответ.

Как в Eclipse во время отладки в удобной форме видеть содержимое периферийных регистров?

Регистры определены в заголовочнике как: #define REG_NAME (*((volatile unsigned int *) (0x...)))

При аппаратной отладке (J-Link+GDB+Zylin) в "Debug" в окошке "Expressions" ввожу REG_NAME.
Вместо содержимого регистра вижу - <error(s)_during_the_evaluation>

Тем не менее если вместо REG_NAME вбить *((volatile unsigned int *) (0x...)), тогда содержимое отображается верно.

Отлаживать по адресам регистров, а не по их именах мягко говоря неудобно.
Хотелось бы узнать о Вашей практике.
Возможно я что то не так делаю.

В заголовочниках Atmel-я регистры описаны в структурах. И что бы посмотреть их содержимое, необходимо создавать указатели на структуры. Но делать это только ради того что бы посмотреть регистр при отладке как то глупо.
Хотя пока так и делаю + Memory Monitor

Да и еще...
Так и напрашивается некий плагин, в который при настройке проекта вбивается список адресов регистров, их имен и их побитовое описание.
А при отладке, он очень информативно и удобно отображает содержимое регистров, битовых флагов, буферов и т.д...

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

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


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

Даже не стал дочитывать до конца всю Вашу мистику, ибо не пользуюсь плагинами-формирователями.
Разобравшись в линкерном скрипте и makefile необходимость во всём остальном отпала сама собой.
Но поскольку многие пользователи не дают себе труд разобраться в самих основах, то мистика, подобная Вашей, появляется здесь неизбежно и с пугающей регулярностью. И у каждого пользователя своя мистика, поэтому поиск не помогает.

а отладку при помощи gdb вы тоже ведете путем ввода вручную команд в консоли? основное достоинство всех этих плагинов в том, что они держат "под рукой" набор наиболее "ходовых" параметров GCC, избавляя тем самым от мук поиска по документации... вот и все. хочется легкой жизни

Отладку при помощи gdb успешно делаю, безо всякой консоли, хотя никаких плагинов у меня нет.
Чтение документации мучительным не считаю.
Попытайтесь увидеть разницу: у меня плагинов (визардов) нет и у меня всё получается, Ваше стремление к лёгкой жизни ведёт лишь к вопросам здесь.
Ну ладно, получите Вы здесь по данному конкретному случаю исчерпывающий ответ. Это поможет понять Вам глубинную суть происходящих процессов при компиляции\сборке? Это избавит Вас от схожих проблем? Думаю врядли. А вот единожды во всём разобравшись у Вас будут совсем другие ощущения и полная независимость от кого бы то ни было, написавшего (возможно глюкавый) плагин.
Всё вышенаписанное составляет моё личное мнение.

пока что я вижу очень подозрительное поведение make, заключающееся в том, что не проверяется "свежесть" файлов, подлежащих компиляции. по-моему, make должна сравнивать дату исходника и дату объектника, и если они не совпадают, перекомпилировать исходник. разве нет? я же вижу, что проверяется только main.c, причем при его обновлении перекомпилируется весь проект, а не только обновленные файлы, что тоже как-то странно. если в makefile эта ситуация лечится какими-то скриптовыми возможностями - подскажите, какими, ибо по GNU-make я скачал талмуд, чтение которого отнимет у меня месяц, т.к. искать я буду неизвестно что...
другие глубинные процессы вряд ли могут меня заинтересовать на данном этапе.

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



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

Если интересно, то вот он.
 makefile.txt ( 6.92 килобайт ) Кол-во скачиваний: 220

И еще. Как я понял, должны создаваться файлы зависимостей, например main.o.d. Вот на основе их он принимает решение перекомпилировать или нет. И это должно указываться в маке файле.

это не помогает...

как раз интересует сгенерированный плагином makefile. точнее, причины такого поведения и методы борьбы (рукописание файлов оставляю на самый последний крайний случай)

и как это должно указываться?

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

А у вас файлы такие как main.o.d появляются?

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