Разбираясь с протоколами обмена счетчиков электрической энергии обнаружил, что некоторые модели способны возвращать информацию о полном времени жизни батареи и оставшемся времени жизни.
Стало интересно, каким образом такая информация может быть получена счетчиком!?

Раз обмен - значит проц, раз проц - почему бы не быть RTC , раз RTC - значит батарейка. Модель плиз

Вы не поняли!!! Понятно, что батарейка, как узнать сколько ей осталось жить, даже при наличии проца?

P.S. Счетчик CE102 S6 (производство Энергомера). Вот выписка из протокола обмена:
Команда: ReadBatRes [0x0126]
Запрос: -
Ответ: 2 байта
UINT8[1] – полный ресурс батареи (количество месяцев);
UINT8[2] – текущее значение оставшегося ресурса (количество месяцев).

или сколько ей осталось жить - считает сам проц исходя из своей программы , своих параметров и параметров батарейки

Считаю, что двух абсолютно одинаковых батареек просто не существует. Батарейки деградируют со просто временем, под влиянием температур и кучи других причин.
Деградация в процессе работы тоже вряд ли линейна и предсказуема. Простой процессор может померять напряжение батарейки, но можно ли по уровню напряжения предсказать ее будущее не знаю?

Угу, но разброс не так уж и велик. И вышеупомянутый счетчик вполне может не вдаваться в такие подробности.
Его UINT8[1] – полный ресурс батареи (количество месяцев); скорее всего банально константа, и соответственно оставшийся ресурс вычисляется по таймеру

Возможно, но интересно тогда возможна ли замена батареи и как переинициализировать счетчик, чтобы считал сначала, команд таких не предусмотрено (по крайней мере в открытом протоколе).
Я уж было подумал, что может быть существуют источники питания (батареи), со встроенным контроллером, который настраивается на заводе, следит за зарядом и разрядом батареи и выдает информацию по какому-либо интерфейсу о ее состоянии!!!

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

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

Вообще-то просто с достаточной для практической точности периодичностью (минуты..часы) писать в ту-же энергонезависимую память RTC или будильик текущее время.
Оно + 1/2 периода записи и будет "временем пропадания питания". И без всяких "городить".

Если без всяких "городить", то питание с процессора не нужно снимать вообще. Достаточно перевести его в спящий режим. Потребление в таком режиме (при правильно построенной схеме) будет сопоставимо с саморазрядом батареи. То есть на ее ресурсе это ни скажется никак, сколь нибудь заметным образом. Срок годности батареи закончится раньше. Тогда отпадает необходимость использовать ЕЕPROM - зафиксированное время перед засыпанием можно хранить и в оперативной памяти. Пропадание (отключение) питания, в этом случае, используется как индикатор замены батареи (на новую, по умолчанию). И не надо ничего "городить".

В данном случае я отвечаю =AK=, который, действительно непонятно зачем завел разговор об отключении питания . К вопросу заданному Yaumen отключение питания действительно никакого отношения не имеет.

Некоторое отношение все-таки имеет. Топикстартер интересовался, как инициализировать счетчик ресурса при замене батареи, без использования
специальных команд. Инициализация по выключению/включению питания (в сочетании со спящим режимом без отключения питания) - один из возможных вариантов...

Раз , количество месяцев , то что-то их высчитывает , раз высчитывает , то при установке батареи явно работает АЦП.
И возможно по этой формуле высчитывает ресурс, но проценты переводит в месяцы


Хотя меня настораживает вот это:

Такое впечатление , что компаратор

Высчитывает. Скорее всего, исходя из среднего энергопотребления устройства и наперед известной емкости свежей батареи установленного типа.

Попробуйте с помощью АЦП определить степень разряда литиевой батарейки с точностью хотя бы 10%.
Если получится - научите нас потом, как это делается.

Это я уже говорил

А кто сказал , что там литиевая - ?

А кто сказал, что не литиевая? Очень даже вероятно...
Впрочем, это уже оффтоп и гадание на кофейной гуще...
Всего хорошего!

