Комментарии 47
P.S. А почему бы в данной ситуации вместо оперативки microsd? Туда же можно писать уже что угодно — хоть GPS хоть коды ODB2 хоть данные гироскопа-акселерометра.
За чип хотят 16р/штука.
SD хорошо, но там слишком много контактов. Это же мотоцикл, более того, эндуро. Там такие вибрации, что контакты противопоказаны.
Ну и жрёт память SD в ардуине и флеш жрёт и быстродействие совсем не то. Здесь же i2c одна на всех, две ножки всего. Никаких файловых систем, просто пиу и готово.
P.S. А почему бы в данной ситуации вместо оперативки microsd?
насколько я понимаю, только промышленные micro sd карты (с соответствующей ценой) сравнимы по циклам записи с eeprom. у дешевых карт — циклов записи меньше.
тут, конечно, может помочь больший размер карты — можно устраивать wear leveling с циклическими буферами.
но в этом случае возникает вопрос про хранение указателя ) или поиска последней записи по сигнатуре )
в принципе, указатель в данном случае:
а. можно хранить в памяти, а записывать только по прерыванию на понижении питания
б. использовать код грея для указателя — чтобы уменьшить износ младших бит в ячейке
недавно был пост про малинку и readonly fs — там обсуждали износостойкость и были ссылки на информацию по картам
https://geektimes.ru/post/283802/
А моточасы, надо полагать, величина всегда возрастающая, поэтому можно просто писать в следующую ячейку и потом искать наибольшее значение.
Впрочем, попробовать новые штуки — тоже хорошо :]
Достаточно хранить абсолютные значения счётчиков и "нулевые" значения для сбрасываемых счётчиков (то есть, при сбросе записывать текущее абсолютное значение в ячейку памяти, а при чтении брать его оттуда и отнимать от нового текущего значения абсолютного счётчика). Не думаю, что счётчики вы будете сбрасывать настолько часто, что износ ячеек где хранятся "нулевые" значения может стать проблемой.
В чем проблема хранить показания одометра в еепроме (не обязательно внутреннем — их на любой плате россыпь обычно, спаял да прикрутил на соплях) по смещению 0x00, отвести на это целых четыре байта, например, а часы хранить в структуре по смещению 0x04???
Может ещё что-то всплывёт.
Микросхема стоит 16р/ш при покупке от 10 штук. Я её потом напаяю прямо на плату, когда буду разводить. Главное — код мизерный, память не ест, гемора нет.
вот например, RTC + i2c + 64 bytes RAM backed by battery
http://www.nxp.com/documents/data_sheet/PCF85363A.pdf
батарейки живут долго, там успеешь и имплементировать отслеживание разряда батареии и приглашение её поменять.
Простейший алгоритм реализации — это ввести некий счетчик, который увеличивается каждый раз при сохранении структуры (содержащей данные и сообственно счетчик). Если счетчик дошел до 100.000 — инкрементируется позиция структуры (которую можно хранить по фиксированному адресу, т.к. запись туда происходит редко).
У EEPROM время жизни скажем ~100 тысяч циклов
не надо забывать, что это применимо к одному биту. и лет 50-60 назад господин Грей придумал, как уменьшить износ физических переключателей для бинарных счетчиков.
если мы просто инкременитируем байт — то каждый раз младший бит мигает. и в конце концов умирает, а старшие разряды живы.
в итоге, добавив минимальную логику на преобразование gray-binary мы можем растянуть срок жизни еще в 8 раз )
Википедия — Код Грея
Идея заключается в том, чтобы использовать новую позицию для записи каждый раз, 1К памяти хватит на 3 года.
Всё хорошо, если стирание/запись не постраничная, как это часто бывает. Но на таких размерах это обычно не так.
Хотя всё же проще кольцевой буфер или, ИМХО, правильнее детектировать отключение питания и тогда всё сохранять, например, как тут http://radiokot.ru/forum/viewtopic.php?p=1120034#p1120034
Сначала я хотел обмануть судьбу записывая структурку данных в разные места 1К памяти чипа по кругу. Упёрся в то, что указатель надо где-то хранить тоже, а данные достаточно случайные, чтобы использовать какой-то маркер для последовательного поиска.
Можно было, наверное, два кольцевых буфера завести, один с указателем (увеличивается равномерно, при поиске искать самое большое число, которое не FF), а второй собственно с данными.
Нужно только реализовать «реакцию» на отключение питания, и схему на поддержание питания Ардуины, что бы успела скинуть последнее значение в EEPROM.
...«что-то сглючило с FRAM и прощай»...
Помехи обмена по I2C, блокирующая реализация Wire библиотеки…
Я в своём проекте ambox.me делаю именно так как предложенной выше. Плюс еже простейшая схема из электролита и диода на входечтобы питание не пропадало неожиданно. АЦП и источник опорного в Ардуине, благо есть. Пр правильной организации кольцевого буфера можно не только повысить ресурс eeprom на 2.5 порядка, но и гарантировать откат на предыдущее значение, если что.
Способ с FRAM надёжнее заметно. Конечно же, намного проще.
Одно другое не исключает, даже наоборот. :) Я собираюсь писать и туда и туда. Просто fram на i2c и шина тоже может сглючить даже на 100кГц.
прерываний больше, просто их на одну строчку кода сложнее обрабатывать))))
не ограничивайте себя int0 & int1
ловите pin change на порт и просто проверяйте нужную ногу
для атмеги328
4 Pin Change Interrupt Request 0 (pins D8 to D13) (PCINT0_vect)
5 Pin Change Interrupt Request 1 (pins A0 to A5) (PCINT1_vect)
6 Pin Change Interrupt Request 2 (pins D0 to D7) (PCINT2_vect)
тут есть прекрасный саммари http://gammon.com.au/interrupts, чтобы толстый даташит не перекапывать
FRAM через I2C для Arduino как замена EEPROM