AVR. Как проснутся по UART

[Волосатый]

Есть острая необходимость разбудить контроллер Atmega48 ( или 8 ) из режима power-off командой из UART. Знаю, что стандартными средствами это сделать невозможно.
Может каким-нибудь образом подключить вход данных на ножку INT0 к примеру, и просыпаться как с обычного внешнего прерывания, и сразу отключать сиё прерывание, а перед спячкой его снова взводить...
Вот только вопросец - а успеет ли это прерывание захватить скажем, команду 0xFF или 0xFFFF ?
Или может есть другой способ?

[asteroid7]

Тупо запараллелить ноги RXD и INT0. INT настроить по низкому уровню.
"успеет ли это прерывание захватить" - зависит от CKSELx, SUTx и скорости UART. В ДШ есть таблицы времянок запуска генератора.

[Волосатый]

А время срабатывания INT по низкому уровню в режиме power-off такое же, как и в обычном рабочем, и равно ~50 нс ?

[Волосатый]

В продолжение темы "предчуствие граблей". Сами грабли...

В устройстве используется USART вместе с режимом сна ADC noise reduction. Проблема в том, что МК большую часть своего времени циклично оцифровывает сигнал и делает с ним что-то, выходя по прерыванию из сна ADC noise reduction. Во время этого "сна" к МК может придти байт по USART'у. МК просыпается, отключает ADC, и ждет пока завершится прием. Но. судя по всему из-за задержки на выведение из сна, происходит рассинхрон и МК получает мусор: в старшем разряде появляются 2-3 "левых" единицы (двоичное исчисление) и выходит байт как бы смещен вправо а пустота заполнена единицами.

Каким способом этого можно избежать?

[md5sum]

Судя по ДШ USART ждет стартового бита - ждет именно спада из 1 в 0, а не состояния 0 на линии.
Естественно этот спад пробуждает МК, но USART его не видит и принимает за старт первый нулевой бит.
Мне видится два варианта решения:
1. Если обмен ведется ограниченным набором кодов (ASCII например), то перед посылкой байта команды посылать символ пробуждения (преамбулу) с кодом отличным от набора.
2. Реализовать полностью программный прием байта - задача не сильно сложная, особенно если скорость обмена не шибко высокая. В этом случае, по "просыпанию" программа уже знает, что пришел START и просто получает биты в соответствии с алгоритмом. За основу можно взять и описанный в ДШ.

На скорости 9600, я не заморачивался многократными выборками, а просто раз в период считывал состояние линии. Правда в моем случае пакет передавался с контрольной суммой и в случае ее несовпадения программа безболезненно игнорировала пакет.

[Волосатый]

Проанализировав еще раз отправленные в МК и принятые им байты я пришел к выводу, что вы правы. Чистый прием начинается со следующего бита после 1-0...
"Символ пробуждения" отправлять это впринципе можно накоддить, но терминалка в протеусе не позволяет отправлять два байта без паузы между ними.
И я так понял, что бы МК не запутался, нужно посылать конкретное числ 0111 1110. Первый ноль для пробуждения МК а последний ноль вместо "штатного" старт бита. Это число 0x7E.

Отсюда вопрос как в протеусе набрать число 0x7E или любое другое...

[md5sum]

Первый ноль для пробуждения МК а последний ноль вместо "штатного" старт бита. Это число 0x7E.

С протеусом не заморачиваюсь...
Первый ноль не нужен - МК и так проснется от штатного старта. А вот если в качестве преамбулы передать 0xff, то МК проснется от штатного старта, далее USART "увидит" все единицы и будет ждать старт, который будет предворять второй байт (сгенерится аппаратно).
Т.о. задача сводится к проверке: если МК проснулся от прерывания int0 (или какой-там запараллелен на RX), то необходимо дождаться байта не уходя в сон.

[Волосатый]

Вы однако правы, FF будет правильней. Разобрался с протеем как там числа слать - этот метод действительно работает
Спасибо