[murmur 0]

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

Вот устройство http://c2.at.ua/load/tajmery/schetchik_otr...rovoj/21-1-0-50

 

Это счетчик, который считает время своей работы. Как написано в описании, при снятии питания он сохраняет значение отработанного времени в энергонезависимой памяти.

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

 

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

 

Правильно ли я поняла алгоритм работы устройства или все же НА ДАННОЙ КОНКРЕТНОЙ СХЕМЕ каким-то хитрым способом можно вести запись в EEPROM именно во время пропадания питания? ПРедлагаемая прошивка на асме, я в нем ноль.

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

 

В общем, есть ли у этой задачи решение, реализуемое на данной схеме, или же нужно сообщать заказчику о необходимости рисовать новую схему?

Изменено 18 ноября, 2012 пользователем murmur

[rx3apf 0]

Без модификации схемы - нереально. Да и с модификацией непросто (пытаться обнаружить потерю входного питания и на остатках заряда фильтровых конденсаторов писать в EEPROM - верный путь к искажению содержимого). Если счетчики размазывать по всему EEPROM - тоже ресурса максимум на месяц-два.

[murmur 0]

Спасибо, этого ответа я и ждала.

[Herz 5]

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

 

В общем, есть ли у этой задачи решение, реализуемое на данной схеме, или же нужно сообщать заказчику о необходимости рисовать новую схему?

А почему бы не использовать PD2 для контроля за питанием? Ведь сброс счётчика тоже наверняка должен инициировать запись во флешь нулей.

Только компаратор поставить.

[zombi 0]

ПРедлагаемая прошивка на асме

А где асм ? не вижу.

[ReAl 0]

Если счетчики размазывать по всему EEPROM - тоже ресурса максимум на месяц-два.

Если схему менять не хочется...

 

Вот что-то мне говорит, что 100к -- это число стираний, а не записей.

А у tiny2313 уже эти операции резделены, можно писать не стирая.

 

Надо пробовать конечно, но идея такая:

Выделяем восемь байт (64 бита) EEPROM под счётчик секунд «термометром».

Т.е. изначально там 0xFF

В первую секунду пишем в нулевой байт 0xFE (~0x01)

Во вторую секунду пишем в нулевой байт 0xFD (~0x02) -- заметьте, в бит 0 уже не пишем, в него импульсы не пойдут.

И так далее, пока не пропишем нулями 59 бит. Тогда инкрементируем счётчик минут и стираем эти байты.

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

 

Дальше можно фантазировать на тему выделения большего числа байт под «термометр» секунд. Выделение 15 байт даст 120 бит, две минуты (и дальше счётчик по две минуты, а не по одной), 60 байт - 8 минут.

Размазывать особого смысла нет, просто удлиннение счётчика секунд само есть размазыванием.

[rx3apf 0]

Если схему менять не хочется...

 

Вот что-то мне говорит, что 100к -- это число стираний, а не записей.

А у tiny2313 уже эти операции резделены, можно писать не стирая.

Хм.. А ведь и в самом деле...

Дальше можно фантазировать на тему выделения большего числа байт под «термометр» секунд. Выделение 15 байт даст 120 бит, две минуты (и дальше счётчик по две минуты, а не по одной), 60 байт - 8 минут.

Размазывать особого смысла нет, просто удлиннение счётчика секунд само есть размазыванием.

Идея интересная, да. Но даже если отведем 124 байта под битовые отметки секунд, то все равно ресурса хватит года на три. Маловато... Впрочем, если заказчик согласится на увеличение дискретности до 2..10 секунд, то ресурс вырастет пропорционально. Если, конечно, все действительно обстоит таким образом - ну, проверить-то недолго...

Изменено 18 ноября, 2012 пользователем rx3apf

[zombi 0]

В первую секунду пишем в нулевой байт 0xFE (~0x01)

Во вторую секунду пишем в нулевой байт 0xFD (~0x02) -- заметьте, в бит 0 уже не пишем, в него импульсы не пойдут.

И так далее, пока не пропишем нулями 59 бит. Тогда инкрементируем счётчик минут и стираем эти байты.

