"Говорят, в Москве кур доЯт". ... Есть стандартный SWD-интерфейс отладки и загрузки, зачем мучиться с UART-загрузчиком? Загрузчики через иные интерфейсы нужны для перепрошивки или первичной заливки в готовые устройства.

Точно так же как в AVR. Включаете питание и код начинает выполняться с Reset_Handler.

Не придумывайте, какая ещё операционная система? Всё то же самое как в AVR.

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

Как вы себе это представляете? Вот включили вы питания контроллера, флэш девственно чистая (экономите ресурс). Откуда код и данные появятся в ОЗУ? В ОЗУ размещаются переменные (нулевые занулением, ненулевые копированием из флэш в стартапе), а во флэш лежит код. Лежит себе, положенный туда один раз при программировании.

Экономят флэш когда занимаются постоянно отладкой. Тогда с помощью отладчика (ST-Link, J-Link и др.) загружают код в SRAM. Тогда флэш и правда не используется. Именно при таком сценарии использования нужен скрипт линкера с перенаправленными в SRAM секциями. Для штатной прошивки, которая должна работать в контроллере при включении питания это всё не работает.

У контроллера в документации написано по каким адресам какая память находится. У вашего контроллера по адресу 0x08000000 всегда флэш, а по адресу 0x20000000 всегда SRAM. Так устроен чип. Если сказано разместить в SRAM (0x20000000), то ничем иным это не будет.

Подумайте и ответьте на два вопроса. Откуда копируется секция данных? Куда кроме ОЗУ она может копироваться?

Сам МК ничего поместить не может. Есть три основных механизма загрузки кода:
1. Программа программатором прошивается во флэш и лежит там постоянно. При включении питания из него и стартует.
2. Отладчиком программа загружается в SRAM и работает оттуда до выключения питания.
3. С помощью перемычки в МК запускается программа-загрузчик, находящаяся в системной памяти. Эта программа-загрузчик позволяет прошить флэш через UART, USB и т.д. без программатора. После прошивки перемычка снимается и работает всё как в п.1.

Поверьте, проблема не в скрипте линкера, а в том что пример своего блинка вы на какой-то помойке нашли. Оставьте в проекте скрипт, который я выкладывал и больше в него не заглядывайте. Поверьте, там проблем нет.

Когда вы работали с Ардуино, то "под капотом" было всё то же самое. Просто IDE всё от вас прятала и дурные мысли не приходили.

Совет - создайте чистый проект руками. В него включите:
1. Стартап файл.
2. Линкерскрипт.
3. Заголовочный файл от вашего микроконтроллера.
4. Папку CMSIS. Заголовочные файлы из неё понадобятся для пункта 3.
5. Один файл программы с функцией SystemInit. В ней включите тактирование GPIO-порта, на котором висит диод.
6. Второй файл программы, в котором в main мигайте себе светодиодом.

Так и разберётесь как что работает, и с "лишним" бороться не надо будет.

Добавлено after 15 minutes 38 seconds:
Ну так не собирайте его на всяких помойках. Самому, конечно, трудно с нуля проект сделать. Но можно же на форуме попросить. Минимальный проект без всякого мусора. IDE нормальную используйте, с нормальной отладкой. Тогда никакие симуляторы не понадобятся.

ST-Link самый дорогой $3. Зажали и будете без отладки через загрузчик шить? Ну-ну. Чем тогда это от ардуины будет отличаться?

А чё, прикольно. Купить контроллер с 256к на борту и впихнуть всё в 2к. Занятная цель.

Добавлено after 20 minutes 10 seconds:
Так это, там хранятся адреса конструкторов глобальных объектов.
В стартапе для их использования вот такое пишут

Размещает компилятор, а не МК.
МК в стартапе может скопировать что-то из флеша в ОЗУ, но к размещению секций это отношения не имеет.

В теории да но на практике, обычно скорость выполнения из флеша примерно такая же как из ОЗУ. Учтите что ОЗУ намного меньше чем флеша. Размещать в нем код без необходимости обычно не имеет смысла.

