Argon (25.03.2010 10:48, просмотров: 21448) MBedder-
- Если денег куры не клюют можно применить вот это: Денис Ягов(128 знак., 07.04.2010 08:44)
- "размазать" на одной или нескольких страницах самое правильное решение, с одним но, если б это было eeprom где можно ячейки писать, а в предлагаемой флешке запись поблочная, но она имеет буфер, то значит в буфер пиши сколько влезет (там нет ограничений zimdip(71 знак., 05.04.2010 19:55)
- для защиты от провалов напряжения ионистор вместо кондера (лично для флешки). - zimdip(05.04.2010 19:59)
- если можно отдать страницу под счетчик, то первые пару байт указатель на адрес где лежит собственно счетчик, а счетчик проверять при записи на валидность. если что не так - сдвигать дальше. при этом младший байт должен быть первым. указатель будет AVF(35 знак., 05.04.2010 14:23)
- Не понял - отдать по странице на каждое значение счетчика или вообще одну страницу на счетчик? Argon(261 знак., 05.04.2010 14:39)
- Можно писать в буфер, а уж его переписывать по сигналу отключения питания. - General(05.04.2010 12:43)
- Будет уменьшаться но не так быстро: блок из нескольких страниц всё равно надо регулярно стирать, будет много записи без стирания -- будут глюки (где-то в даташитах сказано). Возможно и нет необходимости писать без стирания страницы. Возможно, достаточно fk0(417 знак., 25.03.2010 10:58)
- Как-то расточительно использовать целую страницу в 512 байт на пару чисел. Но может, без этого и не обойтись. - Argon(25.03.2010 11:55)
- Нужно "размазывать" по всей странице. Типо ID записи и по ней определять последнюю запись. Или же FRAM - megajohn(25.03.2010 12:14)
- Вот-вот, про размазывание по одной странице и был изначальный вопрос! Argon(226 знак., 25.03.2010 12:18)
- Зачем так ? Вообще, делают типо INT на провал напряжения и на буферном конденсаторе проивзодиться запись - megajohn(25.03.2010 13:18)
- похоже, мы о разном говорим. мне не надо отслеживать провал напряжения и завершать запись до конца. Argon(382 знак., 25.03.2010 13:29)
- "И ее надо восстанавливать при последующем включении." ну вот и идет сохранение из ОЗУ в ПЗУ по выключению питания - megajohn(25.03.2010 15:10)
- ну да, а в какое место ее записывать, чтоб флэшка сдохла не через месяц, а, скажем через 10 лет? - Argon(25.03.2010 15:35)
- зависит от частоты выключений. Но вы выбрали самое неудачное - NAND, лучше бы NOR (EEPROM) или FRAM - megajohn(25.03.2010 15:55)
- Нее, атмеловская dataflash как раз NOR - Argon(25.03.2010 18:01, ссылка)
- зависит от частоты выключений. Но вы выбрали самое неудачное - NAND, лучше бы NOR (EEPROM) или FRAM - megajohn(25.03.2010 15:55)
- ну да, а в какое место ее записывать, чтоб флэшка сдохла не через месяц, а, скажем через 10 лет? - Argon(25.03.2010 15:35)
- всякую задачу можно решить по-разному koyodza(572 знак., 25.03.2010 14:17)
- Все варианты НЕ ИСКЛЮЧАЮТ необходимость хранения более чем одной копии данных. - fk0(25.03.2010 15:36)
- +1 - zzz(26.03.2010 14:34,
)
- +1 - zzz(26.03.2010 14:34,
- Все варианты НЕ ИСКЛЮЧАЮТ необходимость хранения более чем одной копии данных. - fk0(25.03.2010 15:36)
- "И ее надо восстанавливать при последующем включении." ну вот и идет сохранение из ОЗУ в ПЗУ по выключению питания - megajohn(25.03.2010 15:10)
- похоже, мы о разном говорим. мне не надо отслеживать провал напряжения и завершать запись до конца. Argon(382 знак., 25.03.2010 13:29)
- Зачем так ? Вообще, делают типо INT на провал напряжения и на буферном конденсаторе проивзодиться запись - megajohn(25.03.2010 13:18)
- Вот-вот, про размазывание по одной странице и был изначальный вопрос! Argon(226 знак., 25.03.2010 12:18)
- Нужно "размазывать" по всей странице. Типо ID записи и по ней определять последнюю запись. Или же FRAM - megajohn(25.03.2010 12:14)
- Да и CRC, а лучше сумму или, возможно, flatcher sum или adler sum для блока иметь надо. На случай недо-стирания недо-записи (из-за сбоя питания). Сумма надёжнее CRC -- см. сообщения тут: fk0(165 знак., 25.03.2010 11:01)
- ИМХО LRC применяется на потоковых сообщениях, а на фреймовых все же CRC. К какому типу информации отнести запись во Flash или EEPROM, что-то сходу не соображу. Т.к. это зависит от структуры записей. Однако, например, в стандарте VESA rezident(476 знак., 25.03.2010 22:50 - 22:52)
- ..чушь полная. Прописываю Тутевича, для начала. - blackbit(25.03.2010 21:56)
- Ну да, а мужики то, разработчики CAN, Ethernet, 1-Wire? Modbus... не знают, что "Сумма надёжнее CRC" :). Я так понимаю, что как раз CRC выгодна в последовательных протоколах возможностью контроля изменения отдельных битов. Возможно, что сумма, в случае Chum_A(103 знак., 25.03.2010 13:11)
- Мужыки могут дальше использовать CRC. Сумма надёжнее CRC в конкретных условиях, там по ссылке написано каких именно (моё оригинальное письмо). CRC же надёжнее защищает от перестановок, вставок и гарантированно от искажений коротких последовательностей fk0(91 знак., 25.03.2010 13:22)
- CRC много разных. Полином их образующий выбирается исходя из предпологаемого распределения ошибок в канале связи. - 11111(25.03.2010 14:55,
)
- "Вероятность сбоев в ППЗУ вида FFFFF... или 0000... -- очевидна, если сбоит питание". Это конкретный результат исследования конкретной серии микросхем по конкретной методике или личное мнение автора? - Chum_A(25.03.2010 13:47)
- Это особенность алгоритма. Который вначале стирает, потом пишет. Сбой может быть между операциями. - fk0(25.03.2010 15:34)
- А во время операции не может быть по определению? - Chum_A(25.03.2010 15:39)
- Сбой питания во время операции записи как раз и приведёт к тому, что хвост записи останется в стёртом состоянии. - ReAl(25.03.2010 22:31)
- Гм. А где указано, что CRC обязательно в конце записи должна быть? - rezident(25.03.2010 22:39)
- А это не важно где будет CRC. Сам факт, что длинный об 0xFF-ченный хвост может дать совпадение CRC и вероятность там заметная в практических условиях. vs сумма которая просто тупо гарантирует (но не ловит эффективно другие ошибки) - fk0(26.03.2010 12:30)
- Уважаемые (-fk0), ну с чего Вы взяли, что при деградации (пост изначально был про деградацию) или при сбое записи/стирания в ячейке обязательно будет 00 или FF. Да что угодно может быть, на древних РФ-ках вон даже плавающие биты для сохранности копирайта Chum_A(12 знак., 26.03.2010 11:13)
- Речь про отключение питания, а не про деградацию flash в результате могочиесленных перезаписей (этого просто не должно происходить за срок жизни прибора). С чего взял... Да с того, что принцип flash такой, что либо нулей на массив массово больше станет fk0(91 знак., 26.03.2010 12:32)
- Вы хоть и хам, но отвечу. Вот идет процесс записи слова в ячейки. Т.е. физически заливаем заряд в затвор МОП-а. "0" или "1" величина пороговая. Нет 100% уверенности, что если процесс заливки прервать (сбой питания), то уровни в разных ячейках слова Chum_A(77 знак., 26.03.2010 13:52)
- ЕЩЁ РАЗ ПЕРЕЧИТЫВАЙТЕ МОЁ СООБЩЕНИЕ. Надоело уже спорить тут с тугодумами. При стирании, очевидно, происходит только объединичивание ячеек. При записи -- только ОБНУЛЕНИЕ. При записи нулевая ячейка в один не установится, как и наоборот, при стиранни fk2(247 знак., 04.04.2010 18:18, )
- Может я и "тугодум - пользующийся приёмами литературной полемики помноженными на сомнительный авторитет", но на личности в тех. споре не перехожу. Надоело, спор с переходом на личности бессмысленен. - Chum_A(04.04.2010 18:32 - 19:15)
- В Atmele тоже сидят тугодумы :) Chum_A(05.04.2010 11:20, ссылка)
- Может я и "тугодум - пользующийся приёмами литературной полемики помноженными на сомнительный авторитет", но на личности в тех. споре не перехожу. Надоело, спор с переходом на личности бессмысленен. - Chum_A(04.04.2010 18:32 - 19:15)
- ЕЩЁ РАЗ ПЕРЕЧИТЫВАЙТЕ МОЁ СООБЩЕНИЕ. Надоело уже спорить тут с тугодумами. При стирании, очевидно, происходит только объединичивание ячеек. При записи -- только ОБНУЛЕНИЕ. При записи нулевая ячейка в один не установится, как и наоборот, при стиранни fk2(247 знак., 04.04.2010 18:18,
- Вы хоть и хам, но отвечу. Вот идет процесс записи слова в ячейки. Т.е. физически заливаем заряд в затвор МОП-а. "0" или "1" величина пороговая. Нет 100% уверенности, что если процесс заливки прервать (сбой питания), то уровни в разных ячейках слова Chum_A(77 знак., 26.03.2010 13:52)
- Речь про отключение питания, а не про деградацию flash в результате могочиесленных перезаписей (этого просто не должно происходить за срок жизни прибора). С чего взял... Да с того, что принцип flash такой, что либо нулей на массив массово больше станет fk0(91 знак., 26.03.2010 12:32)
- Гм. А где указано, что CRC обязательно в конце записи должна быть? - rezident(25.03.2010 22:39)
- Сбой питания во время операции записи как раз и приведёт к тому, что хвост записи останется в стёртом состоянии. - ReAl(25.03.2010 22:31)
- А во время операции не может быть по определению? - Chum_A(25.03.2010 15:39)
- Это пустопорожний трёп Chum_A который в умной книжке о CRC читал, а до его свойств не дошёл. - fk0(25.03.2010 15:33)
- Чего-то Вы, дорогой товаристЧ в буденовке, на личности переходите, от недостатка аргументов что-ли? - Chum_A(25.03.2010 15:37)
- Это особенность алгоритма. Который вначале стирает, потом пишет. Сбой может быть между операциями. - fk0(25.03.2010 15:34)
- CRC много разных. Полином их образующий выбирается исходя из предпологаемого распределения ошибок в канале связи. - 11111(25.03.2010 14:55,
- Мужыки могут дальше использовать CRC. Сумма надёжнее CRC в конкретных условиях, там по ссылке написано каких именно (моё оригинальное письмо). CRC же надёжнее защищает от перестановок, вставок и гарантированно от искажений коротких последовательностей fk0(91 знак., 25.03.2010 13:22)
- Не великий я спец в достоверной передаче данных, но попробовал (modbus CRC16 + готовый бинарный файл к CRC в двух последних байтах) затереть хвост файла (пара десятков байтов из 362) как FF-ами, так и нулями. И появляется разница. Что-то в консерватории? - Toчкa oпopы(25.03.2010 12:50)
- Точно что-то в консерватории. Идите и читайте на rsdn.ru. - fk0(25.03.2010 13:23)
- Как-то расточительно использовать целую страницу в 512 байт на пару чисел. Но может, без этого и не обойтись. - Argon(25.03.2010 11:55)