Ничего удивительного. Там же только сам бинарник g++. Ставьте gcc-arm-linux-gnueabi, он своими зависимости притащит минимальный необходимый набор (компилятор C и препроцессор).

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

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

Прочитав это, попытался сделать для Eclipse Juno SR1 по аналогии с этим сообщением Сергея Борща.
Отличия: попытался сделать как рекомендуют разработчики, т.е. без "Discovery Options".
В качестве тестового проекта были использованы примеры от ScmRtos для lpc17xx.
Действия:
1. Запуск eclipse, выбор места для workspace. File->New->Makefile Project with Existing Code.
2. Project->Properties.
3. C/C++ General->Preprocessor Include Paths, Mfcros etc.
4. Вкладка Providers. Выбрал все варианты (поставил галки).
Подробности настроек:
4.1. CDT User Settings Entries: выбрано только Enable language settings providers for this project. В группе Language Settings Provider Options ничего не выбрано.
4.2. CDT Managed Build Settings Entries [ Shared ]: выбрано только Enable language settings providers for this project. Группа Language Settings Provider Options недоступна.
4.3. CDT GCC Build Output Parser: выбрано Enable language settings providers for this project. В группе Language Settings Provider Options заполнено по умолчанию Compiler command pattern: (gcc)|([gc]\+\+)|(clang), радиокнопка в Container to keep discovered entries "File" и выбрано Use heuristics to resolve paths.
4.4. CDT GCC Builtin Compiler Settings: выбрано Enable language settings providers for this project. В группе Language Settings Provider Options обязательно выбрать Allocate console in the console View. Остальное не выбрано. Поле "Command to get compiler specs" заполнено так: make discovery
5. Apply, Ok.

У меня не получилось (наверно руки кривые) сделать по полной аналогии. Возникли проблемы с переменными окружения ($(specs_file)).
Сделал изменения в makefile:


Не заработало!
Выяснил, что не распознаются относительные пути из $(INCS). При этом все определения (в makefile) и пути компилятора добавляются в eclipse. Замена BASE = . на абсолютный путь к проекту и добавение переменной, определяющую абсолютные значения путей к SCMDIR и COMMON привели к положительному результату.
Запись путей была только с прямыми слэшами, как пути в linux (не родные для Win), иначе не собирался проект с помощью make из командной строки (WinXp).
Проверено на WinXp и linux (SLCE 5.2). Причем в linux путь к компилятору указывался в makefile (TOOL), так как в переменных окружения его не было.

Вопрос: как заставить парсер определить на основе относительного пути полный, считая текщим положение makefile? Наверное, что при использовании Scons можно использовать pwd и получить для цели discovery необходимые полные пути. Как это сделать для make пока не думал.

To ReAl:
Похоже, что в srec_cat версии 1.61 поменялись ключи и на строку из makefile было предупреждение (под linux).

Можно избавиться от временного внучную созданного dummyspec.c Для этого надо изменить правило для discovery следующим образом:

А поле "Command to get compiler specs" заполнить make specs_file=${INPUTS} discovery.
По поводу относительных путей вижу только следующую возможность - добавить

и указывать INCS пути относительно ROOT

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

Да проверил - Windows 7 x64, Eclipse Juno SR 2. Так же стоит gnuwin32. Видимо у вас не работает из-за отсутсвия pwd утилиты.

Несколько раз задавал где-то на форуме вопрос, но ни разу не получал ответа. Вот одна из попыток:

Тут вторая

Мало ли, вдруг кому-то тоже пригодится.

Обнаружил, что в последней эклипсе (Kepler) с CDT версии 8.2.0 после прекращения отладки с сипользованием Standart GDB HArdware Debugging Launcher невозможно удалить сессию в окне Debug. Попробовал еще раз DSF debug launcher и обнаружил, что из меню исчез выбор формата отображения регистров, переменных и т.д. Гугление показало, что они спрятали это меню в показанное на картинке место:

Доброго дня !

прикручиваю Keil С51 к Eclipse. Как избавится от ругни на обработчик прерывания static void ADC_Conv_Ready (void) interrupt 6{} ?

Уважаемые, помогите разобраться.