Как это влияет на работу прошивки? Релизную все равно нужно шить во флеш потому что ОЗУ хранит данные только пока есть питание. А отладочные прошивки можно грузить в ОЗУ. В IDE выбираете цель сборки Debug RAM или подобную (зависит от IDE), компилируете и заливаете в МК.

Вы прошиваете МК 1500 раз за день? У флеша гарантированный ресурс перезаписи около 10 тысяч.

В МК переменные могут быть еще где-то кроме ОЗУ?

Дизассемблируйте прошивку и посмотрите как она устроена. Посмотрите map файл. Запустите отладку и по шагам проследите как выполняется программа, что и куда пишет/копирует и т. д.

Нормально создавайте проект не добавляя то что не требуется.

Вроде что-то связанное в объектами плюсов, но могу ошибаться.

Библиотеки HAL/LL/SPL/CMSIS в файлах проекта и там тысячи строк кода. Будете вручную выпиливать все что не используется?
А сколько подобного кода было ардуине, о котором вы похоже даже не знали.

А если флеша хватает?
Откуда столько заблуждений? Видимо негативное влияние ардуины!

Отладчик освойте (купите ST-Link если его нет). Многие вопросы отпадут, потому что когда видно как работает программа что и где находится, не приходится догадываться о работе МК.

Ну, как вам сказать... Да! В IAR для AVR можно переменные в EEPROM размещать.

Наверное есть, но у меня нет SWD-программатора, есть только usb-ttl. Если можно просто прошить меня это устраивает. Дебаг на работающей плате мне не особо нужен, в AVR мне это не потребовалось. Там отлаживаю на коде для компа, или перепрошивкой с выводом значений printf().

Из флеша во флеш, этакий недокументированый swap. С одной стороны это бессмыслено, так как данные копируются из флеша во флеш. Но если это убьёт МК быстрей производитель только порадуется, а виноват программист, - незачем было указывать размещение во флеш). Таким образом мы ограничивает МК не только по числу перезаписей, но и по числу включений. Это я опять выдумываю).


А зачем отладчик загружает программу в SRAM, если флеш настолько хорош? И почему так не делают в рабочем режиме, если только не из экономии RAM?


Я в vim'e писал, в том числе простой makefile с компиляцией каждого файла. Но вот avr-gcc действительно скрывало многое, что просто gcc для stm32f4 не скрывает.

Спасибо, примерно это я сейчас и пытаюсь сделать.


Впринципе всё понятно, можно и на Эклипсе жить, отладчик gdb и printf(), если дойду до Хеллоу Ворлда.


Я и ожидал что работа с stm32 от Ардуины ничем принципиально отличаться не будет. Тем более что больший размер памяти упрощают алгоритмы, и приводит к уменьшению кода. А я и ардуину не отлаживал на чипе, только на компе куски кода и через printf(), с этим можно жить.


Цель была упростить код, который на ардуине впритык расходует 2 кБ RAM, что приводит к усложнению алгоритмов. А хотелось их упростить, так как 64 кБ RAM на stm32 должны были развязать руки. Но не всё так просто оказалось)

Ну мы тут обсуждаем STM32.
И это не совсем переменная. Это скрытая запись в энергонезависимую память.
С таким же успехом можно разрешить запись во флеш и записывать вызовом FLASH_ProgramByte() или подобной.

ST-Link продается на каждом углу и стоит около 150 рублей.

Спойлер

Его можно самому собрать.

Это не отладка, а много зря потеряного времени!
Вот смотрите просмотр регистров под отладчиком. Как это сделаете на printf()?

Спойлер

Выводить все регистры? Представляете сколько это текста и как неудобно и утомительно анализировать выхлоп?

Смысл?

Если не потанцевать с бубном не разблокировав запись во флеш, и не стерев страницы, записать ничего не получится.

Ага!

Загружает если это явно заданно. Обычно применяется для отладки чтобы флеш не протирать.

