Пояснять, простите, в Ваших измышлениях просто нечего. Но нельзя было молча наблюдать за распространием ахинеи.

Epic Fail произошел как раз у тов. Aner'а
Интересно, как он сможет объяснить свои слова про то, что контроллер в SD рулит FATом. И ничего, что на карту можно записать любую другую файловую систему, или даже вообще не использовать ФС, а работать с ней как с массивом блоков.

Можно, кстати, SD карточку осторожно расковырять, там вполне паябельная платка будет.

сам наржался )

еще вопрос немного не в тему SD, но в тему Wear Leveling...
Есть девайс (а-ля диктофон) пишущий последовательно данные в NAND. но он также может фиксировать время отсутствия данных. изначально я сделал, чтобы с каким-то периодом он сбрасывал подряд биты группами по 32 бита подряд на текущей странице. потом вычитал в мане, что страницу можно писать до 4х раз тк стереть можно только блок, то реально памяти не хватит, чтобы это все обработать. да и времени тоже (контроллер стоит C8051F93x/92x ). читал, что если этот лимит перепрыгнуть, то могут сбрасыватся другие биты в странице...
с этого следует, что инфа про фикс. интервал времени отстутствия данных будет занимать страницу. страниц мало и запомнить можно очень ограниченное количество временных фиксов...
есть ли какие-то методы обхода с малыми затратами ресурсов?
частота данных 44000байт/сек. проц 24.5мгц. памяти 4кб, 2кб используется для кеша страницы...

спасибо!

Сообщение отредактировал brag - Jun 15 2009, 12:44

ИМХО, со столь скромными ресурсами все равно придется бросать страницу после 4-х записей. Ну, и писать пореже.

и я к тому же склоняюсь. или вообще забить болт, писать ифу о времени отсутствия данных только при приходе новых данных. при потере питания,ессно инфу потеряем.
там еще одна возня есть с битыми блоками..их тоже надо учитывать..какой обычно максимальный процент их может быть на SLC флешке(512мб)? и может ли это число сильно расти со временем?

Сообщение отредактировал brag - Jun 15 2009, 13:28

Процент должен быть в DS, обычно не более 2%.


Увы, может.

в ДС написано, что мин количество валидных блоков 4016 из 4096 "when shipped from the factory"...
тоесть это означает, что со временем, количество битых блоков может стать больше, чем 80, скажем, через год ?
в даташите на другую память(гнусмас) сказано "However, the total number
of available blocks will not fall below Nvb during the endurance life of the product."
но в даташите на эту память (MT29F4G08ABC) такого не сказано

Nvb - number of valid blocks

к стати, там еще и о ECC написано. "The first block (physical block address 00h) for each CE# is guaranteed to be valid with ECC when shipped from the factory"
тоесть, чтобы иметь достоверные данные, нужно еще и ECC использовать?

Сообщение отредактировал brag - Jun 15 2009, 13:54

Да. Но для диктофона можно этот момент "упростить", т.е. не считать ECC для звука, а защищать только служебные записи.

для звука можно и на битые блоки писать. в других доках микрона написано подобное, что и на самсунг..значт можно доверять. "Additional bad blocks may develop over time; however, the total
number of available blocks will not drop below Nvb during the endurance life of the device."
спасибо!
пойду ecc городить

Сообщение отредактировал brag - Jun 15 2009, 14:09

смотрел всякие разные алгоритмы ECC, но чет ничего не подобрал простого. Рид-соломон и Хемминг жоркие. Варшамов вобще не подошел.
мне нужно защитить всего лишь 4 байта. можете посоветовать легковесный алгоритм для этого?
можно, конечно записать 4 раза под ряд копии этих 4 байт и считать валидными те, что имеют наиболее одинаковых совпадений. ни чет мне не совсем нравится такой лобовой подход

Можно сделать 8 бит ECC на 32 бита данных, хотя мне и мажорирование представляется вполне нормальным вариантом.

а какой алго для этого взять? избыточность не критична. главное - легковеснисть по процессорному времени.

мажорированием называется тот вариант в лоб, что я предложил?

Да. Если избыточность не критична, то его и взять, ИМХО.

спасибо! значит сделаем 4кратную избыточность. можно еще 1 байт простейшего crc для надежности

Скорее нужно, иначе что будете делать, если в двух записях '0', а в других двух '1'?