stm32f4discovery+scmRTOS4, Вопрос чайника: можно ли запустить? Опции

[Legath]

Можно ли как то запустить версию порта от cortex-m3?

[AHTOXA]

Я бы не стал ставить утилиты пакета MSYS в несвойственное им место. Тулчейн может обновиться. Другие среды и тулчейны могут использовать эти утилиты в своих целях. Мало ли ещё какие причины могут быть?

Да, конечно лучше в отдельную папку. Просто я описывал как покороче.

Лучше проинсталлировать MSYS стандартным способом с сохранением пути к нему в переменной PATH.

Дело в том, что я не нашёл на сайте mingw нормального инсталлятора MSYS. Самый последний инсталлятор - msys-1.0.11, от 2008 года. Дальше просто куча частей, разложенная в кучу архивов. Я решил, что лучше взять компоненты поновее.

А вот путь к тулчейну я в переменной PATH не сохраняю, а указываю в Project->Properties->C/C++ Build->Environment в переменной PATH (у меня Eclipse Luna, но и в других аналогичных IDE есть похожее). Так удобнее и при экспериментах с разными тулчейнами и с переносимостью проекта лучше.

Считаю, что makefile должен работать самостоятельно, на завися от эклипсы. Поэтому все параметры сборки проекта - в нём. Это и для переносимости в том числе.
При экспериментах ничто не мешает мне задать в makefile путь к любому тулчейну, если занадобится. А дефолтные тулчейны - в PATH.

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

А чем это лучше, вот такого варианта:

Код

    TOOL    = arm-none-eabi-
    CC          = $(TOOL)gcc
    CXX         = $(TOOL)g++
    LD          = $(TOOL)g++

(при необходимости заменяем на:

Код

    TOOL    = /path/to/another/toolchain/arm-none-eabi-
    CC          = $(TOOL)gcc
...

)?

[IgorKossak]

Дело в том, что я не нашёл на сайте mingw нормального инсталлятора MSYS. Самый последний инсталлятор - msys-1.0.11, от 2008 года. Дальше просто куча частей, разложенная в кучу архивов. Я решил, что лучше взять компоненты поновее.

mingw-get-setup.exe Можно выбрать то, что нужно.

Считаю, что makefile должен работать самостоятельно, на завися от эклипсы. Поэтому все параметры сборки проекта - в нём. Это и для переносимости в том числе.
При экспериментах ничто не мешает мне задать в makefile путь к любому тулчейну, если занадобится. А дефолтные тулчейны - в PATH.

Это безусловно, если собирать из командной строки. Но если в проект входят ещё и настройки среды (файлы .project, .cproject, что в последнее время сполошь и рядом делается), что удобно для индексатора и discovering, то на мой взгляд лучше по-моему.
Кроме того, "дефолтные тулчейны - в PATH" могут подложить свинью, поскольку оттуда трудно отследить какие именно инструменты вызываются. Например, у меня установлены две версии тулчейна от GCC ARM Embedded и один от CodeSourcery. Чтобы переключиться с одного на другой в Вашем варианте надо поменять переменную PATH и перелогиниться в системе (у меня по крайней мере так). В то время как используя мой вариант, не нужно даже среду перезапускать, а достаточно подправить переменную PATH в среде, при этом автоматически осуществляется редискаверинг и реиндексация.
Мне так показалось удобнее, но я не настаиваю.

[AHTOXA]

mingw-get-setup.exe Можно выбрать то, что нужно.

О, спасибо, я как-то проглядел. Хотя не люблю я эти веб-инсталляторы

Это безусловно, если собирать из командной строки. Но если в проект входят ещё и настройки среды (файлы .project, .cproject, что в последнее время сполошь и рядом делается), что удобно для индексатора и discovering, то на мой взгляд лучше по-моему.

В этом случае сложнее перетащить проект в другую IDE. В моём же варианте - настройки сборки проекта - в makefile, настройки среды - в .project, .cproject.

Кроме того, "дефолтные тулчейны - в PATH" могут подложить свинью, поскольку оттуда трудно отследить какие именно инструменты вызываются. Например, у меня установлены две версии тулчейна от GCC ARM Embedded и один от CodeSourcery. Чтобы переключиться с одного на другой в Вашем варианте надо поменять переменную PATH и перелогиниться в системе (у меня по крайней мере так).

Нет, я говорил немного о другом. Я говорил о вызове с полным указанием пути к тулчейну.
То есть, дефолтный компилятор вызывается как arm-none-eabi-gcc, а компилятор из другого тулчейна - как C:/tools/cs/2011.09-69/arm-none-eabi-gcc.
При этом никаких изменений в PATH вносить не надо.
Впрочем, я тоже не настаиваю на этом варианте

[IgorKossak]

То есть, дефолтный компилятор вызывается как arm-none-eabi-gcc, а компилятор из другого тулчейна - как C:/tools/cs/2011.09-69/arm-none-eabi-gcc.

О! Почти пришли к общему знаменателю. За исключением лишь того, что я не пользуюсь понятием "дефолтного" тулчейна, ибо не понимаю этой сущности. У меня тулчейн всегда конкретный, записанный с полным путём (в переменной PATH среды разработки, в системной же PATH - никаких путей к тулчейнам). Что же касается makefile, то указывать там полный путь, на мой взгляд - моветон, ибо совершенно не переносимо.

[AHTOXA]

О! Почти пришли к общему знаменателю.

Да, мы близки к этому
Дефолтный тулчейн - это, скажем, текущий стабильный. Вышел новый gcc-arm-embedded - я его протестировал, убедился в его работоспособности, и прописал в PATH. И с этого момента все проекты компилируются им.
Вам же, чтобы откомпилировать старые проекты новым тулчейном -- придётся менять настройки для каждого проекта.
(Хотя может быть вы как раз наоборот, не станете менять, ибо раз проект разработан с конкретной версией компилятора, то пусть с ней и сопровождается. В этом случае всё нормально.)
Что касаемо указания полного пути в makefile, то это делается только на время эксперимента, потом убирается. Так что на переносимость не влияет.