Можно скачать LPCXpresso (тоже Eclipse и бесплатно). В нём есть поддержка lpc3250 - startup среда сгенерит, если самому не хочется писать.

Спасибо, попробую. Но как бы наоборот, хочется как раз научиться его писать с нуля, была не совсем понятна последовательность инициализации, с чего начать (хотя уже в nxp'шном CDL нашёл примеры).

Разве АРМ9 чем-то принципиально отличается от АРМ7. Тем более если компилятор GCC.
Можно всять startup.c от ARM7 и отредактировать его.


Там не на asm?

Насколько я помню в ARM9 в startup надо ещё кэши настроить/сбросить. А может и попутал чего =)

В CDL большинство того, что интересно, на asm, но это не принципиально, там всё понятно вроде бы, пока что
LPCXpresso попробовал, уже не столько ради стартап-файла, сколько посмотреть на неё в качестве полноценной среды разработки...Ни то, ни сё - ограничения бесплатной версии "ограничивают" %)

А что именно ограничивает?
Там вроде было не более 128кБ отладка - не так уж мало. И всё.

да, в бесплатной не более 128КБ, как раз это одно и останавливает, тут много математических вычислений, хоть и всё заоптимизировано, но кодовый сегмент от 220КБ, плюс ещё не выяснил можно ли туда jlink прикрутить...
А для sourcery codebench lite правда есть один нюанс, если я правильно понял, он не имеет библиотек, скомпилированных в -mfloat-abi=hard, в итоге для операций над плавающей точкой используется fpu, а для функций из math.h тащится в придачу софтовое fadd-fmul и т.д. как вариант свой "libm" собрать.

Подскажите а можно клипсу настроить так чтоб при отладке видеть регистры периферии, наподобие как в AVR Studio сделано или еще как. А то пока через состояние памяти смотрю.

Смотрите тут Просмотр периферии ARM в eclipse

Подскажите возможно ли подставить имя исполнямего файла в аргументы при вызове "external tools" ?
Поясню: используется openocd + jlink + gdb. Для прошивки (просто прошивки флеши без отладки) использую скрипт

Вот можно ли как-то добавить этот скрипт в External tools в Еклипсе и подставлять имя бинарника для прошивки в соответствие с конфигурацией?
Есть переменная BuildArtifactFileName но она недоступна в "External tools configuration"

Настраиваю так:Нажмите для просмотра прикрепленного файла

Без openocd, jlink.

Да, так самое простое. Но если используются разные конфигурации сборки (Debug, Release и др.) то бинарник записывается в папке с именем конфигурации + ещё я люблю добавлять имя конфигурации в начале имени файла чтобы сократить путаницу. Но как теперь извлечь имя бинарника в активной конфигурации и подставить в аргументы для external tools? Понимаю что слегка за уши притянуто и совсем не критично для жизни, но всё же

Можно создать ещё external tools-ы: Program Debug, Program Release с соотв. настройками путей.
Но нужно ли это?
Я думаю - нет.

Поскажите пожалуйста по настройке среды Eclipse.
Установлены CDT и ARM plugin, CodeSourcery и Yagarto.

В Tools Settings нет вкладки Link. Соответсвенно все не собирается.

Что только не делал.
И разные версии Eclipse брал и переустанавливал все и с настройками игрался.
Не выходит....

Так же пусто во вкладке Additional Tools.

Все это под Win7

Может кто знает волшебное слово.

Ниже Settings есть Tool Chain Editor. Там всё правильно установлено?

Там тоже перепробовал все что можно.
Самое интересное что Инструмент типа Link почему то не подсвечен его можно выбрать и добавить,
если внизу установить CheckBox
(извиняюсь сейчас нахоусь на работе и точно сказать не могу как он называется).
Но ничего не меняется.
Вообще где находятся сами настройки путей для текущего Tool Chain.
Другими словами как Эклипс узнает о подключенных инструментах.

Я так понимаю что эти инструменты (находятся) появляются при установеке ARM plugin.

Приветствую!

Установил у себя на Убунте кросскомпилятор gcc linaro-toolchain. В окружении всё прописал, на команду arm-fsl-linux-gnueabi-gcc -v в командной строке получаю адекватный ответ.
Но в Эклипсе, в списке доступных тулчайнов (Project->Properies->C/C++Build->Current toolchain)я не вижу ничего типа "ARM Cross gcc" .

