ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
21 ноября
О смысле всего сущего0xFF Средства и методы разработки Мобильная и беспроводная связь Блошиный рынокОбъявления
МикроконтроллерыPLD, FPGA, DSP AVRPICARM, RISC-VТехнологии Кибернетика, автоматика, протоколы Схемы, платы, компоненты
1468615 Топик полностью
Adept (09.10.2024 00:13, просмотров: 91) ответил Nikolay_Po на У меня данные в EEPROM в двух экземплярах с контрольной суммой хранятся, а записи - нумеруются, износ - выравнивается. Даже если байт надо писать - пишу с номером записи и контрольной суммой. И пишу в ячейки (блоки) по очереди, чтобы износ распределялся по всей EEPROM, а не приходился только на один блок. Так и ресурс кратно вырастает (если запись многократно меньше объема EEPROM), и защита от отказа питания во время записи получается.
блочная запись имеет свои существенные минусы (во первых - сильно медленнее, чем "побайтовая мажлоритарка", во вторых. в случае сбоя понятно, что сбойный блок, но неясно какой байт и приходится обновлять весь блок из "резервной копии", я продумывал всякие/разные сценарии и понял для себя, что "мажоритарные процедуры" - самое то. А выравнивание ресурса 

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

Кстати, в вашей парадигме блочного контроля, - как Вы узнаёте, что байт сбойный? Читаете весь блок из EEPROM с контролем CRC? Это зело ненадёжно, т.к. долго, а в экстремальных условиях нужно максимально ограничивать работу с EEPROM по времени (и энергопотребление будет меньше, и вероятность сбоя сильно снизится). Да ещё и индексация (номер записи) у вас сильно сжирает объём ( чем меньше размер блока (а именно при уменьшении блоков проявляется эффект "выравнивания") тем больше "оверхед" (индексы, контрольные суммы). Думаю в реальных сценариях расход памяти будет сильно больше трёхкратного, необходимого для "мажоритарки". Кстати, мажоритарно я определяю только самые важные ячейки, те, которые не так важны (потеря информации в которых не ведёт к критическому нарушению функциональности), не резервирую.

И, кстати мажоритарные процедуры, практически не жрут памяти, т.к. оформлены макросами с п/п, и в исходниках видятся примерно так:

//вспоминаем свой идентификатор (Мажоритарные операции)
	Mj_XReadRepairValue_TMPfromEEPROM	E_Mj_MyDevID
	brts	StartUp_NoRegistered				;Если мажоритарное чтение возвратило признак неопределённости (ф."T"),
								;  то уходим на ветку "StartUp_NoRegistered"
	sts	S_MyDevID,TMP					;  иначе применяем считанный параметр
...делать нужно так, как нужно. А как ненужно - делать не нужно (С) Винни-Пух :)
Ответить