Микроконтроллеры

Данные не хранятся как есть, а циклически перезаписываются по кругу а-ля JFFS. Допустим, используетеся для чего 4 страницы (16кБайт). Допустим, размер записи 256 байт и, таким образом, в каждую страницу помещается 16 записей. Итого во весь выделенный объём можно записать 64 записи. И после записи такого количества будет стираться очередная конкретная страница. Т.е. реальный ресурс вырастает в 64 раза при увеличении в 64 же раза объёма используемой памяти сверх минимально необходимого. И на самом деле практически всегда в N раз при увеличении объёма на N. Теперь сравним AT24C1024 и SST25VF032B, например. У первого минимум 100тыс. циклов, у второго 10тыс. циклов. Т.е. разница по ресурсу в 10 раз. Но у EEPROM объём памяти 128кБайт, а объём памяти у NOR flash -- 4МБайт, т.е. в 32 раза больше. И, как не сложно заключить, ресурс получается, примерно в 3.2 раза больше, на самом-то деле, при хранении одинаковых объёмов информации. А ведь NOR flash может ещё использоваться для хранения read only данных, где EEPROM вовсе не рационален... И это всё -- в одной микросхеме. Дальше больше. В EEPROM на самом деле нет побайтовой записи. Вас где-то обманули. Она побайтовая была в старых микросхемах с очень мальенькими объёмами. В той же AT24C1024 запись блоками по 256 байт. И работает она примерно так же как и AT45DBxxx: когда меняется один байт в блоке из 256 байт, то считывается блок целиком во внутреннее ОЗУ микросхемы, меняется байт, блок стирается и записывается заново. Микросхемы EEPROM меньших объёмов устроены аналогично, но там могут быть меньшие объёмы блока, 8 байт, 16 байт, 64 байта... Из этого следует неприятное следствие -- сбой (питание, например) в момент записи может испортить весь блок настроек прибора, например, а не только записываемый байт. Но это на самом деле даже не важно. Потому, что сбой при записи этого единичного байта тоже может нарушить дальнейшую правильную работу прибора в целом. Более того, обычно программы записывают не отдельные байты (если это не программмы проф. уровня), а цельные структуры данных, где отдельные элементы между собой тесно увязаны. И не дай бог, записать только половину структуры и оборвать запись на середине. Работать опять же не будет. Элементарный пример: записывалось 16-битное число и записался только первый байт. Из этого следствие: настройки прибора, например, должны храниться (дублироваться) по меньшей мере в двух независимых страницах flash памяти (вне зависимости, EEPROM оно или нет), чтоб при записи одной, если произошёл сбой, осталась вторая и наоборот. И блок настроек должен быть защищён чем-то вроде CRC для проверки правильности записи. И чем-то вроде серийного номера записи, для выбора последнего блока из двух. И чем-то вроде magic number, потиму, что CRC или сумма от массива нулей или FF может прекрасно совпадать с тем же нулём или FF. И раз уж мы по такой методике умеем записывать два блока, то совершенно не сложно записывать и любое число блоков в любом объёме памяти циклически, по кругу, стирая страницы при записи в начало очередной новой страницы. И искать при старте прибора последнюю запись по максимальному серийному номеру. Приходим к тому, что я писал в начале сообщения. Отвечаю на вопрос, также, мол "мы поставим волшебный конденсатор и сбоев не будет". Когда я говорю сбой, я не подразумеваю только и исключительно отключение питания. Хотя, это наиболее частая причина обрыва записи. Запись (не байта, а их последовательности) может быть прекращена и из-за прекращения работы программы, например, что может произойти в свою очередь по массе разных причин, включая программные ошибки, внешние сигналы и т.п. Это тоже очень вероятная причина. Работа МК может быть нарушена под воздействием электростатических и электромагнитных полей, включая радиацию, космические лучи и т.п. И не только МК, но и источника питания прибора, к слову, или любого произвольного компонента в котором случиться latchup. И схемотехнически волшебный конденсатор предусмотреть достаточно сложно. Только в очень простых схемах, где кроме МК ничего нет. А в любой достаточно сложной кроме МК есть огромная масса других компонентов, которые во время программирования EEPROM живут своей жизнью и контролировать их потребление хотя бы сложно.