И Вам тоже

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

Вместо того, чтобы записывать текущее время, можно один раз запомнить время подключения батареи (еще на заводе, до отгрузки пользователю) и при помощи обычного счетчика в программе считать суммарное время работы, когда питание наличествует. Тогда в любой момент времени, вычтя из текущего времени время подключения батареи и суммарное время работы можно вычислить, сколько времени устройство находилось без питания и расходовало батарейку. Естественно, суммарное время работы тоже придется сохранять в энергонезависимой памяти и заботиться о целостности сохраненных данных.

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

Что-то не так . Счётчик считает киловат/час. Даже , есди батарейку установить на заводе, то пока счётчик валяется по складам - ей может наступить ёк.
- в AVR для этого есть цельный регистр. Поэтому проверить причину сброса - элементарно. А зная время текущее и последнее записанное в память - вычислить время работы RTC от батарейки , не сложно. Но в них предусмотен "Журнал состояния сети" , куда заностся и это Отключения или включения счетчика
(пропадание и восстановление питания) . А судя по единицам измерения (количество месяцев) - (+/-) киллометр всех вполне устраивает.
По всевозможным докам на этот счётчик - его инит производится при его установки на места его работы.(вплоть до тарифов в праздничные дни)
Что умным людям сможет помочь в значительной "экономии" электороэнергии при установке дома этого счётчика.
В СE102 S6 используется holtek (впервые слышу), зато в в S7 и прочих pic18f6490 и pic18f65j90

Вы собственно о какой проблеме связанной с не атомарностью волнуетесь? О том, например, что при записи времени раз в час и продолжительности этой процедуры несколько тактов как раз во время этих тактов пропадет питание? Это действительно ужасно и "никуда не годится" (посчитайте вероятность ) потеряем, например, сутки, это если имеет место быть неатомарность, что для встроенных RTC уже далеко не всегда.

Я рад, что Вы поняли всю бесполезность СВОЕГО предложения:

для решения поставленной Автором задачи.

Задним числом (после восстановления питания) узнавать, почему пропадало питание - в данном контексте бессмысленно. Речь о том, чтобы узнать о пропадании питания немедленно, за некоторое время того, как brown-out reset или супервизор питания выработают сигнал сброса.


Текущее время узнать не проблема. А вот гарантировать, что последнее записанное в память время - не испорчено, это требует определенных усилий, просто так это не получится. Если где-то в середине процедуры записи появится сигнал сброса, то часть времени будет "новым", а оставшаяся часть - останется старой. Именно об этом я говорил ранее, об атомарности записи.


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

Да наплевать - ещё раз обращаю Ваше внимание на единицы измерения - МЕСЯЦЫ

И кстати в послед. модификациях вообще компаратор используют

Проблема НЕ существует, даже после поминания ПОСТФАКТУМ ПРИТЯНУТОЙ ЗА УШИ ВАМИ возможного существования неатомарного доступа. Для существования проблемы даже после изменения Вами правил игры, нужно просто оценить вероятность и последствия некоего события.
Не следует аппаратно бороться с вероятностями уровня вероятности падения тунгусского метеорита на Ваше изделие, если они приводят к ничтожным последствиям типа увеличения погрешности измерения времени жизни батареи, которое и так более, чем оценочное.

Только получаются, как я вижу, лобовые, бездумные и избыточные, в том числе и по аппаратуре, "решения". Причем оценивать вероятности надежной работы вот такого:

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

Так ведь есть же разрядные характеристики. Градусы, Вольты, часы, пульсы...

Если 2 Вольта (или те же "N<=86"), то всё.

Однако, ресурс в 143 месяца, это да... Или эмир, или ишак...

Ох, и разрослась тема, пока я отсутствовал.
Я то думал, что вопрос простой и я просто упустил из виду появление на рынке "умных" батарей, которые умеют оценивать собственный заряд и расход и сообщать об этом по запросу.
А оказывается, что скорее всего это некий приблизительный расчет "пальцем в небо" конкретного производителя!!!

