Хорошо. Но как быть с ОЗУ?


Не вижу моря. Вам видно виднее сколько памяти в моём проекте.

Ваш проект не при чем.
Просто вы не привели никакой альтернативы статическому анализу стека да еще при дефиците памяти.

Я так и дождался от Вас расшифровки термина "статический анализатор стека", может поэтому и не привёл. Не знаю что это такое.

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

Если бы Вы когда-нибудь разрабатывали ПО для МК на ядрах Cortex-M3/4, то знали бы что такое MPU.

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

Во-во! А у нас в некоторых задачах по нескольку КБ стеки уже. Не в моих задачах - я стараюсь экономить память. Но я не один участвую в проекте.
Это хорошо как Вы пишете распланировать когда ты сам себе хозяин и только один пишешь ПО.
Но как трудно объяснить людям почему нежелательно использовать sprintf() или что, если например внутри switch в одном case на стеке используется временная структура1, а в другом - временная структура2, по неск. десятков байт каждая, то очень желательно их объединить в union. Ну и т.п.
И что ещё - хорошо, например сейчас определили, что в задаче1 вызывается такая-то функция, которая ест много стека. Хорошо - выделили этой задаче побольше. Но потом, когда уже подзабыли немного, что эта функция много ест при определённых условиях, и сделали её вызов из другой задачи2, имеющей мало стека. И писал эту функцию совсем другой человек. И отладили, проверили - всё ок, работает ок. А ведь эта функция много ест стека только при определённых редких условиях и на этапе отладки эта ветка выполнения кода не случилась, а вылезет оно потом много позже и неожиданно.

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

Это ваши проблемы.
Пока я вижу такой настрой: "Вы тут мне предлагайте всякое разное, а я придумаю 1000 и одну причину, почему мне это не подходит".
Хозяин - барин, конечно, но выглядит это всё довольно комично.

Вообще-то вопрос был конкретный: про вставку пролога в функции в IAR. Ни одного дельного предложения по этому вопросу не было.
И причины я никакие не придумываю: причины все существуют, вот они передо мной, в проектах. Не понимаю - что именно комично? Объём кода большой (около 70 тыс. строк), памяти впритык (почти во всех проектах так), написателей кода - куча, задач - куча. И ПО ведёт себя как-то неадекватно. И что в этом случае делать-то прикажете? При каждой проблеме всё вручную пепрепроверять? Во всех режимах работы и функциях и их комбинациях коих тьма? И делать это после каждого внесения изменений в код каждым разработчиком? И что именно проверять? Как быстро определить где искать проблему???
Для такого тестирования у нас есть полигон, где стоит несколько десятков устройств и работают круглосуточно в реальных режимах работы. И нужно чтобы залить в них ПО и чтобы оно там крутилось долго и когда проявится проблема - вылетело на ловушку, сохранив состояние, по которому можно локализовать проблему.
Вот и хочется для наиболее типичных вариантов проблем (в частности - переполнение стека) сделать какие-то методы быстрой локализации, чтобы в случае поиска проблемы, быстро отсечь эти варианты.

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

70 тыс. строк это несложный проект. В такой размер помещается простейшая RTOS и с пару десятков модулей с логикой и аппаратной поддержкой.
Такой проект должен делать один человек.
Переполнение стека это не типичная ошибка.
Косвенных вызовов в таком проекте будет не более десятка. У вас все решения лежат на виду.
Проблема чисто организационная. Либо у вас проблема с выбором платформы и отладочных инструментов.

Про "круглосуточно в реальных режимах работы" тоже можете не плакаться.
У нас в Австралийской пустыне и на Тайване техподдержка через teamwiewer собирает логи и апгрейдит программу.
В Саудовской Аравии специалист спокойно сидел на объекте и JTAG-ом ловил баги.
Китайцы, так те самостоятельно отреверсили наши протоколы, присобачили беспроводные модули и сделали круглосуточное наблюдение через облака.

Не далее как вчера мне пришла ссылка на хорошую статью про выбор платформы - http://www.edn.com/electronics-blogs/embed...ampaignId=29190

Сдается мне у вас скверно выбрана платформа ( ну кроме того, что еще и скверная команда)

Ну да-да - рассказывайте сколько у меня косвенных вызовов - Вам конечно виднее. И какая разница - сколько их? Что от этого меняется?
И про простейшую ОС - тоже. В каком-то ином мире Вы живёте видно. У нас ОС занимает менее 13тыс. строк. И это с кучей комментов и портом под ядро.
А в 70тыс.строк я ОС не включал. И эти 70тыс. - это почти без комментов.
И про объём это Вы похоже слабо владеете предметом. Вероятно у Вас ПО состоит из набора откуда-то стянутых чужих кусков. И для Вас писать ПО - слепить эти куски воедино. Так и 700тыс. - не проблема.
У нас же в этих 70тыс.строках нет ни строки чужого кода.


И что Вы этим хотели сказать??? У нас тоже основное ПО устройства обновляется удалённо через любой доступный канал связи по рабочему протоколу и без всяких тимвьюверов и безопасно. И даже с рестрансляцией через несколько устройств (если целевое устройство не поключено к глобальному каналу связи). И не только основное встроенное ПО можно обновить, но и встроенное ПО любого из входящих в состав устройства связных модулей (ZigBee, RF, GSM, PLC). И тоже безопасно.
Только какое это имеет отношение к вопросу???
Почему не получится отловить JTAG-ом, я тут уже несколько раз объяснил. Если не поняли - извините.

PS: Пустой трёп про китайцев в облаках поскипан.

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

Ну разве это не диагноз?

Я не обсуждаю здесь лошадей, не обсуждаю и проект. Это Вы всё время стараетесь стащить тему во флейм.
Вопрос был конкретный - в заголовке. Или более расширенно - о методах контроля стеков задач в многозадачной среде в общем случае, а не в частных типа: имеем вагон+тележка памяти и можем каждой задаче по мегабайту на стек выделить.
И чтобы это было удобно сделано - при малейшем подозрении на проблему со стеком: включил чекбокс/define, проконтролировал работу девайса в течение длительного времени на нескольких устройствах. И не надо было при каждом подозрении на стек, делать кучу ручной работы (ставить watchpoint-ы, снимать, просматривать стеки задач и т.п.). Я думаю это полезно будет не только в моих проектах.
Недостатки проектов, в которых я участвую, более здесь обсуждать я не намерен. Я их сам прекрасно знаю и чьё-либо мнение здесь на этот счёт меня не интересует.
Если нечем заняться и нечего сказать по существу - лучше пройдите мимо.

В Кейловской РТОС можно включить контроль переполнения стека, одной галочкой в настройке. Если случится, вылетаем в os_error, и там можно определить, из какой задачи прилетели.

Может попробовать использовать MPU? Расставить за концами стеков области с запретом на доступ...
Хотя кмк с такими запросами пора переходить на чип толще, с защитой адресного пространства задач. Ну или программистов строить - устроить кодревью репозитория с прошивкой.