Обычно когда я начинал новый проект под STM32 я выдергивал startup файл из какого нибудь демонстрационного проекта. но теперь я хочу начать новый проект под STM32F411 и не могу найти startup файл. максимум что я нашел это startup_stm32f401xe.s. где можно найти startup файл?

Сообщение отредактировал Jenya7 - Sep 24 2015, 13:29

Полагаю, что у Вас есть два пути:
1) Взять и наконец написать, а не "дергать" что-то откуда-то.
2) Не заморачиваться вообще - что нибудь, как нибудь волшебник генерящий всякие проекты в IAR Вам нарисует.

вроде нашел. лежит у меня в сорсах. не помню откуда взял.
теперь ругается на Fatal Error[Pe1696]: cannot open source file "stm32f411xe.h" а у меня есть только stm32f401xe.h.

вроде бы победил и эту проблему. но теперь при компиляции ругается
stm32f4xx_hal_flash_ex.c
Error[Pe020]: identifier "FLASH_MER_BIT" is undefined
на строке FLASH->CR &= (~FLASH_MER_BIT);
перерыл все файлы - нигде не нашел такой дефайн FLASH_MER_BIT. что то ST со своей HAL библиотекой начинает меня раздражать нипадецки.

понял в чем дело. дефайны зависят от камня. у них везде
#if defined(STM32F405xx) || defined(STM32F415xx) || defined(STM32F407xx) || defined(STM32F417xx) || defined(STM32F401xC) || defined(STM32F401xE)
а моего камня нет.мне приходиться вручную добавлять || defined(STM32F411xE)

я их маму в белых тапках видел чес слово....

Сообщение отредактировал Jenya7 - Sep 24 2015, 15:19

А у меня почему-то всё необходимое находится:
STM32Cube_FW_F4_V1.5.0\Drivers\CMSIS\Device\ST\STM32F4xx\Source\Templates\iar\startup_stm32f411xe.s
STM32Cube_FW_F4_V1.5.0\Drivers\CMSIS\Device\ST\STM32F4xx\Source\Templates\iar\linker\stm32f411xe_flash.icf
STM32Cube_FW_F4_V1.5.0\Drivers\CMSIS\Device\ST\STM32F4xx\Include\stm32f411xe.h

Попробуйте скачать HAL посвежее, Ваш вероятно появился раньше чем F411 процессор.

спасибо за наводку. похоже у меня таки старый HAL.

извиняюсь что я туплю. а где можно взять новый HAL? я свой выдрал из какого то проекта. на сайте нет. только установка среды.

все. собрал проект. правда по ходу дела такого начитался про HAL . народ ругается и плюется. все резко полюбили обратно StdPeriph_Driver.

Сообщение отредактировал Jenya7 - Sep 25 2015, 05:06

https://www.google.ru/search?q=STM32CubeF4+...oGcf8ygOTvbCAAw
первый же результат:
http://www.st.com/web/en/catalog/tools/PF259243
.zip в самом низу страницы.

Что HAL, что StdPeriph - выбор между чумой и холерой.
Впрочем, с помощью STM32CubeMX можно распределить периферию по ножкам и сгенерировать проект для быстрого старта.
Инициализацию периферии можно оставить родную, там они почти нигде не накосячили, а глубже разбираться с их HAL - только время терять.

Мне, как человеку "воспитанному по строгим древним правилам, ... , а довольное испытание подало потребное просвещение, дабы судить о вещах"© проще всю остальную работу с устройствами сделать самому.

А я поддержу товарища zltigo - написать стартап самому. Там ну очень мало нужно написать, причём ассемблер совсем не нужен (не зря же говорят, что Cortex-M заточен под Си). А для общего развития полезно.
Только если в стартапе нужно что-то прикручивать для совместимости с кубами/халами и прочими блюмблюатеками, то увольте. Это уж точно время терять.

Переписать такой startup это все равно что переписывать стандартные хидеры чипа.
Там перечисляются вектора, и зачем их писать заново?

Я, например, почти никогда не использую "стандартные хидеры чипа" (если конечно речь идёт об описании периферии), пишу их сам.
Одна из причин: приходится работать с МК разных производителей, у которых свои собственные непохожие стили описания. Так что для своего удобства, пишу сам. Времени , это занимает немного.

Какой "такой"? Они вообще разные должны быть для разных случаев жизни и подгибание их под один "универсальный", или генерация и склеивание из мгочисленных кусочков в нечитаемый человеком исходник, не есть хорошее решение. И даже в таком вырожденном варианте, который характерен для кортексов-м, в startup есть что испровить и дописать. Исправить, как минимум выбранные неведомо кем и с какого бодуна имена обработчиков (мне удобнее всегда и везде иметь понятные и привычные МНЕ имена для ВСЕХ контроллеров с которыми я работаю). Есть и что дописать - те-же обработчики исключений на которые практически всегда откровенно плюют. Причем эти обработчики незачем дублировать в загрузчике и в основной программе.
То-же касается и "стандартых хидеров чипа" - уж больно разные стили у них а зачастую и вообще категорически неприемлимые, как у того-же IAR испольльзующего свои расширения языка.
Производители компиляторов зачастую допускают отклонения от аббревиатур в документации производителя. Да и у самих производителей тоже рыльце в пушку бывает часто - выпускают новый чип и даже в той-же серии допускают неведомо зачем изменения в названиях регистров. Или добавляют еще такой-же интерфейс и ко всем именам регистров добавляют цифры. И старые исходники, что теперь править и сопровождать в двух экземплярах для разных чипов? Типа после выхода фильма "Терминатор-2" нужно менять титры "Терминатор" на "Терминатор-1"?
Времени, как уже писал jcxz, это занимает немного, тем более это пишется по кусочкам в порядке добавления в процессе изучения железа. Да и это небольшое затраченное время с лихвой окупается уменьшением затрат времени на то, что-бы НЕ вспоминать, спустя дни или годы, как сегодня на этом контроллере в этом компиляторе что-то там называется.

Ну на самом деле нет. Вектора просто копируются из даташита и чуток обрабатываются find/replace. А больше там ничего особого объемного и нет. Более того, у меня к примеру один стартап для CM3, куда в зависимости от типа проца подключается нужный хидер с векторами