По некоторым причинам пришлось слезть с Windows + CooCox на Linux + Eclipse + CDT + stlink(от texane)
И вот такая вот трабла... Всё билдится, компилится, в общем, работает ОК, но вот дебажить - через попу. Конкретно - не могу приостановить выполнение программы.
Если поставить брейкпоинт, на нём дебаггер останавливается нормально.
А вот если необходимо приостановить выполнение программы в том месте, в котором выполняется в данный момент - клацаю кнопку "Suspend" (как "пауза") - просто ничего не происходит
Пробовал юзать OpenOCD - так там вообще эта кнопка неактивна, но если законнектиться телнетом к OpenOCD и сказать halt - нормально приостанавливается. Уж не знаю, что и думать...

Сообщение отредактировал Zend - Sep 5 2013, 08:23

В OpenOCD я наблюдал подобное поведение в случае, если в его скрипте нет команды "reset". Удалось это исправить в исходниках, но я не уверен, что починил правильно и в нужном месте. Не знаю, поможет ли это вам, но попробуйте пересобрать с вот этими исправлениями:

Товарищи, помогите разобраться плз.

Вопрос по СMake + Eclipse.
Я так понял, с приходом мудрости, и опыта большинство отказываются использовать CMake и прочие костыли, и начинают писать makefile ручками, но я из новичков.

Гляньте, прав я или нет, плз:
итак, при совместной работе Эклипса и cmake есть 3 пути:
1. Использовать генератор "Eclipse CDT4 - Unix Makefiles" . Тут получается два проекта. Первый - это мною написанный файл CMakeLists.txt, из которого CMake сгенерирует файлы проекта Эклипса. Полученные файлы импортируются во вновь созданный проект Эклипса. Если, например, добавился новый сишный исходник к моему проекту, то надо запускать всю описанную цепочку заново и пересоздавать проект в Эклипсе. Второй проект- это другой CMakeLists.txt, в нем я описываю как собрать мой проект, из него будет сгенерён makefile моего проекта.
2. Использовать обычный "Unix Makefiles" генератор которым будет создаан CMakeLists.txt для генерации makefile. При этом файлы проекта Эклипса создаются в самом Эклипсе.
3. Установить в Эклипс плагин CMakeBuilder. Это типа промежуточного звена между Эклипсом и всё тем же CMake. По сути это тот же путь что и второй, только CMakeLists.txt создается не в простом текстовом редакторе, а прямо в Эклипсе.

Мне кажется второй способ более предпочтителен. В первом случае, не понятно зачем генерить файлы проекта из рукописного CMakeLists.txt. Не проще ли проект Эклипса создавать самим эклипсом, пользуясь соответствующим визардом?
Третий способ ставит в зависимость от Эклипса. Мне на данном этапе наплевать стал я зависимым или нет, но потом я думаю, это может помешать мигрировать куда-нибудь. Любые узко специализированные примочки могут оказать медвежью услугу.

Есть ли принципиальные ошибки в выше изложенном ? Если нет, дальше спрашивать буду.

Спасибо!!!!

Пытаюсь увеличить буфер данных выводимых в консоль. Но даже сняв галку "Limit console output" (Windiws -> Prerefernce->Run/Debug->Console) ничего не изменяется...
Может где-то вручную в конф. файле можно поменять этот параметр?

UP
Windiws -> Prerefernce->C/C++ ->Build->Console
"Limit console output"

а какое заклинание создает окно консоли gdb?


эти исправления не помогают избавиться от телнета - как раз позавчера писал об этом, а что эти правки делают?
ресет сбрасывает контроллер же? а хальт нет?

Надо выбрать standard hardware GDB debugger launcher и в настройках появится галочка "verbose console mode".

Какой телнет? Зачем от него избавляться? Эти правки делают следующее: в hla_interface - если в скрипте не указано подключение линии сброса, то по документации предполагается, что ее нет. В коде это должно выглядеть как будто она в неактивном состоянии. В реальности же переменные остаются со значениями "не инициализаровано", OpenOCD считает, что reset не отпущен и не выполняет опрос состояния отлаживаемого процессора. Не вызывается функция poll() и он не может сообщить gdb что процессор работает. А когда дается команда halt - он без этого опроса не может узнать, что ядро остановилось и что об этом надо сообщить GDB. В hla_target при чтении состояния игнооиоуется переход ядра в любое состояние кроме HALT. Этот патч я вчера отослал и его в целом одобрили. Мне осталось разобраться, как теперь послать доработанный вариант.