ЗАЧЕМ??? ...если куча не нужна и не используется нигде в проекте.
Во всех моих проектах размер кучи задан ==0 в конфигурационном файле компоновщика.
У меня везде так (для IAR):

А далее:

Стеки задач, основной стек (который указан в reset-векторе) и стек исключений определены подобно:

Иногда я объединяю все стеки (задач, основной стек и стек исключений) в единый сплошной блок через define block.
Имхо: определять размеры стеков в си-шных файлах гораздо удобнее, чем в едином конфигурационном файле компоновщика.

PS: Контролировать размер стеков конечно нужно. И выделять под них память, а не надеяться что "что-то не налезет на что-то".

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





Чем? Есть одно место, где описаны все размеры блоков памяти конкретного проекта. Заходишь и смотришь, а не надо ползать искать. Когда пишутся, например, всякие демки на 999 вариантов, тогда в них приходится выносить и размазывать настройки по файлам и ключам. Но для конкретного проекта зачем?

Как можно контролировать стек (не задач в RTOS), который растет себе и растет, пока не налезет на кучу или переменные??

Также, как и "задач в RTOS". Какие проблемы? Те стеки тоже "растут себе и растут"... С контролем НЕ в реальном массштабе времени проблем нет. Но вот именно отсутствие контроля в реальном времени как раз и не позволяет на ходу разруливать ситуации со стеком и следовательно по любому под стек нужно выделять гарантированно достаточное место. Потом уже постфактум по результатам контроля, если надо, думать уменьшить его или нет.

Есть задача, у неё свой стек. Все переменные, дефайны этой задачи - в её файлах. Проект состоит из множества таких задач. Естественно что данные, нужные локально только данной задаче, должны быть локальны (описаны именно в её файлах, а не вкаком-то едином файле). А стек - это локальная сущность конкретной задачи. И размер его скорее зависит от данной задачи, а не от проекта в целом.
Или Вы и локальные переменные каждой задачи тоже в едином файле определяете?

Не передергивайте! Речь идет о статически распределяемой памяти.
Но, если-бы я с какого-то бодуна выделял стеки задачам статически, то, да и эти БЛОКИ памяти я бы ТОЖЕ описал под линкер, что-бы видеть общую картину в одном месте и сразу при проектировании, а не тогда, кода линкер выругается при линковке что памяти совсем нет. После чего придется ползать по куче файлов и думать где жертвовать.

Содержимое стека - несомненно. Но сам стек, как блок памяти, это уже элемент ВЕРХНЕГО, надзадачного уровня. Вот и его выделением и размещением занимается НЕ задача.

К чему эта дурацкая фраза и усмешка?

В принципе - можно и в реальном. И даже под многозадачную ОС.
С MMU конечно вообще проблем нет такое сделать. Но даже с MPU это возможно. Я уже не раз задумывался чтобы внести такую функциональность в свои проекты, всё руки не доходят.
Как:
Вынести все стеки задач в единый сплошной сегмент памяти. Закрыть полностью доступ к этому сегменту через MPU. В ISR PendSV при каждом переключении пользовательского контекста, программировать перекрывающую запись таблицы MPU (более приоритетную чем та запись, которая закрывает доступ ко всему сегменту стека) на новый стек (находящийся внутри общего сегмента стека).
Конечно будут потери памяти на выравнивании, необходимом для MPU. Но сделать вроде можно.
Да - в начале и в конце сегмента стека должны быть небольшие интервалы неиспользуемой памяти.
Конечно, если функция внутри задачи написана так, что выделяет размер массива выходящий за границу сегмента стека, то тогда такая защита может не спасти. Но чаще всего доступ к стеку идёт более-менее последовательно, небольшими шагами.


А с какого бодуна Вы выделяете стеки задачам динамически? И зачем такое делать? Задачи создавать/убивать? Это лишнее.

Без комментариев, ибо рожденный ползать понять "лишнего" не может

Размещением стека, как и любой другой статической переменной у меня занимается компоновщик. Не вижу ни малейшего смысла выделять стек динамически.
Какая разница кто размещает?
Есть разница где эта переменая описана. А описана она должна быть там же, где и прочие локальные переменные задачи.


Думаю, что во всех случаях, когда нужно зачем-то создавать/убивать задачи в embedded среде с заранее известным выполняемым функционалом (речь не идёт о системах, в которых заранее не известен список работающих задач, когда задачи запускаются пользователем), всегда можно составить максимальный список задач, которые могут работать одновременно, выделить под них стеки статически и все их запустить.
И не убивать их когда работа закончена и создавать заново, а просто приостанавливать выполнение когда необходимо (на мэйлбоксе например), до появления новых данных для обработки.

Если опустить RTOSы и MMU/MPU.- а такие системы с супер циклом просты и весьма популярны, - то контроль стека организовать затратно, и риск проехать катком стека по переменным есть. Это неизбежно.
На мой взгляд, в системе со стеком И кучей следует именну кучу выделять фиксированного размера, а стек - сколько есть памяти. Почему? Оценить потребность в стеке гораздо сложнее, чем в куче: прерывания, рекурсии, сложно-предсказуемые глубины вызовов... А вот работа с кучей более детерминирована и подконтрольна. Например, в тех немногих местах, где она используется, легко проверить полученный от malloc указатель на NULL и ругнуться, если что не так... Стек же я инициализирую на самый верхний адрес доступной RAM памяти. Как это в .COM программах в DOS делалось (я стар, о я очень стар, я - суперстар!).

Если есть куда ругнуться. А если ни LCD ни UART с терминалом? Да и вообще - ближайший человек за тыщу км

Когда о количестве ресурсов можно не думать, то оно, конечно, все "просто". Просто берем больше памяти, мегагерцев, размеров корпуса и батареи.






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

Тогда можно ругнуться в себя.

Я едва-ли Вас моложе, но так уже не делаю , тем более, что не у x86 этих самых стеков чаще всего не один

Подскажите во время отладки в CoIDE где можно узнать адреса по которым расположены переменные?