Нет смысла. Программа нормально из флеша выполняется (в AVR разве не также?).

Это вы все усложняете начав изучение не с той стороны.

Странное ожидание. Лет пять назад вас за такие слова помидорами бы закидали Дело в том, что STM32 это принципиальная и диаметральная противоположность Ардуины. А то, что появились некоторые адруиноподобные шилды на STM32 и в Ардуино-IDE добавили младший STM32, это еще не говорит о принципиальной схожести.

Исполнение не из флеша может быть нужно в очень старших семействах STM32 с выделенной специальной областью SRAM (ITCM RAM), в которую загружаются некоторые небольшие части кода. Своего рода кэш второго уровня.
Так же исполнение из SRAM может использоваться при перепрошивке флеша в готовом устройстве. Однако, оно небезопасно при неожиданном прекращении питания во время перепрошивки - опасность окирпичивания.

Исполнение из общей SRAM чревато снижением скорости, потому как SRAM однопортовая и если нет второго отдельного блока SRAM с отдельным портом, обращения к SRAM будут делиться между исполняемым кодом и данными.

Такое выдумать можно только под воздействием чего-то запрещённого.

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

А как вы себе это представляете? К каждому серийному изделию по программатору и программисту запускающему его в коробку класть? А экономия RAM и флэш вообще бессмысленная вещь до тех пор пока код помещается в микроконтроллер и работает с необходимой скоростью. Конечно, когда пишешь какие-то библиотеки или тот же стартап, то надо писать оптимально, ибо использоваться будет в разных проектах и это не станет узким местом в будущем. Но если надо на F4 написать мигалку светодиодом, то нет никакого смысла тратить время на "утаптывание" кода. Спасть лучше от осознания, что прошивка занимает всего 1 кБ из 1 МБ я точно не буду.

Одно дело когда подруцгому никак, то довольствуешься тем что есть. Но когда есть возможность отладки, это совершенно другой стиль разработки.

Ерунда, всё реально. Было бы желание.

Добавлено after 8 minutes 48 seconds:
В терминах языка программирования, на котором написан код, это именно переменная и есть. Я могу с ней работать как с любой другой - присваивать значения, копировать, выполнять арифметические операции, передавать значения в функции и т.д. Во что это компилируется вообще не имеет никакого значения. Например, при копировании структур или массивов компилятор частенько вызывает незаметно для программиста функцию memcpy. Вы же не отказываете из-за этого им в праве называться переменными?

А вот это совсем другое. Если бы компилятор сделал всё это незаметно для программиста, как в приведённом мной примере, то да. А так НЕТ!

Вот только сейчас додумался как правильно сформировать запрос для гугла, и за 5 минут узнал всё что хотел.
И таки да, всё связанное с С++, С#, всем тем зоопарком что выше. К функции SystemInit() вообще ни как не относится. Даже сами авторы GCC считают _array некрасивым, уродливым решением. Но ничего лучше предложить не могут.

Намекаю второй раз уже в этой теме. В GCC конструкторы могут быть не только в С++, но и в православном С. Как бы странно это не звучало.

Намекаете что в проекте могут быть вперемешку *.c и *.cpp файлы или о чем-то другом?
В описании языка Си не встречал упоминаний о конструкторах в структурах или о классах.

Это расширение GCC, стандарт С такого не предусматривает. Тык!

Тогда понятно.
В GCC есть много чего не входящего в стандарт, например вложенные функции.

Однако, стартап написан для GCC и должен поддерживать все его возможности. Просто так выкинуть из стартапа вызов конструкторов из-за того что вы не используете С++ можно только из-за великой жадности.

Спасибо, я уже наступил на эту лепёшку. Мне всегда подобный код казался странным и непонятным. После глубоко_копания в разные стороны - ощущение укрепилось, мне этого не надо.
Гораздо проще работать с памятью явно и прямо здесь, а не ожидать что память выделится магическим образом через вызов функции из исполняемого файла в другом каталоге проекта.
Ну да, С++ у меня не очень, точнее вообще никак.



