Ну, дык, заблокировать и его, ежели он не нужен и мешает.

Это понятно, когда будить можно по внешнему событию, но кому тогда сказать разбудить, например, через сутки ? Придется делать нечто софтовое или аппаратное позволяющее формировать большие временные интервалы с минимальными затратами энергии.

А динамически период системного тика нельзя менять?

Естественно можно, еще можно его обработчик (если формируемого интервала не хватит) на максимально короткий на время сна заменить. Это то, что я имел ввиду под софтовым решением. Можно добавить RTC c будильником и к режимам сна подвязать....

Приветствую.
Не буду создавать отдельную тему, тут напишу. Читал обе темы про слип режим в контексте МСП430 и даже вроде поучаствовал как-то, но появился новый ракурс проблемы.
Все понятно если тип слип режима один, например LPM0. Но что делать, если в зависимости от ситуации тип режима должен меняться?
Например, мой случай. Прибор работает условно в двух режимах, покоя и работы. В покое прибор ничего не делает, просто ждет нажатия кнопки. Его задача потреблять как можно меньше. В режиме работы есть обмен по УАРТ, запись на СД карту и пр. дела, в перерывах между которыми неплохо бы поспать.
Однако, реализовать сон можно тут по-разному. В первом случае можно делать LPM3, и тактироваться от часового кварца. Для периодического опроса кнопки 32 кГц хватит, а периферия не нужна. В режиме работы LPM3 не годится ибо нельзя снимать клоки с УАРТ и пр. поэтому только LPM0.
Проблема вот в чем. Просто поставить if в зависимости от режима в IdleProcessUserHook нельзя. Ведь в каждой из задач ОС при восстановлении контекста восстанавливается и статусный регистр, а в нем информация о работе/не работе FLL. Соответственно при смене режима с покоя на рабочий и включив FLL сей факт запишется только в статусный регистр контекста текущего процесса, а в другие процессы как??? Хакерскими способами не очень хорошо. Кто-нибудь сталкивался с подобной проблемой? Как решали?
Спасибо.

Тогда можно загнать в LPM4, а нажатие любой кнопки перенаправить на RST, с последующим запуском рабочего режима (естественно, обработчик вектора сброса должен уметь отличать горячий запуск от холодного)

Спасибо. Но хотелось бы менее хакерского способа Ресет контроллера идеологически вещь, которая не должна использоваться для перехода из режима в режим.

Не появилось ни у кого идей по моему вопросу?

Разослать широковещательное сообщение всем процессам о смене режима? И пусть они сами рулят своим статусным регистром.