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

Можно, работает без каких-либо доработок.
Можете взять примеры для STM32F2XX (GCC), они вообще должны заработать сразу.

ЗЫ. Естественно, плавучку использовать можно только в одной задаче.

А скрипт линковки какой взять? Из примеров платы или от ОС?

От ОС конечно. Прямо целиком пример берите.
Ну или могу выложить мигалку светодиодами непосредственно для STM32F4DISCOVERY. Надо?

Благодарю, не надо. Это были уточняющие вопросы. Огромное Спасибо!

Всегда пожалуйста
Забыл написать. Если захотите использовать плюшки M4F, и станете компилить для cortex-m4 (-mcpu=cortex-m4), то в OS_Target.h заругается на вот этой проверке:

Пока можно просто закомментировать её.
А потом, (я надеюсь, что скоро) появится нормальный порт для M4.

еще глупый вопрос: почему когда в скрипте линковки ставлю величину ram в 192к (сколько есть в контроллере) - сразу улетаю в дефолтный хендлер? я чего то не учитываю?

Видимо потому, что верхние 64К - это некая CCM (core coupled memory), которая не присоединена к bus matrix. То есть, любая попытка DMA-доступа к ней обречена на провал.
Кроме того, в RCC_AHB1ENR есть бит CCMDATARAMEN, возможно это означает, что надо включить тактирование этой CCM перед её использованием.

А там ошибки в sysinit нет? а то у меня возникла такая проблема?
http://electronix.ru/forum/index.php?showt...102811&st=0

В регистрах пока плохо разбираюсь

На STM32F4DISCOVERY кварц 8МГц, а в примерах (они для платы TE-STM32Fx07) - 25МГц. Это задаётся в makefile, строка

, поменяйте на 8000000.
А в sysinit.cpp, чтобы заработало на 168МГц, надо задать:

Ну и включить high performance mode:

Огромное спасибо за оперативную помощь по переходу!

Меня тут в личке попросили всё же выложить пример. Выкладываю.
Нажмите для просмотра прикрепленного файла

Это я просил.
Спасибо огромное.
Думаю будет, Вам, общая благодарность, если найдете время допилить порт под F4.

Еще раз Спасибо.

Могу вас порадовать, порт уже задышал. На днях постараюсь выложить в репозиторий.

Добрый день. Впервые пытаюсь запустить проекты на scmRTOS, использую Eclipse + Sourcey G++ Lite, получаю следующее:
c:\!Botva\8semestr\kursach\scmRTOS_stm32f4_sample\HelloLed>make
--- building HelloLed. defines: -DSTM32F4XX -DVER_MAJOR=0 -DVER_MINOR=1 -DHSE_VALUE=8000000
Ошибка в синтаксисе команды.
Ошибка в синтаксисе команды.
Ошибка в синтаксисе команды.
Ошибка в синтаксисе команды.
--- compiling ./src/sysinit.cpp...
"LC_MESSAGES" не является внутренней или внешней
командой, исполняемой программой или пакетным файлом.
make[1]: *** [obj/sysinit.o] Error 1
make: *** [all] Error 2
причем ошибки не подсвечиваются и никак не выделяются. Подскажите, что это может быть и как с этим бороться, пожалуйста

У Sourcery make называется cs-make. Исправьте в настройках проекта.
Кстати, в репозитории есть более свежие примеры.

