Собственно, есть проект на Mega169. Тактовая внутренняя 8М, 2 прерывания:

1. Таймер 1 (~1000Hz) - опрос клавиатуры, индикатора и т.д.
2. Таймер 2 (RTC, кварц32768) - раз в секунду считается время.

вот в 1-м таймере опрашивается датчик внешнего напряжения, его дребезг и т.д. и через некоторое время
необходимо проц усыпить, дабы он не скушал слабенький аккум (~20mah,4.8v) Но просыпаться раз в 1 сек от таймера 2
и, добавив секунду снова уснуть(если питание не появилось)...
Может кто сталкивался с такими задачами?
Собственно интересует правильный процесс перехода в спячку, просыпание и снова спячка...
т.е. необходимо ли разрешить прерывания и не сбрасывать флаг для TMR1 что бы проснулся от TMR2?
но как я понимаю, флаг сбрасывается при входе в прерывание, значит его нужно ручками установить?

А какая связь между этими прерываниями ? Проснуться по прерыванию TMR1 все равно нельзя, так что речь может идти только о обработке TMR2. Соответственно, включить асинхронный режим с нужным прескалером, раскрыть прерывания по переполнению (как вариант), выставить соответствующий режим обслуживания команды sleep. Особенность TMR2 в асинхронном режиме (169 не щупал, но, думаю, так же, как и в других) - нельзя выйти из обработчика TMR2 сразу (т.е. можно, но тогда нельзя сразу же опять уходить в sleep), должен выполнится один цикл таймера (1/32768 sec).

Именно TMR2, т.к. проц выключает свой тактовый генератор. Проблема в другом: именно в прерывании если просто выполнить sleep, проц от TMR2 не проснётся-прерывания-то выключены при входе в обработчик TMR1. А если их включить, то возможен бесконечный цикл/переполнение стека с TMR1. Вот я и думаю, что что-то здесь не так... Может остановить TMR1 и включить прерывания?
А в sleep нужно уходить максимально быстро...

Я может чегото пропустил, но где Вы это вычитали?

К сожалению из опыта.(Я раньше писал только на асм, там извращался как мог...) А насчёт цикла 1/32768 вы пожалуй правы. Иначе sleep не действует, а сразу выполняется обработчик TMR2 несколько раз... Самое интересное, что я жду пока в регистре ASSR младшие 3 бита будут равны 0, но почему-то это не помогает...
Да, делитель у меня на TMR2 на 128. (счётчик на 256*делитель 128=32768). На осциле вижу импульсы(тест. ножку сделал) примерно 3-4 штуки по 12 микросекунд. это обработка TMR2+sleep. Как бы не получить время 1/32768*128=3.9ms Это будет катастрофа

И куда ж все так торопятся? От того, что контроллер уснет на 1 мс позже, земная ось погнется?
Не засыпайте в прерывании. Засыпайте только снаружи.
У Вас по TMR1 выполняется несколько задач. Могу предположить, что они друг на друга не очень сильно завязаны, но пока все не завершены, засыпать не стОит. Так заведите какую-нить структуру типа SleepInh и отдайте в ней по биту на каждую такую задачу. Каждый раз, стартанув задачу, взводите бит, завершив - сбрасываете. Если SleepInh == 0, значит пора спать.
Я, правда, не представляю, как можно работать с клавиатурой со временем реакции > 1 с. Наверное, разумнее будет просыпаться по TMR2 с частотой 32-64-128 Гц - тогда опрос клавы (и 1 такт устранения дребезга) можно выполнять единожды на прерывание TMR2.

Я уже писал, что стоит аккум ~20mah,4.8v а устройство должно проработать недели 2-3 без внешнего корма и эта миллисекунда мне очень дорога...
А TMR1 выполняет общие функции (клавиатура,дребезг,жки) и ко времени привязан слабо.
TMR2 только секунды добавляет (<50 тактов выполнение)
А снаружи инженерная математика(и логарифмы и синусы и т.д) и эта математика думает иногда очень долго(минуты). Поэтому в неё нельзя. Поэтому и сабж. Сейчас на данный момент достиг 118 мкс, пытаюсь укоротить хотя бы ещё втрое...

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

Примерно через часик скину. Сейчас добился примерно 30 мкс, а это как раз 1/32768, но нужно всё проверить...

Я уже прочитал про аккум. 1 мс была помянута образно. Пусть будет 100 мкс, если все задачи у Вас завершаются за это время. Но, судя по "инженерной математике", это далеко не так. Я не знаю алгоритма работы Вашего устройства, и как часто ему приходится заниматься математикой, но, имхо, убиваться над потреблением контроллера за сверхбыстрый (и некорректный) уход в спячку на фоне минут в математике бессмысленно.