Я уже неоднократно замечал - человек не в состоянии принять и понять информацию, если она имеет базовый конфликт с его опытом.
Кхм, думаю если ему показать левую колонку видимых функций и переменных - он вообще ничего не поймёт. Как например я не понимаю, откуда аурдинщики берут имена функций: без встроенной подсказки, без автоматического дополнения, без динамической фильтрации типов, без той самой левой колонки любой нормальной IDE. Наверное по старинке, из бумажной книжки.

Копипастят друг у друга... Ардуина, кмк, сильна сообществом.

Да именно так. Так как большинство ожидает от STM32 уровня программирования даже не Ардуино-IDE, а хотя бы AVR (avr-gcc), но нет, в STM всё намного хуже. И когда после AVR человек пытается использовать STM, он получает отрицательные эмоции во-первых от настройки стартапа, которого в AVR нет. И утешает себя ну мол ладно, стартап переварю и дальше всё пойдёт. Но тут бах и - HAL. И первая реакция, ну ладно, в AVR тоже были библиотеки абстракций, и здесь я избавлюсь от HAL. И чел пытается смотреть примеры без HAL, а там тоже какой-то ужас, и получает ещё отрицательных эмоций с попыткой разбить BluePill об стену . После чего говорит, ну ладно буду использовать этот ужасный HAL. Берёт пример с hal-uart - print "Hello World" ковыряется в библиотеке включая нужные дефайны. Запускает и ..... облом . Копаясь в куче ошибок компилятора ... понимает. Что в этом примере "Hello World" - другая версия HAL и тут терпению приходит конец, как и BluePill'у .
И после таких приключений , кто-то пишет ещё один отрицательный отзыв о STM32, что это ужас-ужас. (и это отзывы не Арудинщиков начального уровня ).
Что вы уже "неоднократно замечали".


В AVR для выполнения реальной задачи оперируют 10 функциями в 2-3 файлах, а в STM32 чтобы вывести строку "Hello World" надо оперировать 100 функций расположенной в двух библиотеках. И тогда потребуется IDE не для того чтобы удобно писать код, а для того чтобы исследовать код библиотек, стартапав и прочего. И вот когда вы с этим разберётесь (с помощью IDE - которую вам тоже придётся изучить) - добро пожаловать в STM32.
И какое сообщество может быть у STM32 с такими граблями?
Цены на AVR подтверждают всё вышесказанное. )

Ой, а можно посмотреть эти "ужасные" примеры? Просто как раз пишу на CMSIS и оч. любопытно чего вы такого ужасного там нашли?

А что ужасного в STM32? Это просто гораздо более мощный микроконтроллер с гораздо более высоким порогом вхождения, для более умных и опытных программистов. Документация - да, на порядок объемнее. Про стартап линкерскрипт уже сто раз объяснили. Автор вопроса либо тупит, либо капризничает. Ну да, STM32 гораздо сложнее, это вы ещё не видели системы тактирования в каком-нибудь STM32H743. Но это просто совершенно иной уровень. Если программист не тянет мозгом, то незачем и начинать. А то как в басне про обезьяну и очки.

Автору - не волокешь, не хватает соображаловки, мозги не проворачивают объем информации - просто не лезь в эти дебри, сдохнешь. STM не виноват, что он сложный. Виноват программист, недостаточно подготовленный и не понимающий. А ведь есть и гораздо более сложные системы, для весьма подготовленных специалистов.

Это не так. Нет необходимости на начальном этапе разбираться со стартапом и скриптом линкера. Они добавляются в проект при его создании в IDE.
Ваша задача, создать проект и писать код. Но вы решили все усложнить.
Смотрите, проект создается и все сразу готово к компиляции прошивки без необходимости править стартап и скрипт линкера.

Спойлер

Зачем вы решили все усложнить, непонятно.

Зачем вы полезли его настраивать?
В этом нет необходимости. Сами себе создали сложности!

Можно писать без HAL. Это одна из библиотек и никто не заставляет ее использовать.