Есть необходимость использовать в приборе флешку приличной емкости (8-16 мбит).
Почитал про NANDы, испугался - гарантированных циклов записи/стирания нет (кроме первого сектора). Надо реализовывать ремап сбойных секторов. Надо размазывать запись чтобы часто перезаписываемые сектора (например FAT) не умерли через неделю.
Я правильно понимаю, что в SD флешке это уже все реализовано?
И еще - краем уха слышал, что бывают SD флешки в корпусе под пайку, с ногами. Подскажите где искать (или по каким словам).

Да, все так. С одной оговоркой - никто не указывает, как реализовано размазывание, и реализовано ли вообще.

я думаю в SD размазывания записи нет
размазывание новерно начали использовать только в SSD накопителях
а в SD только запись с ECC и замена сбойных секторов

SD флешки в корпусе под пайку не встречал
если и есть то большая редкость

если хочется именно SD то проще поставить microSD

Лучше всего вам подходит память RAMTRON, NANDы для гругих целей,
контроллер в SD занимается в основном FATом и CRC. Никакого размазывания там нет.
Поищите Datasheet на SD от компании Smatr, там все описано.
Вроде у ATMELA есть SD флешки в корпусе под пайку.

Занимается и меняет алгоритм записи. Размазывает!
Лучше купить Developer Kit - все станет понятно, хоть и не все описано.

epic fail!
не стоит фантазировать ЮВГ, и не сбивать с толку народ, требуется знать!
Размазывания нет и не может быть, и что это за термин размазывание? Откуда такие слова берете?!
(А если оно есть, докажите, для чего это нужно, ну очень интересно будет узнать!)

Смотрим спецификацию на SD memory card, нет ничего о размазывани.
...и хто ето там меняет алгоритм записи!? и зачем это?! где и кто должен запоминать эти изменения?

А если вас беспокоит многократная запись в одну и туже ячейку,
FAT этого не позволяет, поскольку по спецификаци FATа,
перезапись делается в соседний сектор, стирая затем предыдущий.
Таким образом заполняется последовательно вся матрица памяти, затем по кругу.

( несколько лет назад разбирались с SD и использовали в нескольких проектах)
не упомянул только SPI интерфейс для внешнего подключения.

Посмотрите описание какой нибудь NAND-флеш, и подумайте, можно ли эффективно работать с памятью без логической адресации блоков и wear-leveling.


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


FAT'ом он не занимается, и никогда не занимался.

Для таких объемов nand не нужен. Ставьте M25P16 или dataflash и не мучайтесь. Для работы с nand памятью потребуется значительное кол-во ресерсов.

А что по-вашему содержит SD-карта, помимо контроллера? Погуглите FTL - это как раз то, чем в основном
занят контроллер SD-карты.


Что же в новых-то?


Так, а откуда взялось "стираем"? Или иначе файл переписать нельзя?


Все, что касается обслуживания файловой системы, делает хост. Контроллер внутри карты знать ничего не знает о файловой системе
(ну, разве что в CSD может быть три бита записано, и то нужны они для хоста, а не для контроллера карты).

Код команды "формат" не подскажете?

Так про размазывание поясните чё нибудь, а то народу интересно?.

А вот где таблицы FATа расположены?
А как хост узнает что там FAT? и какой, и куча файлов? Кто ему говорит?

Команда формат (форматирование) дается с PC, как для обычных дисков. Можете
форматить SD как FAT-16.

SanDisk SD Card Product Manual:

Wear leveling


А вот читает сектора из памяти, и узнает. И дело контроллера только эти сектора хосту отдать, не вдаваясь в подробности.


Бред, и про "обычные диски" тоже. Все форматирование сводится к записи на диск структур FAT или другой файловой системы, контроллер понятия не имеет, что его заставляют писать в данный момент.

Судя по вашим репликам, вы не знаете:
- как происходит запись/стирание NAND-флеш
- чем занимается контроллер на SD-карте
- как устроена и как работает FAT

Объяснять все эти пункты вам персонально не имею ни малейшего желания.


Со столь глубокими познаниями вы в этих проектах могли разве что свечку держать.


добили. О чем тут можно говорить еще.

понятно, ... вообщем не способны вы пояснить то.

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

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

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

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

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

спасибо!

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

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

Процент должен быть в 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 использовать?

Да. Но для диктофона можно этот момент "упростить", т.е. не считать 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 городить

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

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

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

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

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

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

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

да,но crc тоже может исказится как тогда быть? держать еще нсеколько crc?

Вероятность того, что исказятся и данные и CRC, да еще так, чтобы CRC осталась верной, много меньше, чем вероятность искажения двух битов на одинаковых позициях в разных записях.

И конечно всегда возможен вариант полной ж., но так жизнь устроена, ничего не поделаешь.

а если исказится CRC, и пару бит в разных записях?
вариант полной ж. не берем во внимание. но ситуация, с искаженной crc и данных на всего каких-то 136битах есть немаловероятная

Это как раз и есть вариант "полной ж". В огромном числе случаев довольствуются ECC с корекцией одного бита на 512 байт данных.

из доки микрона, на конкретную память:
"Minimum required ECC 1-bit ECC per 528 bytes of data"
это означает, что в 528байтах, может быть ошибка только в одном бите из 4224?
если да, то достаточно 3-4 раза записать одно и тоже 32битное число...

Это значит, что ECC может исправить одну ошибку на 4224 бита. Т.е. много и сразу отваливаться не должно.


Ох, ну зачем 4-я запись-то? Что Вы с ней делать будете?

понял ,спасибо!

для круглости чисел
процу проще будет обработать if(!(x&3)), чем if(x!=3). конкретному процу, в смысле. был бы avr, там до лампочки.
хотя такая мизерная оптимизация не даст никакого выиграша

вот нашёл интересное исследование на тему "чем занимается контроллер в USB/SD флешках":
https://wiki.linaro.org/WorkingGroups/Kerne...FlashCardSurvey

пытаюсь разобраться в том, что там написано

Я бы посмотрел здесь - http://www.micron.com/products/managed-nand/e-mmc