Допустим есть такой код:

Массив cmd[] компилятор размещает в стеке. Затем его адрес присваивается другой переменной и она с ним как-то работает, причем эта переменная используется в прерывании. В связи с этим возникает вопрос: можно ли быть уверенным, что положение этого массива в ОЗУ (его абсолютный адрес) не изменится? Разумеется, при условии что из функции мы еще не вышли. Не может ли в процессе выполнения функции он как-то двигаться? Дело в том, что в таком виде наблюдались необъяснимые глюки, которые исчезли как только я объявил этот массив static. Но они и раньше иногда исчезали, поэтому нет уверенности, что их вылечил именно static.

не должен.
но!
1) надо убедиться, что Вы адресуетесь _именно_к_нему_ а не по указателю на деревню бабушке.
2) (маловероятно)соглашение об очистке стэка в вызываемых подпрограммах соблюдено.
3) не происходит выхода за его размерность, при работе с ним.
4) само значение указателя ссылающегося на него не меняется

все эти случаи отсекаются под низкоуровневым дебагом. либо мало инфы привели.

(круглый)

Как вы себе представляете "движения" стека? Это вообще-то довольно нетривиальная задача сдвинуть в памяти десяток переменных разного типа, и уж тем более это задача не для АВР, и конечно-же такого ни один компилятор не делает сам. Гораздо более вероятна ошибка программиста, т.е. все 4 выше приведенных пункта.

Или стек переполнился, что тоже ошибка программиста.
Или прерывание сработало после того, как программа покинула функцию.


Оооо! Какой моветон.

Это еще почему? Некая функция хочет послать данные по I2C. Для этого нужно указатель I2C установить на буфер из которого будут передаваться данные. Этот буфер находится в функции, поэтому создается на стеке. Ну а передаваться они, естественно, будут по прерываниям. Какие проблемы?

А не проще заполнить статический буфер, дать обработчику ссылку на начало и длину и спокойно заниматься своими делами?

Надо оставаться в функции до завершения работы прерываний. Зачем тогда прерывания?
Есть еще один тонкий момент - вы объявили буфер без volatile, поэтому если во время, пока прерывание работает с буфером функция занимается чем-то еще кроме ожидания, компилятор вполне может расположить на месте этого буфера какие-то использующиеся дальше локальные переменные, ведь с его точки зрения функция уже закончила работу с буфером и он ей больше не нужен. Более того, компилятор вправе выкинуть этот буфер и его заполнение вообще, ведь занесенные в не-volatile буфер данные дальше не используются.

А "свои дела" как раз и заключаются в том, чтобы опросить несколько модулей по I2C и передать с них информацию дальше. Поэтому пока она передается, делать все равно нечего, нужно стоять и ждать.


Обработчик прерываний ничего не знает о буферах, он работает с переменной pTWI, а она volatile. И вообще, я уже сделал буфер static, но это не помогло, глюки продолжаются, так что вопрос снимается.

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

Спасибо, кэп!

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


(круглый)

Сообщение отредактировал kolobok0 - Oct 5 2010, 16:50

Да при чем тут обработчик? Функция не знает, что этот буфер еще кому-то нужен, пусть на него хоть 10 volatile-указателей указывают.

все дело в волшебном словечке volatile

Программист, запомни!
Если ТЫ используешь прерывания и разделяемые переменные,
То обязательно напиши это волшебное слово volatile.
И прибудет тогда с тобой сила!

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

Это я писал в сообщении №7. Тут попытался упростить.