Размер стека Опции

[d7d1cd]

Привет всем. Подскажите, размер памяти, выделяемой под стек, в устройствах MSP430 всегда одинаков или все зависит от компилятора?

[_Артём_]

Подскажите, размер памяти, выделяемой под стек, в устройствах MSP430 всегда одинаков или все зависит от компилятора?

Размер как правило определяется в каждом проекте, за исключением случая когда стек аппаратный.

[d7d1cd]

Размер как правило определяется в каждом проекте, за исключением случая когда стек аппаратный.

Тогда два вопроса.

1. В каких устройствах MSP430 стек аппаратный?

2. Как может быть определен размер стека, если я, например, в своем проекте использую рекурсивную функцию? Заранее нельзя сказать сколько раз она будет вызвана и, соответственно, выделить под стек необходимое количество памяти.

[_Артём_]

1. В каких устройствах MSP430 стек аппаратный?

ДУмаю, что в MSP430 аппаратный стек не использовался.
Такой стек использовался например в PIC-ах.

2. Как может быть определен размер стека, если я, например, в своем проекте использую рекурсивную функцию? Заранее нельзя сказать сколько раз она будет вызвана и, соответственно, выделить под стек необходимое количество памяти.

Глубина вызовов не может быть больше, чем размер стека - работать перестанет.
Выбирите максимально возможное значение глубины вызовов и задайте стек в соответствии с ним.

[d7d1cd]

Глубина вызовов не может быть больше, чем размер стека - работать перестанет.Выбирите максимально возможное значение глубины вызовов и задайте стек в соответствии с ним.

Возможно мы не поняли друг друга. Я сам задаю размер стека?

[rezident]

Возможно мы не поняли друг друга. Я сам задаю размер стека?

Размер стека это абстрактная величина, определяемая программистом для компилятора. Потому, что в MSP430 аппаратный лишь сам указатель стека. Размер стека никак аппаратно не задается и не контролируется. "Наползание" стека на область статических/глобальных данных это самая трудновыявляемая ошибка в программировании. Компилятор может немного помочь в определении этого момента, но не всегда и с вероятностью, сильно отличающейся от 100%. Тем более он этого не может, когда идут рекурсивные вызовы в прерываниях, которые компилятор спрогнозировать вообще не в силах. Используйте программные ухищрения, типа счетчика рекурсии.

Код

#define MAX_NESTED_VALUE   5    //максимальное значение уровня вложенности прерываний
#pragma vector=TIMERB0_VECTOR
#pragma type_attribute=__interrupt
void TIMERB0_ISR(void)
{ static unsigned int cntr_nested=0;
  cntr_nested++; //инкремент счетчика вложенности прерываний
  if (cntr_nested < MAX_NESTED_VALUE) //проверяем уровень вложенности, если он меньше допустимого, то выполняем какие-то действия
  {

    ... //выполняем какие-то действия, необходимые до вложенных прерываний

    __enable_interrupt(); //разрешаем прерывания, в т.ч. вложенные

    ... //выполняем какие-то действия

  }
  --cntr_nested; //декремент счетчика вложенности прерываний
}

[_Артём_]

Код

#define MAX_NESTED_VALUE   5    //максимальное значение уровня вложенности прерываний
#pragma vector=TIMERB0_VECTOR
#pragma type_attribute=__interrupt
void TIMERB0_ISR(void)
{ static unsigned int cntr_nested=0;
  cntr_nested++; //инкремент счетчика вложенности прерываний
  if (cntr_nested < MAX_NESTED_VALUE) //проверяем уровень вложенности, если он меньше допустимого, то выполняем какие-то действия
  {

    ... //выполняем какие-то действия, необходимые до вложенных прерываний

    __enable_interrupt(); //разрешаем прерывания, в т.ч. вложенные

    ... //выполняем какие-то действия

  }
  --cntr_nested; //декремент счетчика вложенности прерываний
}

