Добрый день!

Озадачился тут оптимизацией памяти. Ну во-первых, уменьшил количество одновременно запущенных задач до реального значения
Во-вторых, хочу оптимизировать размер стека

После компиляции я могу посмотреть в отчетах, например, что-то вроде такого:


отлично. Закладываю 400 байт... и вылетаю в Stack Overflow

Запускаю симулятор. Все там прекрасно бегает, разумеется, как только использование printf - так сразу стек "подскакивает"
Но смотреть пошагово - неудобно, да и не всегда отобразится полная картина.
Можно ли как-то промориторить пиковые значения мспользования стека каждой задачей?
В Debug->OS Support я не нашел. Возможно, еще где-то есть такая возможность?

Заполнить стек чем нибудь определённым и не равным 0.
Дать поработать достаточно долгое время, остановить и посмотреть сколько использовано.

тоже вариянт! попробую, спасибо

upd

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

в общем, я так понимаю, довольно сложно будет точно определить самому. Только если нет штатных инструментов так что пока - чистое шаманство

0xFF - это, мягко говоря, не самый удачный вариант. Заполните каким-нибудь паттерном подлиннее и посложнее (0xdeadbeef, например).

попробовал... картина та же
кстати, стек инициализируется 0x00, так что паттерн особой роли не играет - обращения все равно в диапазон 0x0xxxxxxx (flash) или 0x4xxxxxxx (RAM), 0xFFFFFFFF видно все равно
ну не суть

Может в этом ошибка: заполнять нужно не всё - задача должна запускаться с определёнными значаниями (и наверняка не с FF). То есть заполнить нужно ту часть которую задача ещё не использовала.
SP_tast_init_value-SP_min_value байт начиная от SP_start_value-1.


Точно.

Тогда увеличивайте стек, чтобы наверняка ухватить конец. Очень может быть, что его уже не хватает,
просто это пока не проявляется. "Дырки" вполне могут возникать при работе *scanf.

Ещё вариант. Использовать MPU (если такое возможно): при запуске задачи перенастраивать его на новый стек.
Но такое сам не пробовал.

точно, в основном в там и проявляется явно. Но эта задача запускается только в одном режиме, в котором все остальные задачи не поднимаются
Для нее был вообще выделен свой стек, на чем и смотрю

Но иногда в задачах, которые уж точно тупо принимают пакет, отдают ответ и также тупо ходят по машине, тоже бывает глюк. После увеличения стека пропало


задача, по идее, запускается в двух вариантах - со стеком, выделяемым системой, или со стеком, определяемым пользователем.
Вот я и хочу уйти от огульного выделения каждой задаче одинакового количества оперативки
Но сейчас копаю исходники - разобраться в ихнем менеджере памяти пока туго
upd
MPU там нет

а в IARосвком отладчике есть какой то монитор стека, даже брекпоинт хавает, его поэтому отключаю все время.

Если у вас в каком-то режиме работает только одна задача, то это уже не многозадачность и соответственно - либо стек этой задачи можно наложить
на другие стеки (union), либо - ещё лучше - организовать работу так, чтобы другая задача, которая в это время стоит, выполняла функции данной
задачи и уменьшить кол-во задач на 1. Вот вам и экономия памяти.
А насчёт стеков - правильно вам посоветовали - увеличивайте стек до тех пор пока глюки не пропадут, потом ищите дырки в шаблоне заполнения -
стандартный способ. И естестно - шаблон не 0 и не 0xFF должен быть.
printf часто много памяти жрёт (зависит от используемой библиотеки). Я, для уменьшения расхода памяти, использую переключение стека - перед
вызовом printf переключаю SP на стек, выделенный специально для printf и защищаю это дело семафором естесно.
Например: ARM9+CCS3.3 - закладываю под отдельный стек == 136*4 байт + размер под контекст, сохраняемый ОС при переключении задач
(на моей ОС uCOS - ещё 18*4 байт). Хватает.