Что я пропустил?

Заранее благодарен

Вероятно нужен еще и плагин, адаптированный к АРМ. Вот такой есть в Сети http://sourceforge.net/projects/gnuarmecli...ource=directory Но в списке совместимых кросскомпиляторов нет Linaro. Есть CodeSourcery G++ Lite, GNUARM, WinARM, Yagarto, devkitPro, Summon . Хотя может и для Линаро он сгодится?

Спасибо!

update. Спросил товарищей из Variscite, говорят пиши makefile сам, а в Эклипсе выбирай "Standard Make C Project" Я не настолько опытен да и 21 век уже....

IHMO, это разумный путь, тем более в 21 веке . Нет привязки к среде, высокая переносимость с платформы на платформу. Если не нравиться make, то используйте другую систему сборки (Scons, Cmake или что-то ещё).
Примеров makefile масса, хотя бы гляньте примеры от scmRTOS.

Ясно. Посмотрел в Сети, сколько людей столько и мнений. Вот здесь, после статьи в комментах сошлись поклонники make и Cmake http://habrahabr.ru/post/111691/ А вот тут автор статьи http://makesystem.net/?p=988 прям моими словами (точнее я его словами получается) заявил:


Но для меня (для Линаро) Эклипс плагина похоже не создали, так что без вариантов, надо make либо Cmake

Вопрос. Синтаксис содержимого makefile по сути является скриптовым языком. А он (синтаксис) отличается для разных компиляторов, кросскомпиляторов ?
Еще раз спасибо.