Может вскрыть счетчик и посмотреть, что там внутри!? Пломбу жалко!!!

Вы мне живо напоминаете персонажа Вовку из мультфильма "Вовка в тридевятом царстве", у него была точно такая же жизненная позиция: "подумаешь, и так сойдет!"

Здесь срежете угол, там на соплях сделаете, и т.д. - и рано или поздно какое-то из ваших изделий изделие "выстрелит". Конечно, вряд ли дойдет до масштабов Чернобыля, вероятность мала. Вспоминаю убийственную характеристику отечественной бытовой аппаратуры, которую слышал от пользователей: "Выглядит как настоящая, но включаешь - не работает". Тоже ведь был коллективный плод усилий таких же недоделкиных, любителей считать вероятности и базарить в курилках. Недоделок - это недоумок-практик.


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

Жаль, что думать Вы не можете . В голове Вашей пустота, тупые шаблонные решения и дежурные лозунги.

А Вы не допускаете, что такая "спешная" запись данных на падающем питании может завершиться неудачно? Гарантировать 100%-й успех записи невозможно. А повторить операцию несколько раз или как-то иначе обработать аварийную ситуацию - может просто не остаться времени. Самое скверное, что при последующем старте вы можете так и не установить, чем завершились все эти манипуляции на "агонирующем" питании. И на сколько можно доверять последним записанным значениям - то ли они действительно последние, то ли последние так и не удалось записать из-за каких-то проблем...
Поэтому говорить о какой-то исключительной "надежности и добротности" подобных решений не приходится. Скорее наоборот - где-то на грани технического авантюризма...

В дополнение к выше сказаному:
По-этому поводу была целая тема, на этом форуме, о китайском фонарике, где пол форума пыталось записать в Eeprom данные в момент выключения питания и проводилось уйма экспериментов записи - чтения . Если не изменяет память , там тема на страниц ~30-40 , а может и больше . =AK= - посмотрите

Не нашел


Это почему? Ессно, без учета прямых попаданий молний, ядерных взрывов и вспышек сверхновых в пределах досягаемости.

Это почему это?
Есть емкость конденсатора в цепи питания, есть потребляемый ток, есть допустимый диапазон питающих напряжений, есть время записи в EEPROM. Есть формулы, связывающие все эти параметры. Трудно посчитать и выбрать емкость с запасом?

Для справки: у меня при пропадании питания, тантале на 100 мкФ и процессоре atxmega32A4, спокойно удается записать страницу EEPROM 32 байта. Для практической проверки времени нахождения питания в допустимом диапазоне после обнаружения факта отключения источника выводил в бесконечном цикле в компорт тестовые байты (помимо записи в EEPROM!). По числу байт, полученных терминалкой, можно судить о вышеуказанном времени. Запас достаточный.

Вот такой вот технический авантюризм...
Кто-то его называет просто грамотным техническим решением.

Ошибки записи и сбои EEPROM встречаются несколько чаще описаных Вами явлений, хотя и достаточно редки. И если при обычной работе устройства такая ситуация совсем не смертельная - всегда можно как-то обработать ошибку или, в крайнем случае, индицировать неисправность - то при выключении у Вас может не оказаться возможности даже ее как-то зафиксировать. Поэтому, как Вы выразились:
Но говорить об исключительной надежности такого решения - не стоит.

Ну-ну...

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


Аналогично, только проц другой. Нюанс в том, что у меня кондер стоит на входе LDО, который делает 3.3В из 5В. От прочих цепей 5В накопительный кондер и LDO отделены диодом шоттки. После записи этой страницы проц уходит в спячку на несколько мс, чтобы снизить собственное потребление.

Плиз
http://electronix.ru/forum/index.php?showt...&hl=фонарик