Как всегда, задача нестандартная... Математика тормозит, но клавиатурой прерывается. Всё хорошо, пока есть питание. А когда его нет, всё скидывается в еепром и считается время бездействия.
К сожалению, 30 мкс пока не получилось. Получилось только 120 мкс. Буду думать дальше, но наврядли. Тем не менее, могу скинуть то, что есть, если интересно...

Вообще-то из даташита. После того, как наступил...


Просто это написано в даташите.

Именно так. Про то и написано. Что переполнение, что сравнение.

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

Нет, один цикл осциллятора, независимо от значения прескалера. У меня все устройства сейчас именно в таком режиме работают (mega8, mega168). С потреблением все в порядке...

Гм. Действительно. Как-то это мимо меня прошло... Ааа... Понял. В том приборе моем, который спит и просыпается от часов, кварцевый генератор основной, и пока он раскачается, цикл TOSC1 вполне проходит.

Хотя стоп... Есть у меня другой прибор, там внутренний RC. Пойду-ка я посмотрю, чего там, может за давностью лет не помню...

Мда. Извращенно. Ну, вообще-то, если раскрыть прерывания (только, конечно, не TMR1, а то, пожалуй, будет рекурсия) и уйти в sleep (когда он разрешен) внутри прерывания TMR1, то повторного прерывания случиться не должно, процессор уснет, и таймер тоже встанет. Однако после выполнения прерывания TMR2 возобновится работа того обработчика, где был sleep. Вообще, я бы такое (обработку асинхронного пропадания внешнего питания) попробовал бы сделать через внешние прерывания.

Т.е. математику на аккумуляторе Вы не считаете? А клаву обрабатываете? Или только время бездействия (надеюсь, Вы это время в ЕЕПРОМ не сохраняете)?
Ей-ей, отключив лишнюю периферию и использовав внешний супервизор питания, включаемый когда нужно с ноги контроллера, наэкономите больше.


А смысл? Есть резервное питание от аккумулятора, при пропадании основного все равно нужно скинуть в ЕЕПРОМ некоторое количество данных, поэтому скорость реакции на пропадание основного не очень и интересна. Электроэнергии на сохранение в ЕЕПРОМ будет сожжено больше, чем за сутки работы TMR2 на часовом кварце. имхо, разумнее организовать сохранение данных в ЕЕПРОМ в спячке (просыпаясь по TMR2, проверять состояние очереди записи и, при необходимости, завершенность предыдущей записи - в такой последовательности будет экономичнее).

Если попробовать использовать фиктивное прерывание. Берем какой нибудь вывод порта, надежно его заземляем, и настраиваем прерывания на перепад напряжения на этом выводе.
В TMR1 взводим флаг прерывания от того вывода и выходим из прерывания TMR1 срочным образом. И тут же попадаем в фиктивное прерывание, сбрасываем флаг, разрешаем глобальные прерыывания и уходим в sleep, тут не должно быть переполнения стека, потому что пока мы сами не сгенерируем прерывания от порта, они не появятся.

Зачем всякие фиктивные прерывания? Всё красиво работает. Перед sleep я принудительно останавливаю TMR1.
Вопросов с рекурсией не возникает. Прога по TMR2 считает только секунды и больше ничем не занята.
Время выполнения как я не крутил-120мкс и всё тут. (это 4 периода 32768 Hz) не могу понять только, почему 4...

Правда, сейчас не могу разобраться с оптимизацией - на максимуме и на минимуме есть глюки, макс. без code motion и cross calls<5 работает.
И закралась на этапе вылизывания интересная вещь: при обновлении ЖКИ на нём иногда включаются совсем не те сегменты,
которые должны были... хотя ОЗУ не модифицировалось (просто обновление)

Кстати у меня тоже 4 почему-то получалось. Но в том случае меньше и не надо было. Да вспомнил. Тактовый генератор (основной кварц) крайне медленно запускается. Те-же фузы, что при выходе из слипа, что при запуске.
Я в своё время решил проблемму потребления при этом (ионистор) понижая тактовую частоту в 16 раз. Это оказалось даже выгоднее (по энергозатратам), чем засыпать и через 5 милисек просыпаться. Тогда я решил, что во время запуска основной тактовый генератор кушает больше, чем во время работы. Только с поделённой более чем в 2 раза тактовой ни в коем случае не засыпайте. Просыпаться будет во столько-же раз медленнее.