Если выключить питание при записи (обнулении) очередного бита то ничего страшного не произойдёт (максимум 1 сек потеряем).

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

Хотя проблема выключения питания во время записи епром есть в любом случае. Интересно как автор её решает. Хочется увидеть исходник.

[ReAl 0]

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

Эта проблема в полный рост встанет при инкременте минут-часов независимо от стирания секунд.

 

По достижении секундами предела:

В отдельном байте флагов пишем бит "минута прошла" (ну или две-четыре-восемь, как выделили)

Стираем секунды.

В флагах пишем бит "секунды стёрты"

Берём счётчик минут-часов, увеличиваем на 1 и пишем в другие ячейки

В флагах пишем бит "значение времени подготовлено"

Читаем новое значение времени из буфера, записываем в основной счётчик.

Стираем байт флагов.

 

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

 

Что-то в таком духе пришлось сделать где-то в конце 90-тых, когда наша добрая сертификация при проверке прибора выключила его питание посреди рабочего цикла, раскрутила (пломбируемый по жизни) прибор, вытащила батарейку, коротнула отверточкой ее контакты на несколько секунд, собрала все назад, включила, ткнула пальцем в невосстановление работы с прерванного места и заявила, что в стандарте «должен сохранять bla-bla-bla в энергонезависимой памяти в течении 1440 часов» а та память «не энергонезависимая, она зависит от батарейки».

Ну за пару дней подчистил софт, больше не смогли придраться. Думаю, немого денег фирме этим сэкономил.

 

ресурса хватит года на три.

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

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

 

Если, конечно, все действительно обстоит таким образом - ну, проверить-то недолго...

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

[zombi 0]

По достижении секундами предела: ...

Да, действительно целостность данных не нарушится.

Но остаётся одно узкое место - байт флагов. Который пишется раз в минуту (ну или две-четыре-восемь, как выделили)

[ReAl 0]

Но остаётся одно узкое место - байт флагов. Который пишется раз в минуту (ну или две-четыре-восемь, как выделили)

Ровно так же часто, как сами секунды и младший байт счётчика этого «как выделили». Так что не заужает остальное.

[zombi 0]

Так что не заужает остальное.

Это если принять на веру то что обнуление одного из битов в байте епрома не влияет на ресурс других.

Хотя можно наверное в качестве флагов использовать и разные байты.

[ReAl 0]

На веру принимать не надо, надо проверить. На это должно уйти несколько часов.

Разница будет или не очень заметна, или очень и это будет ответ на вопрос.

 

По физике -- стирание это импульсы в одном направлении, запись -- в другом. Ресурс уходит на этих импульсах.

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

Кончено, влияние на соседние биты и даже байты может быть, так как «напряжение ходит рядом», что-то там было у атмел data flash на эту тему. Но всё равно я ожидаю существенного увеличения ресурса.

[ILYAUL 0]

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

Каждая из 128 ячеек EEPROM имеет гарантированный ресурс по записи 100'000. Каждую минуту программа записывает в следующие, после предыдущей записи, 4 ячейки новое значение текущего времени. Через 128:4=32 минуты весь массив EEPROM будет записан. Поэтому

600'000 [минут]:32 [минуты]= 18'750 циклов записи каждая ячейка EEPROM выдержит. Дополнительно, в каждую ячейку через каждые 32 минуты записывается 0xFF. Т.е. нужно добавить еще 18'750 циклов. Получается, что каждая ячейка EEPROM в течении 10'000 часов будет перезаписана 37'500 раз.

Для поиска последнего значения наработки при очередном включении питания, вся страница EEPROM при программировании контроллера, а также каждые 32 минуты заполняется 0xFF. Формат записываемых данных исключает появление такого значения и оно может служить признаком куда нужно будет записывать следующее значение и откуда брать последнее записанное...

В приложении asm

И его схема мне больше нравиться

MOTOHOURS_01.rar

[zombi 0]

И его схема мне больше нравиться

Я хоть и не схемотехник но схема мне тоже нравится больше