Пусть есть девайс на AVR Mega, к которому подключен внешний RTC скажем типа DS1307.
Как лучше всего и экономнее по ресурсам организовать переход с зимнего на летнее время и наоборот, учитывая что девайс может быть как включен в момент перехода, так и выключен ?

Ну очень важная информация....

Сам RTC не трогать ни в коем случае (не уподобляйтесь, блин MS!), просто считав из него время при необходимости скорректируйте на лето. Все.

Флаг ставить в памяти DS1307 - типа текущее время летенее или зимнее. Проверять на граничную дату, смотреть флаг и переводить часы и изменять флаг. Пару строчек кода.

Почему бы просто не зарезервирвать в eeprom контроллера память под флаг "текущее время" (лето или зима). А потом раз в сутки и при включении проверять дату из ds1307 и смотреть, попадает ли она в "текущее время", если нет, то корректируем время и меняем значение флага на противоположное. Места в программе это много не займет...

Нафига флаг-то - при бесхалтурном подходе (а не как выше предлагалось "раз в сутки") проверять лето/зима при каждом обращени к часам - это без вариантов.

Метод zltigo самый простой и главное самый надежный.
Флаги и пр. вообще не нужны.

За переводить часы сразу надо по рукам давать. Нормальный подход только один - часы идут по гринвичу всегда, а уж что у нас с локальным временем и летом это уже коррекция.

zltigo прав: самое разумное -- держать в DS1307 только время.

Инициатором запросов времени однозначно будет клиентская часть программы МК (так называемая -- бизнес-логика). Думаю, что следует написать код так, чтобы запросы шли не непосредственно к DS1307 (через I2C), а к промежуточному коду, т.е к прослойке между аппаратурой и бизнес-логикой. Назовите этот код драйвером DS1307 и все встанет на свои места. Написать этот код не сложно, сложнее понять (объяснить самому себе) смысл/необходимость этого дополнительного кода.

В драйвере Вы можете прописть все, что хотите. Например, отвечать на запрос клиентской программы учитывая зимнее/летнее время. Зимнее/летнее время учитывается по критерию текущей даты и, соответственно, корректируется или не корректируется динамически при исполнении запроса. В драйвере Вы можете учтывать часовой пояс, который удобно хранить там же -- в ОЗУ DS1307.

Иначе говоря, наличие драйвера, даст Вам свободу маневра. А лезть с коррекцией в DS1307 -- право, не стоит.

Пользователя при инициализации тоже просить ввести время по гринвичу?

Необязательно совсем, каие проблемы пересчитать локальное?

ну если этот девайс подключен к инетнету, то, наверно, скорее "да", чем "нет". К сожалению, Олег Хохлов не уточнил, что за устройство.

А вообще

выделенное слово следует понимать, как "если Вам это необходимо, то нет препятствий для ..."

Сама по себе не очень, но имелась в виду определенная ограниченность в ресурсах (Mega16 уже забита процентов на 80% по коду).


Спасибо всем за высказанные мнения. Имевшиеся у меня сомнения по поводу:



были вызваны только тем, что как я уже выше сказал мега уже почти забита, а функции арифметики над датой/временем, которые очевидно нужны для данного варианта реализации, компилируются на меге ну уж в очень печальный код по размеру и эффективности (посмотрел листинг-прослезился).
И коррекция времени нужна как при вычитывании времени из RTC, так и при записи времени в RTC.
Впрочем, я уже придумал как сделать это оптимальнее.




Девайс - ну вообще их несколько разных, но все - малые контроллеры, которые чем-нибудь автономным управляют. К интернету разумеется не подключены Один например - центральный контроллер средств индикации типа светодиодных часов/ценников/стелл и т.д. Другой - самодельный бортовой комп для ВАЗ.

Да ну? Что-же там можно такого большого и неэффективного написать, тем более, если не добавлять многочисленные правила перехода лето/зима и лунные календари...

Да вообще можно использовать DS1337 с её будильниками и отрабатывать прерывание- "стукнул" один - зима , другой -лето . А время держать в таблице- всё произойдёт автоматом - код минимальный.

третий раз в первый класс
http://electronix.ru/forum/index.php?showtopic=45647