В makefile прописываются правила для достижения целей. make анализирует этот файл и запускает программы с указанными ключами. Программы указаны в makefile.
Если у компиляторов ключи запуска разные, то придется править под конкретный компилятор. Для разных версий gcc на одной платформе обычно этого не требуется.
make`ом собирают в том числе и документацию (doxygen, TeX) для получения pdf-файла. Язык makefile своеобразен и не всем нравиться. Альтернативы озвучены.
Система сборки не привязана к средствам сборки!

правильно ли я понял, что если используется свой makefile, то практически все настройки проекта доступные из Eclipse становятся для меня неактуальными, от него остается по сути только текстовый редактор? Так?

Да и запуск make для построения проекта.
Настройки отладчика задаются в Eclipse и вызов отладчика осуществляется из него (в большинстве случаев).

Приветствую,

Вопросик у меня. Вот тут http://www.voom.net/use-cmake-with-eclipse товарищ в статье пишет что Cmake 2.8 не работает с Эклипсом:



Это правда ? А что так ?

Добрый день!

проект компилируется в Эклипс + GSS но потом выдает:
c:/gcc/bin/../lib/gcc/arm-none-eabi/4.5.2/../../../../arm-none-eabi/bin/ld.exe:C:/Work/eclipse/stm32f103rbt6_eclipse_project/workspace/newtemplate\startup_src\stm32_flash.ld:79: syntax error

куда копать?

79 строка линкер-файла

Разобрался. Просто перед компиляцией поправил файл .ld но нажал кнопочку "Сохранить" и он мне все по старому шпарил.

А есть ли Rtos под эклипс? freeRtos можно запилить туда?

Мне кажется текстовуму редактору (Эклипсе) абсолютно все равно, исходники какой ОСРВ вы будете в нем править. Так же и ОСРВ будет работать независимо от того, в каком редакторе вы будуте править ее исходники.

Разница может быть при отладке

Прошу помочь советом. Установил Eclipse Kepler. По ссылке ( http://gnuarmeclipse.sourceforge.net/updates ) установил ARM Cross GCC.

После обновления в опциях создания проекта появились STM32F10X, что мне и нужно было.
Создал проект автоматически со всеми настройками.

1)При попытке сборки получил: cs-make ***[system/src/stm32f1-stdperiph/misc.o] error 1

2) постоянно вижу ошибку: Type 'uint8_t' could not be resolved
включение #include <stdint.h> результата не дало (

в чем может быть проблема?

Из моего скромного опыта. Сначала надо ставить GCC, потом клипсу, тогда она автоматом цепляет инклюды.

Всем привет. Только начал въезжать в связку Eclipse+GСC.
Установил:
-Eclipse IDE for C/C++ Developers Luna Release (4.4.0);
-Sourcery CodeBench Lite for ARM EABI;
-ARM plugin;

Создал проект на основе шаблона STM32F10X C/C++ Project, выбрав Toolchains Cross ARM GCC, в разделе Content указал Blinkly (создал проект с миганием светодиодом).
Скорректировал порт светодиода под STM32F1Discovery, компилирую.
Первая проблема - не понимает синтаксис make файла, по умолчанию make стоит от С++ builderа, правлю и указываю на cs-make.
Теперь компилит но на линкере останавливается с ошибкой

Ничего лучше не нашел как из настроек линкера убрать ключ --specs=nano.specs, стал компилироваться hex-файл. Заливаю его через STM32 ST-Link Utility - светодиод не мигает.
Смотрю, нет в проекте ассемблерного файла, нахожу его для своего контроллера и импортирую в проект, меняя букву расширения с .s на .S. Тоже компилируется, но, после загрузки программатором светодиод по прежнему не мигает.
Беру пример тут, ручками правлю порт светодиода, компилю, гружу в контроллер - мигает.
Это вкратце свои как я провел начало недели.
Ребята, подскажите, что делаю не так?

Может проект свой прикрепите, а то телепатия какая-то получается...

Выложить не проблема, смотреть там нет на что. Перефразирую вопрос по другому, если поставить компилятор и плагин, то нужно ли что-то дорабатывать ручками, что бы программа заработала в контроллере?
Пока ждал ответ запустил отладку, конечно как-то нестабильно работает, но удалось увидеть, что висит в HardFault_Handler(), до main не доходит.

Видимо, Sourcery CodeBench Lite этого не понимает. Советую gcc-arm-embedded, он - понимает.

Нужно включить в проект соответствующие контроллеру файлы:

• скрипт линкера (*.ld), чтобы линкер знал размеры памяти контроллера;
• стартап-файл (*.S), чтобы компилятор знал таблицу векторов прерываний данного контроллера;
• файл инициализации периферии (*.c) (файл с функцией SystemInit(), или что-то в этом роде.), чтобы правильно инициализировать периферию контроллера перед выполнением вашей программы по миганию светодиодом.

Судя по всему, вы выполнили только второй пункт.

АНТОХА верно про список все указал, а arm-none-eabi-gcc --spec понимает. Если плагин стоит, а вы писали что поставили, то достаточно создать проект, выбрать правильную платформу (Cortex-M3), пройтись по настройкам инклудов, линкера, дефайнов, проверить что все на месте, как указал АНТОХА. Для STM32 как раз надо в настройках задефайнить 100500 символов, указывающих какой именно чип используете, на какой частоте и т.д. Плагин сам подхватит нужный компилятор.

Спасибо за ответ, последняя версия плагина сама создает скрипт линкера, а вот про SystemInit() я совсем забыл. Помню, что для GCC он не нужен в main, он из стартап-файла вызывается, но его реализации у меня не было. Отпишусь о результатах.

Подскажите, за что это ключ отвечает?

Психанул и поставил gcc-arm-embedded, действительно ключ линкера --specs=nano.specs он принял. Еще нарыл, что стояла галка в опции линкера -nostartfiles, из-за этого программа не входила в main. Теперь, после запуска отладки вижу курсор на _start(), а не DefaultHandler(). Куда дальше шагает - не вижу, после step into курсор пропадает вообще. Светодиоды по прежнему не мигают. Пока пытаюсь добиться нормальной работы отладчика.

Добавлено:
Такое чувство, что не добавляет в итоговый код мой *.S файл, но компилит его. В момент старта отладки переходу в какой-то сишный файл, в котором определена _start(), а не в ассемблерный. Все ближе к тому, что бы сдаться.

Спокойствие, только спокойствие! ©
1. -nostartfiles - правильная птичка. У вас есть свой стартап-файл (который *.S), и вам не нужны другие, которые предлагаются по умолчанию.
2. SystemInit() вы нашли?
3. Почему вы не хотите взять тот проект, который замигал, и начать переделывать под себя его?
4. Ещё вариант, гарантированно рабочий - не полагаться на плагин, а использовать "makefile проект". Примеры таких проектов есть, например, в scmRTOS.

Извините, Антоха. Ламерский вопрос: Просмотрел примеры за Вашим авторством, никак не мог обнаружить где в состав проекта(примера) включаются исходные файлы scmRtos\Common\
Как то неявным образом через wildcard и указанием пути?

Да, именно так.
В makefile:
Сначала указываем директорию, где расположена ось:

Потом задаём список директорий с исходниками:

Потом во всех этих директориях ищем все файлы с расширениями *.c, *.cpp, *.S:

Теперь убираем пути и меняем расширение на *.o:

И, наконец, добавляем к именам файлов путь к директории obj (чтобы все объектные файы лежали там):

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

Отлично, подробно.

Благодарю Вас за ликбез, Антоха.

Немного разобрался, Эклипс упорно пихает сишные файлы стартапа, игнорируя мой файл ассемблерный файл, и как-то галочками отключить не удалось. Хотя мой стартам компилирует и передает линкеру. Попробую прикрутить к Эклипсу проект мигания светодиодом, там свой мэйкфайл, а не автоматически сгенерированный плагином.
Еще проблема с этим ST-Linkgdbserverом, через раз коннектиться сервер к чипу, и через раз стартует отладка, вижу только, что перешел на вектор сброса, дальше "Step into" и больше ответа от отладчика нет.

Neborak, АНТОХА дело советует - уходите от этих плагинов! Автосгенеренный мейкфайл совсем не юзер-френдли, поменять что-то - только через плагин. А если система слетела, исходники остались, плагин поставить не получается, а компилить надо?
1 раз сделать свой мейкфайл и использовать с небольшими изменениями для всех проектов!

Ув. АНТОХА. У меня к Вам еще вопрос: Ваши примеры для Cortex-M4 успешно собираются как с помощью arm-none-eabi, так и с помощью arm-kgp-eabi. Но при открытии main.cpp кто-то невидимый(парсер?)
делает массу подчеркиваний красным и оранжевым цветом. Не подскажете в чем причина, и как преодолеть? Windows 7 x64, Eclipse Kepler, опции проекта по умолчанию, т.е. Ваши.

Судя по всему, первопричина в том, что парсер считает "Unresolved inclusion" инклюды: #include "pin.h" #include <scmRTOS.h>. Но даже явное указание путей к ним, в свойствах проекта, не лечит проблему.
Хочется полного исцеления, а не маскирования снятием галок где нибудь в Code Analysis

Да, это собственный парсер эклипсы. Надо объяснить ему, где искать системные инклюды, и ваши личные определения из makefile.
У меня в закладках есть вот эта ссылка. Но это для прошлых версий эклипсы (у меня до сих пор Indigo, лень обновлять). Для кеплера, емнимс, способ изменился. Там немного дальше по теме коллеги выкладывали способ. Ага, вот он.

Кстати, у вас на картинке папки SamplesCommon и scmRTOS вроде пустые?

Пустые. Я как-то и не заметил их. Но почему они здесь? По факту они расположены на 2 уровня выше т.е. C:\Kepler\scmRtos\ а путь к проектам C:\Kepler\Workspace\2-Message\
Makefile практически Ваш. Поправил две строки с путями до SamplesCommon и scmRTOS - поднял на один уровень. Видимо где-то здесь косяк и есть.

-----------------------------------------------------------------------------
было:

# scmRTOS dir
SCMDIR = ../scmRTOS
# lib dir
COMMON = ../SamplesCommon
-----------------------------------------------------------------------------
стало:

# scmRTOS dir
SCMDIR = ../../scmRTOS
# lib dir
COMMON = ../../SamplesCommon
-----------------------------------------------------------------------------

А, тогда всё понятно. И makefile, и проект эклипсы рассчитаны на то, что папки SamplesCommon и scmRTOS расположены на одном уровне с папками проектов (1-EventFlag, 2-Message...). А у вас не так. Makefile вы поправили, а проект эклипсы - нет. Нажмите правой кнопкой на папку scmRTOS, выберите Properties. Там будет кнопка Edit, нажмите её и введите путь "../../scmRTOS". Так же поступите и с папкой SamplesCommon (../../SamplesCommon).
Тогда эклипса найдёт исходники оси и общие файлы.

Подскажите, кто в курсе - code sorcery lite сейчас можно стянуть без ide (только тулчейн) ?
И что сейчас можно пользовать в качестве альтернативы ?

Здесь

GNU Tools for ARM Embedded Processors