Добрый день. Пишу программу на С для Attiny25. Результат моделирования в Proteus'e таков: несколько секунд все идет нормально, потом моделирование останавливается, появляется ошибка - Pop Program stack: SP is not initialized. Насколько я понимаю, в этот момент переполняется стек. Подскажите, каким образом выйти из этой ситуации?

Я не знаю, что у вас за адача, но если она не запредельно тяжела для вашего МК, то можно попробовать вот что.
Увеличить стек. Отказаться от использования рекурсии (если используете) ...

Сообщение отредактировал kovigor - Sep 29 2011, 13:35

рекурсии не использую. а как увеличить стек?

А прерывания используете ?
Стек можно увеличить в настройках проекта через меню вашей среды разработки. Откройте проект и пройдитесь по меню ...

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

Интересное решение проблемы. Особенно если учесть, что убрав массив из стека, ты поместил его в RAM, в котором и находится стек. Как же его стало хватать?

Очевидно потому что не хватало конкретно стека, а не рамы.

В массив в прерывании Вы, по-видимому, что-то пишете, поэтому не забудьте объявить его volatile.

Зачем массив далать volatile?
Раньше он объявлялся как локальная переменная.
Значит использовался только в прерывании.
И следовательно volatile не нужен.

volatile можно ставить на семафор взводимый в прерывании, который говорит о том, что данные поменялись, но никак не на сами данные - иначе это равносильно тотальному отключению оптимизации.

Это не столь очевидно. Стек находится в RAM-е, у него нет отдельного пространства. И если ты перенесешь массив из стека и сделаешь глобальной переменной, то свободного места в ОЗУ обльше не станет.

Наверно его стоило сделать не глобальным, а статическим. Изменится мало что, но ненужной видимости снаружи не будет.

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

Спорно. Спорили тут полтора года назад: http://electronix.ru/forum/index.php?s=&am...st&p=747603. С наступлением эры LTO (link-time optimization) в gcc может стать чертовски актуально.

Если насчет "head" я могу согласиться, то насчет записи в буфер уж никак нет. У компилятора нет повода менять действия местами - так как разрешение прерываний есть volatile операция:

# define sei() __asm__ __volatile__ ("sei" :: )

Можно ее считать программным data sync barrier'ом. Volatile на асм инструкцию однозначно указывает компилятору, что все действия описанные до этой инструкции должны быть завершены. Если была запись в буфер, то компилятор не имеет право отложить ее за пределы volatile инструкции. В то же время объявив данные буфера как volatile, Вы мешаете компилятору отложить запись до удобного момента. Что это за удобный момент, - например, до разрешения прерываний в буфер может быть положено что-то еще, и на ARM логично было бы сгруппировать все записи в одну burst инструкцию. Так вероятно и поступил бы компилятор, не объяви Вы каждое слово сторейджа как volatile.

Ниже привожу функцию:



Я лично на 100% уверен, что действие "read_something_not_critical_and_slow" произойдет строго до запрета прерываний, а действие "read_something_critical_fast" произойдет строго после запрета прерываний. Если какой-то оптимизатор соптимизирует иначе, то он ничего не соображает в оптимизации. Так откуда же взялись сомнения насчет записи в буфер?


Вы сталкивались с системами где RAM access time >50 clk для одно-тактового CPU? (для систем с DRAM это типично)
пара лишних volatile может стоит >50% ресурсов проца.

Этот момент для меня не совсем ясен. Надо обдумать. В той ветке ReAl приводил пример, когда такая инструкция не мешала перенести запись в не-volatile переменную. И я не готов ответить, кто прав в этом случае - вы или компилятор.
Боюсь, с учетом сказанного выше, на данный момент не существует способа объяснить компилятору допустимость этого.

Я, напротив, на 100% уверен, что компилятор может сделать иначе и с оптимизацией у него все в порядке. Если тело этих read_... ему доступно и оно не имеет побочных эффектов - то имеет полное право.

Нет, не сталкивался. И точно также как и вы против использования лишних volatile. Мы лишь расходимся в критериях опредения, который именно считать лишним.