Спасибо. Правда, к настоящему топику он отношения не имеет, так что я уж до конца читать не стал. Сама по себе задачка с китайским фонариком забавна. Скорей всего китайцы прописывают значения текущего режима в ОЗУ, а также держат в ОЗУ некий достаточно длинный "ключ", который портится при длительном выключении питания, однако довольно долго сохраняется на крохах остаточного питания от кондера. Если ключ испорчен - фонарик "начинает жизнь сначала", если цел - то переходят в следующий режим, считая, что записанное значение режима тоже сохранилось.

Почему же не имеет - задача таже , сохранить состояние (данные) при неожиданом откл. питания. Зря не дочитали и Ваша версия там была.

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


Ессно, поскольку это наиболее очевидное решение.

Такое впечатление, что личные отношения превалируют над логикой
Я сам этот "авантюризм" использую в приборах, которые выпущены тысячами, для сохранения статистики работы механических блоков с ограниченным ресурсом и предупреждения пользователя о небходимости вызвать сервис.
Решение как решение, тоже можно лопухнуться, но голова то зачем дана?

Откройте даташит на любой МК (от того же Микрочипа), раздел EEPROM. И ответьте себе на вопрос:
Зачем производитель рекомендует выполнять контрольное чтение после записи данных в ЕEPROM, причем даже тогда,
когда речь не идет о возможном исчерпании ресурса циклов стирание/запись?

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

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

Господа, а можно мне...
Нельзя ли поставить ключик, который нагружал бы батарею током на короткое время... Раз в месяц...
И измерять ее "просадку".

А , если это и будет её последний "выдох"? И мне кажется , ( перекрестился) это какая-то надуманная прибамбасина ,конкретных разработчиков ,этой модели счётчика , при этом точность - они своей целью не ставили. В PIC-ах они же от этого оказались и похоже просто применили компаратор. Самое простое и логичное решение - "Я так думаю" к.ф. "Мимино"

Тут согласен


Тут не согласен. Инженер обязан обеспечить требуемые характеристики детектора питания, причем это легко делается расчетным путем.
А вот рассчитывать схему/конструкцию на дерьмовость комплектующих в подавляющем большинстве случаев не стоит. Если комплектация - дерьмо, смените поставщика. Это не свидетельство неграмотного проектирования.


Была бы однозначная формула пересчета просадки в ресурс батарейки, был бы смысл. А так надо изучить немало диссеров по этому вопросу (или написать свой диссер), чтобы получить достоверное решение. Проще поступить по-военному: отработал срок - на помойку!

Ну зачем же так... Пусть даже заряд за время измерения будет равен дневному потреблению... Раз в месяц...

Ну раз пошла такая пьянка то :

Выдал Google на запрос и далее список производителей.

Что собственно избавляет и от прецизионного резистора , если измерять Вашим методом

А я и не призываю особо на это рассчитывать - только помнить о том, что "Первой, как правило, выходит из строя система обеспечения надежности" . Я ведь это поминал именно в контексте советской реальности, когда разработчики были вынуждены закладываться на дерьмовость, а если к этим добавкам бездумно еще наварачивали железа, то критическая масса для получения неработоспособного изделия достигалась легко . В нынешних реалиях, даже с учетом нонаме эта критическая масса поменьше, но она есть.

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

Пульсами их, пульсами!..

Нажмите для просмотра прикрепленного файла

Чем сильнее нагрузим, тем скорее предскажем...

Если предохрранители отнести к этой системе , то они , как правило выходят из строя последними

Раз пошла такая пьянка, то, кто встречал LDO, которые работали-бы при входном напряжении до 8V (ну в крайнем случае до 5V). Имели выходное напряжение, например, 3V
но при этом при падении входного напряжения ниже напряжения стабилизации представляли из себя ( по документам, а не попробовал и работает) открытый транзистор по крайней мере до напряжения в 2.1V. До кучи, еще защита от неверной полярности. Ток до 50mA устроит. Габариты (из-за этого собсвенно весь сыр-бор) минимальнейшие.
Один кандидат найден, кроме защиты от переполюсовки, 5V входного максимум и цены порядка 2EURO поштучно (хотя черт с ней), всем хорош.