Требуется вести лог данных. Скорость - несколько байт в минуту. Записи могут быть переменной длинны, но их изменение в процессе работы не требуется. После считывания данных хостом считанные данные очищаются.
Нужна ли для этого файловая система с дополнительными сервисными возможностями или ограничиться кольцевым буфером ?
Можно ли в AT45DB дописывать (не стирая предыдущие данные) данные в сектор, в который уже была сделана запись ?
Теоретически, есть еще 56 байт в NV-RAM, которые пока не используются. Хотя на сектор (512 байт) их не достаточно.
Полная версия этой страницы: Нужна ли FS ?
Цитата(Огурцов @ Oct 6 2008, 21:30) 
Можно ли в AT45DB дописывать (не стирая предыдущие данные) данные в сектор, в который уже была сделана запись ?
Можно дописывать, а можно и просто складывать данные во внутренний буфер AT45.
Огурцов, если это не технологический сиюсекундный девайс - пишите во fram. Чем больше рамер фрам - тем дольше проживёт 45
Я бы не очищал данные, а сделал бы офигенный кольцевой буфер. Износ был бы равномерным.
Оцените количество записываемых данных и период съема информации. Может вам подойдет SRAM с интерфейсом SPI от AMI Semiconductor, которую на данный момент купила фирма ON Semiconductor. http://www.onsemi.com/PowerSolutions/parametrics.do?id=2207
Купить SRAM можно, например, в Терраэлектронике. http://www.terraelectronica.ru/catalog.php?ID=316&IDm=b
Прикручиваете к ней литиевую батарейку как резервное питание и получаете NVRAM с неограниченным ресурсом. Потребление ее в режиме STANDBY не более 0,5мкА.
Купить SRAM можно, например, в Терраэлектронике. http://www.terraelectronica.ru/catalog.php?ID=316&IDm=b
Прикручиваете к ней литиевую батарейку как резервное питание и получаете NVRAM с неограниченным ресурсом. Потребление ее в режиме STANDBY не более 0,5мкА.
Подумал: емкости чипа должно хватать на 1 год, время эксплуатации - не более 10 лет. Т.е. всего 10 полных циклов. Даже если писать по 1 байту и каждый раз стирать страницу, это будет всего 5120 стираний на страницу, т.е. похоже есть огромный запас даже при варварском режиме записи - можно не напрягаться.
2 rezident: Сложно, наверно, будет эти SRAM от батарейки запитать. Хотя прогресс впечатляет.
2 DpInRock: да, примерно так и думаю. Хочу лишь выяснить, есть какие-то ли плюсы в использовании файловой системы. Например, с точки зрения облегчения программирования.
2 rezident: Сложно, наверно, будет эти SRAM от батарейки запитать. Хотя прогресс впечатляет.
2 DpInRock: да, примерно так и думаю. Хочу лишь выяснить, есть какие-то ли плюсы в использовании файловой системы. Например, с точки зрения облегчения программирования.
Цитата(Огурцов @ Oct 6 2008, 20:30)
Можно ли в AT45DB дописывать (не стирая предыдущие данные) данные в сектор, в который уже была сделана запись ?
Осторожно с этим надо.У AT45DBxxxB написано недвусмысленно:
Цитата
Buffer to Main Memory Page Program without Built-in Erase
A previously erased page within main memory can be programmed with the contents of either buffer 1 or buffer 2.
.....
Successive page programming operations without doing a page erase are not recommended. In other words, changing bytes within a page from a ”1” to a ”0” during multiple page programming operations without erasing that page is not recommended.
A previously erased page within main memory can be programmed with the contents of either buffer 1 or buffer 2.
.....
Successive page programming operations without doing a page erase are not recommended. In other words, changing bytes within a page from a ”1” to a ”0” during multiple page programming operations without erasing that page is not recommended.
У AT45DBxxxD несколько невнятно:
Цитата
It is necessary that the page in main memory that is being programmed has been previously erased using one of the erase commands (Page Erase or Block Erase).
Может можно дописывать (имели ввиду всего лишь то, что без стирания не "запишутся" единички), может нет.Цитата(Огурцов @ Oct 6 2008, 20:30)
Теоретически, есть еще 56 байт в NV-RAM, которые пока не используются. Хотя на сектор (512 байт) их не достаточно.
Накапливать в них фрагмент и потом его весь сбрасывать. Например, читая во внутренний буфер AT45DB какую-то страницу, дописывая в нужное место фрагмент из RTC, записывая этот буфер в массив со стиранием.И гарантированно "честно", и меньше стираний, меньше самих операций записи.
Цитата(ReAl @ Oct 6 2008, 20:40)
Может можно дописывать (имели ввиду всего лишь то, что без стирания не "запишутся" единички), может нет.
Перечитал раза три, тоже так и не понял, что они хотели сказать.
Цитата(Огурцов @ Oct 8 2008, 00:21)
Перечитал раза три, тоже так и не понял, что они хотели сказать.
Имеется в виду, что запись без предварительного стирания не полностью гарантирует сохранность "1", расположенных на кристалле поблизости от записываемых "0". Видимо у Atmel не совсем идеально разработана структура NOR- вентиля (полевика с "плавающим" затвором) и поэтому при записи "ноликов" в такой вентиль заряд "единичек" вентилей, расположенных по соседству, постепенно "стирается". Туннельный эффект во всем виноват, ёшкин кот! 
Так может вместо ноликов единички и записывать ? Т.е. стерли как положено, записали первый раз 0x12 0xFF 0xFF..., а второй раз записываем уже 0xFF 0x34 0xFF..., тогда единички деградировать не будут, а нолики, где были, в единички уж точно не превратятся при записи хоть что туда записывай.
Цитата(ReAl @ Oct 7 2008, 00:40)
Может можно дописывать (имели ввиду всего лишь то, что без стирания не "запишутся" единички), может нет.
Не удивлюсь, если фраза придумана юридическим отделом фирмы
Цитата(Огурцов @ Oct 8 2008, 01:59)
Так может вместо ноликов единички и записывать ? Т.е. стерли как положено, записали первый раз 0x12 0xFF 0xFF..., а второй раз записываем уже 0xFF 0x34 0xFF..., тогда единички деградировать не будут, а нолики, где были, в единички уж точно не превратятся при записи хоть что туда записывай.
Деградировать все равно будут, хотя возможно и меньше.
А просто складывать во внутренний буфер до заполнения оного, а затем переносить во флеш? Или боитесь потери данных?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.