Покритикуйте алгоритм включения и выключения устройства на AVR Опции

[zheka]

Господа, есть некое устройство на АТМега, управляющее TFT-дисплеем с тачпанелью и небольшим набором периферии. Подключено к автомобильному аккумулятору постоянно. А значит нужно предусмотреть включение и выкючение устройства. При всем изяществе конструкции, наличии тачпанели слишком жалко будет смотреться механический переключатель для коммутации. Хочется выключать устройство нажав виртуальную кнопку на тачпанели, а включать простым прикосновением к экрану. А посему возникла такая идея:
Контроллер управляет дисплеем через специальную плату (если кому интересно TFT-компаньон) Эта плата умеет выходить в режим пониженного потребления и понимает в нем только две команды - выход из режима пониженного энергопотребления и опрос тачпанели.
Я планирую по нажатии на виртуальную кнопку на экране переводить его в PowerDown. Затем переводть в PowerDown (именно в этот режим) и сам AVR. Как включать? Предварительно - настроить WatchDog на 1 сек и на генерацию прерывания по переполнению. В прерывании опрашивать тачпанель и если было прикосновение - можно просыпаться. Однако получается следующее - при выключении всего устройства мы его на самом деле не выключаем, а переводим в спящий режим, и при включении оказываемся на том же месте. Хотелось бы перезагрузить и контроллер. А для этого хочу попробовать следующее - если при обработке прерывания от сорожевого таймера выяснится что к тачпанели прикасались - перенастраивать таймер на сброс контроллера и более короткий период (самый короткий 16 мс). После чего ждать следующего переполнения таймера.

Пока не пробовал, идею сочинял на работе, попробую только дома.

Вопросы:
1. Довольно странный алгоритм получился - при выключении устройство на самом деле просто останавливается, а истинная его перезагрузка происходит только при включении. Хотя на самом деле ввсе выглядит благористойно (забыл сказать - в режиме PowerDown TFT компаньон не только меньше жрет, но и подсветку отключает). Может есть какие-то более адекватные истрически сложившиеся алгоритмы?
2. Есть ли какой-то иной способ программного сброса AVR? Цеплять какой-нибудь выход на RESET не предлагайте, плата сделана и детали напаяны.
3. Не происходит ли чего нехорошего с портами ввода вывода в режиме PowerDown АВР? Нужно чтобы пины оставались в том же состоянии.
Спасибо.

Сообщение отредактировал zheka - Mar 29 2011, 09:22

[aaarrr]

Вот и попались. Логика USART'а сброшена не будет такой инициализацией. Нужно было сначала сбросить RXEN и TXEN в 0, чтобы получить то же состояние, что и после хардварного сброса. То же самое касается SPI и прочих интерфейсов.
А перед "JMP 0" нужно как минимум запретить прерывания.

А теперь представьте, что у вас в руках не мелкая AVR'ка, а достаточно приличный контроллер с десятком используемых периферийных блоков, контроллером прерываний и т.п. Тоже будете вручную выбираться из неопределенного состояния после перехода на 0? То что прощается сейчас по причине примитивности контроллера в будущем вылезет изрядными граблями. Лучше изначально использовать правильный подход.

[forever_student]

...Логика USART'а сброшена не будет такой инициализацией. Нужно было сначала сбросить RXEN и TXEN в 0, чтобы получить то же состояние, что и после хардварного сброса. То же самое касается SPI и прочих интерфейсов...

А что мешает в INIT сначала принудительно присвоить регистрам используемой периферии
значения после POWER-UP, а потом инициализировать обычным путем?

[aaarrr]

А что мешает в INIT сначала принудительно присвоить регистрам используемой периферии
значения после POWER-UP, а потом инициализировать обычным путем?

Ничто не мешает, только это далеко не всегда эквивалентно сбросу.
Вы вот всегда так поступаете? И уверены, что сможете просчитать все возможные побочные эффекты?

Определенное состояние всегда следует предпочитать неопределенному, только и всего.

[forever_student]

...Вы вот всегда так поступаете? И уверены, что сможете просчитать все возможные побочные эффекты?

Определенное состояние всегда следует предпочитать неопределенному, только и всего.

Нет, я не всегда так поступаю.
Но в некоторых МК WDT с непрограммируемым таймаутом.
Ждать ...надцать секунд не всегда хорошо, и если МК не висит - такой сброс помогает.

[aaarrr]

Но в некоторых МК WDT с непрограммируемым таймаутом.
Ждать ...надцать секунд не всегда хорошо, и если МК не висит - такой сброс помогает.

Возможно. Но называть это действие сбросом все-таки нельзя.

[forever_student]

Возможно. Но называть это действие сбросом все-таки нельзя.

ОК. Рестарт