Получилось примерно следущее в CoIDE
GCC HOME: C:\Program Files (x86)\GNU Tools ARM Embedded\4.8 2014q1\bin
compile:
[mkdir] Created dir: C:\CooCox\CoIDE\workspace\start_this\start_this\Debug\bin
[mkdir] Created dir: C:\CooCox\CoIDE\workspace\start_this\start_this\Debug\obj
[cc] 200
[cc] 9 total files to be compiled.
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -Wall -ffunction-sections -g -O0 -c -DSTM32F407VG -DSTM32F4XX -DSUPPORT_CPLUSPLUS -DUSE_STDPERIPH_DRIVER -D__ASSEMBLY__ -IC:\CooCox\CoIDE\workspace\start_this -IC:\CooCox\CoIDE\workspace\start_this\cmsis_boot -IC:\CooCox\CoIDE\workspace -IC:\CooCox\CoIDE C:\CooCox\CoIDE\workspace\start_this\OS_Kernel.cpp C:\CooCox\CoIDE\workspace\start_this\startup-stm32f4xx.c C:\CooCox\CoIDE\workspace\start_this\sys.c C:\CooCox\CoIDE\workspace\start_this\main.cpp C:\CooCox\CoIDE\workspace\start_this\OS_Target_asm.S C:\CooCox\CoIDE\workspace\start_this\OS_Services.cpp C:\CooCox\CoIDE\workspace\start_this\usrlib.cpp C:\CooCox\CoIDE\workspace\start_this\sysinit.cpp C:\CooCox\CoIDE\workspace\start_this\OS_Target_cpp.cpp
[cc] Starting link
[cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -g -Wl,-Map=start_this.map -O0 -Wl,--gc-sections -LC:\CooCox\CoIDE\configuration\ProgramData\start_this -Wl,-TC:\CooCox\CoIDE\configuration\ProgramData\start_this/arm-gcc-link.ld -g -o start_this.elf ..\obj\OS_Kernel.o ..\obj\startup-stm32f4xx.o ..\obj\sys.o ..\obj\main.o ..\obj\OS_Target_asm.o ..\obj\OS_Services.o ..\obj\usrlib.o ..\obj\sysinit.o ..\obj\OS_Target_cpp.o -lm -lgcc -lc -lrdimon -lstdc++
[cc] ..\obj\sys.o: In function `__cxa_pure_virtual':
[cc] C:\CooCox\CoIDE\workspace\start_this/sys.c:15: multiple definition of `__dso_handle'
[cc] c:/program files (x86)/gnu tools arm embedded/4.8 2014q1/bin/../lib/gcc/arm-none-eabi/4.8.3/armv7e-m/crtbegin.o:(.data+0x0): first defined here
[cc] ..\obj\startup-stm32f4xx.o:(.isr_vector+0x0): undefined reference to `_estack'
[cc] ..\obj\startup-stm32f4xx.o: In function `__Init_Data':
[cc] C:\CooCox\CoIDE\workspace\start_this/startup-stm32f4xx.c:257: undefined reference to `__ctors_start__'
[cc] C:\CooCox\CoIDE\workspace\start_this/startup-stm32f4xx.c:257: undefined reference to `__ctors_end__'
[cc] ..\obj\main.o: In function `Pin<(char)68, 12, (char)72, (PinSpeed)3>::SetPullUp(PullUpMode)':
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `Pin<(char)68, 13, (char)72, (PinSpeed)3>::SetPullUp(PullUpMode)':
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `Pin<(char)68, 14, (char)72, (PinSpeed)3>::SetPullUp(PullUpMode)':
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `Pin<(char)68, 15, (char)72, (PinSpeed)3>::SetPullUp(PullUpMode)':
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::BBBits'
[cc] C:\CooCox\CoIDE\workspace\start_this/pin_stm32F4xx.h:471: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `run':
[cc] C:\CooCox\CoIDE\workspace\start_this/OS_Kernel.h:646: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::BBBits'
[cc] ..\obj\main.o: In function `OS::process<(OS::TPriority)2, 600u>::exec()':
[cc] C:\CooCox\CoIDE\workspace\start_this/main.cpp:67: undefined reference to `Pin<(char)68, 12, (char)72, (PinSpeed)3>::GPIOx'
[cc] C:\CooCox\CoIDE\workspace\start_this/main.cpp:67: undefined reference to `Pin<(char)68, 13, (char)72, (PinSpeed)3>::GPIOx'
[cc] C:\CooCox\CoIDE\workspace\start_this/main.cpp:67: undefined reference to `Pin<(char)68, 14, (char)72, (PinSpeed)3>::GPIOx'
[cc] C:\CooCox\CoIDE\workspace\start_this/main.cpp:67: undefined reference to `Pin<(char)68, 15, (char)72, (PinSpeed)3>::GPIOx
[cc] collect2.exe: error: ld returned 1 exit status
[cc] '

BUILD FAILED
Total time: 2 seconds
помогите исправить, пожалуйста

Я не знаком с CoIDE. Судя по всему, в проект кроме стартапа от примера включен стартап от CooCox. Вот они и дерутся.
Нужно настроить проект на линковку без использования какого-либо стартапа.
И скрипт линкера не тот.

Ну а вообще, чтобы минимально зависеть от используемой IDE, надо делать так (только что проделал это на голой Win XP в виртуалке):

1. Качаем и ставим свежий gcc-arm-embedded.
   (не забываем поставить птичку "добавить путь в PATH" или что-то типа того)
   
2. Качаем нужные части из msys (не знаю, зачем они нашинковали их на столько кусочков, но уж как есть.):
   
   • core;
   • iconv;
   • libintl;
   • libregex;
   • libtermcap;
   • make;
   • coreutils;
   • bash;
   Распаковываем их все в папку "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q2\"
   То есть, make.exe, sh.exe и прочие утилиты должны попасть в папку "C:\Program Files\GNU Tools ARM Embedded\4.8 2014q2\bin"
   
3. Качаем и ставим svn.
   
4. Пуск - выполнить - cmd.
   Там пишем:
   
   Код
   C:
   cd C:\
   mkdir test
   cd test
   svn checkout http://svn.code.sf.net/p/scmrtos/code/trunk/Samples/CortexM4F/GCC/STM32F4XX STM32F4XX
   cd STM32F4XX
   switch.bat
   cd 1-EventFlag
   make
   
   (Я всё это делаю в файловом менеджере Far, там работать с командной строкой значительно удобнее)
   
5. Убеждаемся в том, что компиляция проходит без ошибок.
   
6. Теперь настраиваем любую интегрированную среду разработки на использование makefile. Всё.

Ура! Билдится! Спасибо
Знать бы теперь как отладку запустить(

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

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

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

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

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



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

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

)?

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

Так их в любом случае придётся перечислять, из-за префикса arm-none-eabi-

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

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

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

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

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

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

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

Можно вызывать сборку и так:


У меня в Makefile есть такой кусок:

Под Eclipse лень править вызовы для проекта с внешним makefile в Builder Settings, поэтому явно указан CROSS_COMPILE.
Можно убрать (закомментировать) путь к кросс-компилятору и использовать тот, который указан в путях (у меня нет такого).
По поводу переносимости - невелика правка, хуже когда весь проект даже в другую директорию переносится с усилием (по опыту работы с средствами разработки от TI).

P.S. А не следует ли кусок обсуждения про настройку makefile перенести в раздел GNU/OpenSource средства разработки для avr/arm/mips, где это собственно уже и имеется. Для полноты картины?

Хорошо бы, но это может сделать модератор именно этого раздела.