Начинаю "мучать" ATxmega64A1.
Экспериментирую со sleep режимом power-save.
CPU тактируется int. RC2MHz, RTC ext. 1024Hz.
Питание 3.3v на мегу подаётся через диод шоттки (BAT54C) падение порядка 0.3v.
По старту инициализируем портА,RTC и сразу засыпаем (pover-save).
Просыпаемся по переполнению RTC.
В преравании небольшой код и смена состояния ноги портаA.0 на противоположное.

на осцлограмме:
CH2 - пин портаA
CH3 - VCC.
Видно что после засыпания питание на процессоре и на пине (если он в 1-це) плавно поднимается почти до 4-х вольт !
Откуда берутся эти лишние 0.7v? опасно ли это для процессора при максимально допустимом питании 3.6v ?
Если в sleep не уходить то питание на проце стабильно и не превышает 3.0v.
З.Ы. Если закоротить диод шоттки то питание тоже нормальное 3.3V.

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

Если считать, что команда sleep выполняется не один такт, а всё время нахождения в режиме пониженного потребления, то получается что RTC не выведет в рабочий режим. Допустим.
Но как тогда понимать продолжение фразы:

Перевод: будет проигнорирован[запрос прерывания от RTC], пока устройство не разбужено из другого источника или
источник сработал снова(запрос прерывания от RTC).

То есть по Вашей логике получается:
1. RTC не выводит из sleep на свой вектор
2. Выход из sleep произойдёт от другого источника wake-up или повторного срабатывания RTC.
Пункты 1 и 2 противоречивы.

Получается, что sleep в любом режиме выполняется 1 такт:
1) Sleep не разрешён: аналогично nop
2) Sleep разрешён: один такт на команду sleep, затем остановка выполнения любых команд до wake-up или reset.

Но проверить надо ...

Вот - и я не понял о каком источнике , который или сработал или переключился , снова - они хотели сказать.


Может это sleep в режиме ADC noise , тогда хоть какая то логика есть. Пока он цифрует , его ничто оттуда не вышибет.

Речь по-моему о том, что прерывание от RTC, возникшее в момент исполнения команды sleep будет потеряно и мега проснётся либо при следующем прерывании от RTC, либо после какого-либо другого источника wake-up.



Речь о всех режимах пониженного потребления, отдельно про ADC noise ничего не говорилось.

Запросил support - пусть разбираются , что они имели ввиду когда ее писали.

Не переводимый полёт мысли:

Я понял так
Если обрабатывается комманда , после предыдущего режима сна , RTC - будут обрабатываться , только после того как проц "придёт в себя" (похмелиться значить)

И вообще пофиг в каком режиме будет пропуск RTC - на одну комманду см. пункт 2


ИСХОДНИК
I have got some clarification on errata 34. There are a couple of reasons
why an interrupt could be pending.
1) Interrupt happens while global flag IRQ enable in Sreg is not set
2) If another interrupt is being processed while the IRQ is triggered

After an interrupt service routine, the XMEGA always jumps back to where it was in the code and executes one instruction, even if there is another
interrupt pending. This is to avoid locking up the processor with high
frequency interrupts.
So to look at the errata relating to the asynchronous RTC-interrupt.

If another interrupt routine is being processed when the asynchronous RTC-
irq occurs, then the RTC-irq is pending. If the one instruction which gets
processed after the previous interrupt is the sleep instruction, the async
RTC-irq will only be processed after something else wakes up the processor.

The type of sleep mode set is not relevant.

An async-RTC irq will wake the processor if this occurs while the processor
is asleep. So there is only a very rare that the above condition will cause
problems.

This errata (no 34) is very closely linked to errata 23: Pending full
asynchronous pin change interrupts will not wake the device.


Best Regards,
Glen Nilsen
Atmel Technical Support Team

Очень вольный, смысловой перевод основной части:

... Есть несколько причин, по которым прерывание может быть отложено:

1) прерывание происходит в то время, когда глобальный флаг разрешения прерываний в SREG не установлен ;

2) если обрабатывается другое прерывание, в то время как IRQ срабатывает (приходит сигнал прерывания) ;

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

С этих позиций нужно смотреть на ошибки, связанные с асинхронными RTC-прерываниями.

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

Асинхронное-RTC прерывание выводит процессор из слип режима, если это происходит непосредственно в режиме сна, но не в процессе возврата из другого прерывания на команду sleep. Предполагается, что попадание RTC-прерывания в такую ситуацию является очень редким и не должно доставлять проблем...


Сообщение отредактировал @Ark - Oct 17 2011, 17:23