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

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

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

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

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

Интересное решение проблемы. Особенно если учесть, что убрав массив из стека, ты поместил его в 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. Мы лишь расходимся в критериях опредения, который именно считать лишним.

Значит фтопку такой компилятор. Побочный эффект - прерывания будут запрещены дольше чем требуется либо не тогда когда нужно! Volatile инструкция как раз и указывает компилятору на то, что изменение порядка следования действий влечет к непредсказуемому результату.

Допустим компилятор видит, что расчет переменной "a" состоит из расчета переменной "b" плюс какие-то длительные дополнительные действия. Пусть эффективность функции "foo" будет выше если вначале расчитать значение переменной "b", а затем значение переменной "a". Но увеличив эффективность функции можно убить эффективность/функциональность всей системы, если поменяется порядок следования volatile инструкции. (я не зря в примере нарисовал всего три действия, перестановка расчета любой из переменных - выглядит как перестановка запрета прерываний)!

Если вдруг заметите, что gcc при каких-то опциях оптимизации меняет порядок следования volatile инструкции, - стоит репортить баг и пусть фиксят компилятор. И нам дайте знать в какой версии такое имеет место быть, чтобы ее не пользовать! )


Очень жаль, что они тогда оптимизируют в gcc непонятно. burst инструкция (STRM) при работе с DDR/SDRAM будет до 8 крат быстрее в сравнении с одиночными STR.

volatile как раз говорит о побочном эффекте. Я же написал - если содержимое этих функций не имеет побочных эффектов. И если в этих функциях нет volatile и нет вызова внешних функций - компилятор имеет право. А volatile вы сами рекомендуете в них убрать.

Так-с
Расставим точки над i. Вот ваша цитата:


Я утверждаю - не должен он быть volatile, и рекомендую буфер и его элементы НЕ обьявлять как volatile. Пусть компилятор оптимизирует запись и обращения к буферу.

Потому что разрешение прерывания - есть volatile инструкция, и компилятор ни при каких условиях (если в нем нет багов) не имеет права изменять ее порядок появления в коде. Он не может перенести запись после разрешения прерываний как вы говорите, т.к. поменяется порядок volatile инструкции "sei". Кстати команда "RETI" в GCC также объявлена как volatile, поэтому сделать запись в буфер после выхода из обработчика прерывания компилятор тоже не имеет права.

Компилятор может лишь только вообще не писать в буфер, если обращений к нему больше нигде нет, но порядок следования команд, запись -> разрешение прерываний, на другой, он поменять не может!..

Вы не правы - он не может изменить ее порядок относительно других volatile-инструкций (или выражений с побочными эффектами). В противном случае он обязан был бы перед этой инструкцией выгрузить в ОЗУ содержимое всех регистров, в которых закешированы любые переменные. Но этого не происходит - достаточно посмотреть листинг. А вот если мы буфер сделаем volatile - он уже будет обязан сгрузить его в ОЗУ перед sei.

Мне кажется в этом вы ошибаетесь. Обратите внимание на пример ReAl в конце сообщения №36 той ветки.

Много всего написал, потом удалил, потому как не хочу втягиваться в бесконечный спор.
Оставлю только выжимку.
1. Компилятор не должен скидывать временные адреса/индексы, не должен скидывать автоматические переменные и т.д. Скидывать требуется ровно то что требуется, - переменную (или группу переменных) которая находится в защищенном блоке из volatile инструкций.
2. Примеры ReAl'а на мой взгляд непоказательны, в первый вставьте printf("%d",i); и всё станет на свои места, во втором - баг определенной одной версии компилятора.
3. Кто прав, кто неправ рассудит время. Если уж совсем по логике, - volatile перед переменной нужен только для тех переменных, которые не на 100% контроллируются кодом "видимым" компилятору, - а именно, изменяются другой программой, другим процессом, процессором, аппаратным/периферийным модулем. Переменные же которые изменяются кодом который компилятор генерит (в пределах одной программы), в т.ч. и изменяемые в прерываниях, - должны четко обрабатываться и без volatile.

PS: а почему же в той ветке нет продолжения? Никто на последний пост zltigo не ответил. За полтора года так и не удалось найти компилятор который бы выносил запись в буфер за пределы sei()? Стало быть вот и доказательство того, что таких компиляторов нет.

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

Да никто просто не искал. Я, например, использую volatile и спокоен, что подобного выноса не будет. Не использовать volatile рискуя нарваться на грабли ради того, чтобы найти такой компилятор как-то желания не возникает. Потому ветка и заглохла. И эта заглохнет.

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

А вот способ выкинуть потребность в volatile - работать по указателю: