Что то читал, читал эту ветку и так и не понял как определить хватает места программе для стека или нет.
Вот например (IAR AVR) изначально по умолчанию 0x20 явно не хватало, шли сбои, увеличил до 0x44
вот последние строчки из MAP

во вложении скриншот memory data после работы программы

Как понять сейчас хватает программе этого размера?
Какой минимум можно оставить для CSTACK?



Сообщение отредактировал Ga_ry - Nov 25 2015, 19:31

делаете три вещи
1) при выделении стэка расписываете магическим числом всю память под стэк.
2) в определённые срезы времени проверяете сколько памяти осталось расписанной вашим магическим числом(например при переключении задач, если ось)
3) скидываете каждые изменения размеров остатков стэков в лог

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

Понятно.
Вот только логи мне писать некуда, 8к почти под завязку (20 байт осталось) т.е. код для формир. лога вставить тоже некуда. Ноги МК тоже, НИ ОДНОЙ свободной.
Брать контроллер с большей памятью, отладку делать на нем?

А вот это изначальное заполнение FF не пойдет для магического числа?

Спасибо!

Помогло так:

#pragma segment = "NEAR_ID" __farflash
void __farflash * pNEAR_ID_end = __segment_end("NEAR_ID");




Обычно там 00. Можно в прерывании по таймеру или кнопке искать адрес первого ненулевого байта.

Странно, в скриншоте, который прикреплен, видно FF

20 байт - можно использовать для многого под отладчиком для просмотра/контроля - вполне.
а вот FF - тут дело такое. для скорости проверки необходимо брать всю разрядность шины данных. т.е. если у вас используются 32 разрядный мк -
то это уже 4 байта за раз можно писать/тестировать/сравнивать...

нолик 0x00 как и минус один(в стандарте сей) 0xFF чаще встречается чем какие-либо другие комбинации.

kolobok0, а зачем надо умножать на два?

а разве DEADBEEF не помогает - или религия запрещает ?
проблема из пальца выдуманная

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

Этот Ваш стиль надменно-пренебрежительный это врожденное или приобретенное?
Ссылку дайте, я первый раз слышу о таком.

В ОС (из-за многостековости) имеются "включаемые" режимы контроля размера стек(ов).
Алгоритм тот что указан выше.

freeRTOS: