MSP430FR4133 LPM, Прошу помощи Опции

[SasaVitebsk]

Очень редкие проекты у меня на MSP. А с режимами сна вообще дел не имел.
Немного повозился - понял, что там вообще свой подход к написанию проектов нужен. А он у меня не выработан. ((
Короче проект маленький. ОС не нужна не разу. Потребление - основное.
Периферии много задействовано. 3 ноги (прерывания), RTC, LCD, 2 таймера, ADC, USART и I2C. На постоянку только ноги, LCD и RTC. То есть LPM3.5.
Остальная периферия запускается разово. По даташиту на МК нашёл табл. 6-1 "Operating Modes (continued)", где указано что I2C и UART работают только в LPM0 (собственно эти узлы тактируются только SMCLK).
Остальная периферия может спать в LPM3.
Я сейчас в ячейке храню битовый список запущенных узлов. Чтобы знать в какой именно режим сна я имею возможность войти. Но у мне не совсем понятно с выходом из сна.
Приведу пример.
Я работаю с усартом. То есть нахожусь в LPM0. Тут приходит прерывание от ножки (геркон) я просыпаюсь выполняю работу запускаю таймер для задержки на дребезг и надо выйти в голову. То есть выйти из LPM0.
Но если я не работаю с UART, то мне надо выходить из прерывания по LPM3.
И я что-то недогоняю. Достаточно ли мне сделать __bic_SR_register_on_exit(LPM3_bits) и это решит проблему в обоих случаях. Или мне требуется анализировать из какого режима я попал в прерывание?

[SasaVitebsk]

Прошу прощения. Просто сформулировать грамотно не могу.
Написал проект. В отладчике он работает. Если режимы сна отрубить - тоже. В готовом изделии - не хочет.
Особенность проекта (хотя я просто наверняка неправильно изначально его спроектировал) в том, что надо менять режимы сна.
Например. Спим в LPM3.5. Приходит прерывание от RTC, обрабатывается и, например раз в сутки надо замерить текущую температуру.
Для этого надо выйти из прерывания со сбросом режима сна подать питание на датчик температуры, зарядить таймаут на таймер 0 и заснуть уже в режиме LPM3.
Потому что если я засну в режиме 3.5, то таймер идёт лесом. Теоретически может одновременно придти несколько прерываний. В которых потребуется разная периферия и, соответственно, мне надо заснуть в таком режиме чтобы вся эта периферия работала.
Как выглядит типовой проект в таком случае? Я сейчас просто выделил байт в BACKMEM где храню флаги рабочей на данный момент периферии. И при засыпании анализирую этот байт.
Но похоже - что-то не так.

[jcxz]

Например. Спим в LPM3.5. Приходит прерывание от RTC, обрабатывается и, например раз в сутки надо замерить текущую температуру.
Для этого надо выйти из прерывания со сбросом режима сна подать питание на датчик температуры, зарядить таймаут на таймер 0 и заснуть уже в режиме LPM3.

Если у Вас МК вошёл в ISR, то естественно он уже не режиме сна, а в run-mode находится. Как это может быть непонятно??
Как всегда - у вопрошающего каша в голове...
И по выходу из ISR, можно вернуться в сон или продолжить выполнение фонового процесса с инструкции, следующей после той инструкции, что погрузила в сон.
Т.е. - именно инструкция выхода из прерывания, загружает значение в статусный регистр МК, содержащий биты сна.
Атомарный вход в сон:

Код

    __bic_SR_register(GIE);
    if (!(mainFL & (1 << MAIN_F_TASK_MEASURE | 1 << MAIN_F_TASK_RX)))
      if (keyboard == KBD_NONE) {
      mainFL |= 1 << MAIN_F_SLEEP;
      __bis_SR_register(LPM3 | GIE);
      __bic_SR_register(GIE);
    }
    mainFL &= ~(1 << MAIN_F_SLEEP);
    __bis_SR_register(GIE);

В mainFL содержатся флаги-требования обработки некоторых событий (MAIN_F_TASK_RX, MAIN_F_TASK_MEASURE). Эти флаги выставляются в ISR-ах (которые могут срабатывать в режимах сна, пробуждая МК, или в run-mode, если уже идёт какая-то обработка одного из событий).
После этого участка идёт код проверяющий эти флаги и обслуживающий их.
Есть также флаг MAIN_F_SLEEP - по нему ISR-ы определяют из какого режима они вызвались (если им это нужно).

То есть получается в голове совсем проги не должно быть. Как у них в примерах.

Неправильно. Основную обработку лучше располагать в фоновом процессе.
Активация фонового процесса: срабатывает ISR, выставляет флаг в переменной запросов сервисов фонового процесса, выходит из ISR в run-mode.
Фоновый процесс построен в виде большого цикла - просматривает поочередно флаги в переменной запросов, если какой-то установлен - сбрасывает его и выполняет сервис, дальше - опять анализ переменной запросов.
Если переменная запросов ==0 - вход в сон.
Весь цикл:

Код

enum {MAIN_F_SLEEP, MAIN_F_TASK_MEASURE, MAIN_F_TASK_RX, ...};

while (1) {
  __bic_SR_register(GIE);
  if (!(mainFL & (1 << MAIN_F_TASK_MEASURE | 1 << MAIN_F_TASK_RX | ...))) {
    mainFL |= 1 << MAIN_F_SLEEP;
    __bis_SR_register(LPM3 | GIE);
    __bic_SR_register(GIE);
  }
  mainFL &= ~(1 << MAIN_F_SLEEP);
  __bis_SR_register(GIE);
  do {
    if (mainFL & 1 << MAIN_F_TASK_MEASURE) {
      __bic_SR_register(GIE);
      mainFL &= ~(1 << MAIN_F_TASK_MEASURE);
      __bis_SR_register(GIE);
      ... //сервис MAIN_F_TASK_MEASURE
    }
    if (mainFL & 1 << MAIN_F_TASK_RX) {
      __bic_SR_register(GIE);
      mainFL &= ~(1 << MAIN_F_TASK_RX);
      __bis_SR_register(GIE);
      ... //сервис MAIN_F_TASK_RX
    }
    ... //другие сервисы
  } while (mainFL & (1 << MAIN_F_TASK_MEASURE | 1 << MAIN_F_TASK_RX | ...));
}

В принципе, возможно запреты прерываний при модификации флагов mainFL возможно излишни, так как IAR эти операции генерит в виде одной инструкции чтения-модификации-записи (которая атомарна, как я понимаю, для контроллера прерываний).