Собственно, надоело мне размер стека на шару выставлять.
Посоветуйте плиз как это делать наиболее "разумно".
Залез в Keil-овский репорт, там первой строкой (надо полагать нихудший случай):Не совсем доганяю, что значит вторая часть слагаемого?
Еще, как то можно его (стек) во время работы измерять?
Например, под microblaze есть функция которая выполняется в случае переполнения стека, полагаю подобное есть в любой среде?

callback - вызовы через указатели на функции, возможно присутствующие в программе.

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

Кстати, попутно и у меня возник вопрос - есть-ли в природе для arm-elf-gcc свободные программы для анализа и оценки максимального значения используемого стека? Вопрос далеко не праздный - искал, но ничего толкового не попалось.

Моих познаний для этого не достаточно.

Есть один простой способ, хотя и не идеальный. При запуске программы область стека инициализируется известными данными (например, 0x12345678). Затем программу гоняют, стараясь заставить её использовать стек по максимуму. После этого смотрят в облась стека и видят, сколько было затёрто (данные не равны 0x12345678).

Я все-таки думаю, что достаточно.
Такая функция должна делать всего две вещи в первом приближении: получать текущее значение SP и сравнивать его c константой - пределом стека. Если перешли - значит ошибка.

Как с помощью ассемблерной вставки прочитать SP, думаю, разобраться не сложно. Что же касается вышеупомянутой константы - ее можно либо объявить с помощью скрипта линкера (экспортировать символ-указатель на нижнюю границу стека), либо иным доступным способом.

Сложнее сделать backtrace, но тоже вполне реально. Тем более, что у компиляторов есть возможность генерирования стековых фреймов в соответствии со стандартом APCS.




Да уж, от идеала далеко... Как часто нужно запускать процедуру контроля?
К тому же при переполнении стека программа может уже не вернуться в основную свою ветку, где происходит проверка. Так что этот способ лично мне видится совершенно бесполезным.

Отнюдь

Например - раз в неделю, ибо частота контроля для данного механизма не принципиальна совсем.

Это исследовательский способ и в простейшем случае для начала стек берется с явным запасом.
Но а если 'вдруг', то будет, например, exception - там в обработчине и посмотрите а хватило-ли стека?

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