[Canis Dirus 0]

Компилер ставил apt-get install g++-4.4-arm-linux-gnueabi

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

[NaughtyFreak 0]

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

поставил, тольку 0.

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

 

[_Pasha 0]

поставил, тольку 0.

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

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

echo $PATH  если нужно посмотреть что же там прописано
export PATH=$PATH:путь-к-компилятору если добавить путь, к-рый почеу-то не прописан

[mdmitry 0]

Прочитав это, попытался сделать для 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:

#discovery target for Eclipse parser
.PHONY: discovery
discovery:
    @echo > dummyspec.c
    $(CC) $(INCS) $(CFLAGS) -E -P -v -dD dummyspec.c
    $(RM) dummyspec.*

# dependencies
ifeq (,$(findstring build,$(MAKECMDGOALS)))
ifeq (,$(findstring clean,$(MAKECMDGOALS)))
  ifeq (,$(findstring dirs,$(MAKECMDGOALS)))
   ifeq (,$(findstring discovery,$(MAKECMDGOALS)))
  -include $(wildcard $(OBJDIR)/*.d) 
   endif
  endif
endif
endif

 

Не заработало!

Выяснил, что не распознаются относительные пути из $(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).

[btolfa 0]

Прочитав это, попытался сделать для Eclipse Juno SR1 по аналогии с этим сообщением Сергея Борща.

Отличия: попытался сделать как рекомендуют разработчики, т.е. без "Discovery Options".

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

#discovery target for Eclipse parser
discovery:
    $(CC) $(INCS) $(CFLAGS) -E -P -v -dD '$(specs_file)'

А поле "Command to get compiler specs" заполнить make specs_file=${INPUTS} discovery.

По поводу относительных путей вижу только следующую возможность - добавить

ROOT = $(shell pwd)

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

INCS += -I$(ROOT)/src

[mdmitry 0]

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

#discovery target for Eclipse parser
discovery:
    $(CC) $(INCS) $(CFLAGS) -E -P -v -dD '$(specs_file)'

А поле "Command to get compiler specs" заполнить make specs_file=${INPUTS} discovery.

По поводу относительных путей вижу только следующую возможность - добавить

ROOT = $(shell pwd)

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

INCS += -I$(ROOT)/src

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

[btolfa 0]

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

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

 

[Сергей Борщ 123]

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

в эклипсе в настройке debug configuration есть возможность выбрать GDB(DSF) Hardware debug launcher и Standart GDB Hardware debug launcher. Какой предпочтительнее? DSF, похоже, не реагирует на настройку формата отображения регистров - каждый раз приходится вручную переключать отбражение с десятичного вида на шестнадцатиричный. Для стандартного формат задается в Window->Preverences->C/C++/Debug. Для DSF есть что-то подобное?

Тут вторая

 

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

 

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

[swisst 0]

Доброго дня !

 

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

[zend 0]

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

 

По некоторым причинам пришлось слезть с Windows + CooCox на Linux + Eclipse + CDT + stlink(от texane)

И вот такая вот трабла... Всё билдится, компилится, в общем, работает ОК, но вот дебажить - через попу. Конкретно - не могу приостановить выполнение программы.

Если поставить брейкпоинт, на нём дебаггер останавливается нормально.

А вот если необходимо приостановить выполнение программы в том месте, в котором выполняется в данный момент - клацаю кнопку "Suspend" (как "пауза") - просто ничего не происходит :(

Пробовал юзать OpenOCD - так там вообще эта кнопка неактивна, но если законнектиться телнетом к OpenOCD и сказать halt - нормально приостанавливается. Уж не знаю, что и думать...

Изменено 5 сентября, 2013 пользователем Zend

[Сергей Борщ 123]

Пробовал юзать OpenOCD - так там вообще эта кнопка неактивна, но если законнектиться телнетом к OpenOCD и сказать halt - нормально приостанавливается. Уж не знаю, что и думать...

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

diff --git a/src/jtag/hla/hla_interface.c b/src/jtag/hla/hla_interface.c
index f8b5c61..5e958c3 100644
--- a/src/jtag/hla/hla_interface.c
+++ b/src/jtag/hla/hla_interface.c
@@ -137,7 +137,11 @@ int hl_interface_init_reset(void)
        jtag_add_reset(0, 1);
        hl_if.layout->api->assert_srst(hl_if.fd, 0);
    }
-
+    else
+    {
+        jtag_add_reset(0, 0);
+        hl_if.layout->api->assert_srst(hl_if.fd, 1);
+    }
    return ERROR_OK;
}

diff --git a/src/target/hla_target.c b/src/target/hla_target.c
index 5d31c7a..ececcdf 100644
--- a/src/target/hla_target.c
+++ b/src/target/hla_target.c
@@ -497,7 +497,9 @@ static int adapter_poll(struct target *target)

        LOG_DEBUG("halted: PC: 0x%08x", buf_get_u32(armv7m->arm.pc->value, 0, 32));
    }
-
+    else
+        target->state = state;
+    
    return ERROR_OK;
}

 

[Berkl 0]

 

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

 

Вопрос по С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. Не проще ли проект Эклипса создавать самим эклипсом, пользуясь соответствующим визардом?

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

 

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

 

Спасибо!!!!

[bureau 0]

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

Может где-то вручную в конф. файле можно поменять этот параметр?

 

UP

Windiws -> Prerefernce->C/C++ ->Build->Console

"Limit console output"

[сарматъ 0]

Поставил эклипсу 3.4.0 ganymede, комплект разработки C/C++. Инсталлировал плагин Zylin embedded cdt 4.5.1. В окне консоли gdb теперь можно вводить команды вручную.

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

 

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

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

ресет сбрасывает контроллер же? а хальт нет?

[Сергей Борщ 123]

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

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

 

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

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