[zombi 0]

Нужно выделить область под стек.

Много - жалко памяти.

Мало ...

Посчитать все возможные прерывания и pushы я просто не в состоянии.

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

Может существуют еще какие либо методы выбора оптимального размера стека?

[prottoss 0]

1. Заполните стек каким либо "магическим" числом.

2. Запустите программу и постарайтесь прогнать ее на всех возможных вариантах.

3. Проанализируйте стек.

 

В итоге будете видеть, на какую максимальную глубину может быть заполнить стек.

[zombi 0]

постарайтесь прогнать ее на всех возможных вариантах.

Вот со всеми вариантами то и проблема.

Уже сейчас это практически не реально.

А в дальнейшем ещё будут измения, добавления и т.д.

 

[maksimp 0]

Нужно выделить область под стек.

Много - жалко памяти.

Мало ...

Для чего нужна память? Ответ - для стека и для статических переменных. Использовать malloc на микроконтроллере не следует.

Отводите для стека много памяти. Если слишком много отвели, то не хватит места для статических переменных и компилятор должен выдать ошибку (не уверен, не проверял, проверьте).

[zombi 0]

и компилятор должен выдать ошибку (не уверен, не проверял, проверьте).

Ну avrasm так точно ругаться не будет

[Petka 0]

Нужно выделить область под стек.

Много - жалко памяти.

Мало ...

Посчитать все возможные прерывания и pushы я просто не в состоянии.

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

Может существуют еще какие либо методы выбора оптимального размера стека?

Используйте GCC. В нём куча растёт "вверх", а стек "вниз" с вершины памяти. Размер стека вообще указывать не надо.

[Johnny81 0]

Используйте GCC. В нём куча растёт "вверх", а стек "вниз" с вершины памяти. Размер стека вообще указывать не надо.

 

Плюсы не велики. Если стек переполнится - будут ровно те же проблемы :)

 

Автору

1. (Для ИАРа) Выделяешь под стек максимально возможный объем - если вдруг не велезешь в память - будет ошибка линковки

2. На верх стека пишешь магическое число (для ИАРа - на оба стека), периодически проверяешь, если проблема - выдаешь ошибку, перезагружаешься

3. (Для ИАРа) в map-файле есть расчет размера стека. Правда он весьма примерный, так как ничего не знает про то, какие прерывания могут у тебя "вкладываться", а какие - нет.

 

[Сергей Борщ 119]

Плюсы не велики. Если стек переполнится - будут ровно те же проблемы :)

Если стек переполнится в этом случае - то никакое указание размера стека другими способами уже не поможет. Это будет означать, что память кончилась вся. Совсем.

 

1. (Для ИАРа) Выделяешь под стек максимально возможный объем - если вдруг не велезешь в память - будет ошибка линковки

Там два стека. И можно поступить тем же образом, что и в gcc - исправив скрипт линкера заставить размещать стеки с конца. Причем в самом конце разместить стек возвратов (RSTACK), размер которого можно приблизительно оценить прикинув количество уровней вложенности подпрограмм и дав запас, скажем, 10-20 байт, а следом, ближе к началу памяти, разместить стек данных (CSTACK), вершина которого может безболезненно расти за пределы выделенной под CSTACK память до тех пор, пока не налезет на другие данные, т.е. пока физически есть свободная память. Можно указать размер CSTACK равный 0 и забыть про это. А уж если начнутся проблемы с переполнением - оптимизировать алгоритмы.

Делается это использованием символа '#' вместо '=' в определении сегментов и размещением определения RSTACK перед CSTACK:

-Z(DATA)RSTACK+_..X_RSTACK_SIZE#60-45F
-Z(DATA)CSTACK+_..X_CSTACK_SIZE#60-45F

2. На верх стека пишешь магическое число (для ИАРа - на оба стека), периодически проверяешь, если проблема - выдаешь ошибку, перезагружаешься

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

[zombi 0]

Какие ИАРы какие GCC ? Я на ассемблере всё пишу.

 

Ясно одно: идеального метода нет.

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

И в самом частом и самом высокоприоритетном прерывании оставил анализ указателя чтобы в случае чего остановить всё с рааадостным сообшением "stack overflow"

[Petka 0]

Какие ИАРы какие GCC ? Я на ассемблере всё пишу.

....

Если пишете на асме, то тем более можете стек растить "вниз".

[Johnny81 0]

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

 

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

 

[Сергей Борщ 119]

Понятно, что это не слишком точно, но как оценка - вполне работает.

Безусловно.

 

[prottoss 0]

Я забил магическими числами весь стек

Еще есть способ забивать стек не константой а последовательностью. Т.е magic++. Это более помогает при том, о чем говорил Сергей Борщ

[kolobok0 0]

...на ассемблере всё...

 

тогда проблем вроде как и нет.

направления решений

1) резервация под существующий код.

2) контроль за аварийностью, при выходе стэка куда ему не положено.

 

резервация - методы следующие.

1) посмотреть "след" от использования стэка. методы написаны выше.

2) прикинуть мысленно глубину поллинга и(или) глубину прерываний. умножить на 1,5 или 2

 

контроль за аварийностью (как способ вовремя закричать, что _ВНИМАНИЕ_ ышо работаем но уже тогось!!!) лучше делать на "постоянно" используемых функциях. типа выделение памяти или в цикле главной логики, как контроль за общими ошибками. при этом достаточно выставлять признак "всё плохо со стэком" и далее его считывать по мере опроса "старшим братом" или при выводе в юай.

 

[zombi 0]

направления решений ...

Вот уже лет 20 как так и делаю.

Думал за это время кто что новое придумал.

Ан нет, всё по старому.