Может ли меняться адрес переменной в стеке? Опции

[777777]

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

Код

bool ModulesInit(uint8_t mn)
    {
    uint8_t cmd[3] = { 8, mn, 0 };

    pTWI = cmd;
    // ...

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

[GDI]

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

[IgorKossak]

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

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

Массив cmd[] компилятор размещает в стеке. Затем его адрес присваивается другой переменной и она с ним как-то работает, причем эта переменная используется в прерывании.

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

[777777]

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

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

[MrYuran]

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

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

[777777]

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

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

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

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

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

Обработчик прерываний ничего не знает о буферах, он работает с переменной pTWI, а она volatile.

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

[halfdoom]

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

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

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

Точнее, _компилятор_ не знает,

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