Зачем cntr_nested объявлена как static, а не как глобальная?
Это подсчёт вложенности одного и того же прерывания? Не лучше ли на входе прерывания делать запрет вызова, а на выходе опять разрешать?

[rezident]

Зачем cntr_nested объявлена как static, а не как глобальная?

Чтобы зря не "засирать" namespace

Это подсчёт вложенности одного и того же прерывания?

Конечно. Ведь переменная имеет область видимости и изменяется только внутри данной конкретной функции обработки прерывания.

Не лучше ли на входе прерывания делать запрет вызова, а на выходе опять разрешать?

Данный вопрос свидетельствует о том, что вы слабо знакомы с системой прерываний MSP430. При переходе по вектору прерывания сохраняется состояние регистра SR (на стеке), затем флаг GIE (Global Interrupt Enable - глобальное разрешение маскируемых прерываний), входящий в состав этого регистра, сбрасывается (точнее сбрасывается состояние всего статусного регистра SR) и таким образом вложенные прерывания автоматически запрещаются. Так что отдельно запрещать прерывания непосредственно в функции обработки прерывания не требуется. Если вам нужны вложенные прерывания, то в обработчике прерывания их можно разрешить (установив бит GIE). Естественно, что при выходе из прерывания состояние регистра SR (и бита GIE) восстанавливается.

[_Артём_]

Чтобы зря не "засирать" namespace

Ну если так...то понятно.

Конечно. Ведь переменная имеет область видимости и изменяется только внутри данной конкретной функции обработки прерывания.

Мне как-то трудно представить, зачем допускать ситуацию, когда вложенность одного и того же прерывания больше 1. Разрешить работать другим прерываниям - понятно, а так - не очень.

Данный вопрос свидетельствует о том, что вы слабо знакомы с системой прерываний MSP430.

Я их даже не видел ни разу.

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

Обычно так и делаю (на АВР правда, но какая разница). Но перед этим запрещаю тот обработчик, который выполняется в текущий момент.

[Steve Key]

Мне как-то трудно представить, зачем допускать ситуацию, когда вложенность одного и того же прерывания больше 1.

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

[zhevak]

Реентерабебльность (от re-enter -- повторный вход) -- это, конечно, хорошо! Но всему должна быть мера.

Реентерабельность обычных функций (не обработчиков прерываний) -- это нормальное явление. Хотя оно и требует к себе повышенного внимания. То есть вполне допустимо, если вы понимаете, что вы делаете, и что на самом деле у вас в системе происходит.

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

Вообще реентерабельность прерываний подразумевает то, что прерывания разбиты на несколько уровней -- по приоритетам. Более приоритетные прерывания имеют право прерывать работу обработчиков прерываний с более низким приоритетом. (Блин, ну и тавтология. Сам поражаюсь!) Реентерабельность прерываний -- это вынужденная мера. Это нужно делать только тогда, когда другими способами не удается разрулить работу системы (девайса). По возможности нужно избегать реентерабельности прерываний.

Если реентерабельность прерываний одного уровня -- очень и очень сомнительна (это явно не от великого ума), то реентерабелность одного прерывания -- это мега-зло!

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

Во всех остальных случаях, следует придерживаться следующей логики. Из нескольких, одновременно возникших в системе событий мы должны создать очередь, и последовательно их обработать. Например, одновременно пришедшие события от клавиатуры, мышки и RS485, могут быть обработаны в ЛЮБОМ порядке относительно друг друга. Собственно, порядок их обработки может быть легко измениться, если какое-то событие возникнет на мгновение раньше другого. Невозможно учесть абсолютно все жизненные ситуации, поэтому проще считать, что

"мы будем бороться с проблемами в порядке их возникновения" (с) не помню чье высказывание

Вообще это очень большая тема и конкретное решение по реентерабельности прерываний нужно рассматривать не абстрактно, а применительно и конкретно.