microSD задержки при обмене, есть ли способы борьбы ? Опции

[MiklPolikov]

На microSD карту пишется поток данных. Поток непрерывный, буфера RAM нет, карта периодически останавливает обмен на доли секунды.
Интерфейс SDIO 48МГц , на карте FAT32 , библиотека для работы c FAT FATFS.

Вопрос:
Можно ли избавится от задержек в обмене ? Может быть, в современных картах появились какие-то хитрые настройки для этого ? Может быть, есть карты со встроенным буфером RAM ?

Заранее спасибо !

[makc]

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

Число циклов перезаписи современных MLC/TLC NAND Вы знаете, почему же карты живут несколько дольше?
Вот статья 2003 года, отчасти подтверждающая мои слова про наличие механизмов выравнивания износа.

[jcxz]

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

Да я допускаю что внутри там может быть более сложная организация. Я и писал что возможно там есть буферизация потока записываемых блоков (о чём косвенно свидетельствует алгоритм работы команды многоблочной записи).
Но в спецификации это явно не указано! Т.е. - не указано что карта должна это делать. Какой-то конкретный производитель может конечно захотеть и реализовать внутри всё что угодно: и вести статистику использования блоков и даже перемещать самые популярные блоки не только по всему массиву блоков, но и в отдельную память, например FRAM и многое другое.
Но только - зачем ему оно надо? Тратить ресурсы на более сложную разработку, тратить лишние вентили на весь этот механизм, может их лучше потратить на доп. ячейки флешь и сделать бОльшую ёмкость?
Ведь главная цель изготовителя - извлечение прибыли и уменьшение издержек. И если оно не требуется спецификацией, то может кто так и будет делать, то такие карты ТСу ещё найти надо.

Число циклов перезаписи современных MLC/TLC NAND Вы знаете, почему же карты живут несколько дольше?

И что? Число циклов перезаписи не говорит, что по достижении этого значения, блок сразу откажет. Это минимальное число стираний которое блок должен выдержать, а в реале может в разы больше выдержать.
Вот я сейчас разбираюсь с регенерацией SDRAM. Так вот провожу испытания - выключаю регенерацию и измеряю сколько данные продержатся без регенерации. По даташиту регенерацию надо выполнять не реже чем раз в 64мсек, т.е. хранение данных без регенерации более 64мсек не гарантировано.
А в реале (заполняю всю SDRAM 32МБ псевдослучайными значениями и через заданное время проверяю всю целиком) разрушение данных наблюдаю только после отключения регенерации на 3-4 сек и более.
Если на 1 сек отключить регенерацию, то данные 100%-но сохраняются.

[IlyaSergeev]

Некоторое время назад выкладывал мини-отчет по производительности записи на SD в непрофильной теме:
http://electronix.ru/forum/index.php?showt...32833&st=31
Краткий вывод - от задержек в десятки и даже сотни мс не избавиться, но при правильной организации структуры памяти можно радикально уменьшить их количество.

[MiklPolikov]

Некоторое время назад выкладывал мини-отчет по производительности записи на SD в непрофильной теме:
http://electronix.ru/forum/index.php?showt...32833&st=31

IlyaSergeev, большое спасибо ! Выравнивание адреса на 0x8000 заметно улучшило дело ! . Но редкие нерегулярные задержки 400мс при использовании FATFS остались.

[makc]

IlyaSergeev, большое спасибо ! Выравнивание адреса на 0x8000 заметно улучшило дело ! . Но редкие нерегулярные задержки 400мс при использовании FATFS остались.

FATFS написан неэффективно и чуть что лезет писать в FAT, причём пишет совсем понемногу. Поэтому для оптимизации доступа имеет смысл сделать промежуточный слой доступа к носителю (типа кэша), который будет накапливать эти модификации и потом редко записывать единым блоком. И, кстати, стоит обратить внимание на то, как FatFS сконфигурирован. Надеюсь у Вас _FS_TINY == 0 ?

[mantech]

FATFS написан неэффективно и чуть что лезет писать в FAT, причём пишет совсем понемногу. Поэтому для оптимизации доступа имеет смысл сделать промежуточный слой доступа к носителю (типа кэша), который будет накапливать эти модификации и потом редко записывать единым блоком. И, кстати, стоит обратить внимание на то, как FatFS сконфигурирован. Надеюсь у Вас _FS_TINY == 0 ?

Т.е. предлагаете делать прослойку типа SmartDrv в старом мс-досе?? А вы в курсе, что при этом можно очень легко нарушить целостность файловой системы при сбое или отключении питания? Сколько было потрачено сил и убеждений в свое время, чтоб не жали на ресет по делу и без дела в старых компах... Хотя да, на древних винтах ускорение было заметным.

[makc]

Т.е. предлагаете делать прослойку типа SmartDrv в старом мс-досе??

Да, что-то вроде, только более специализированной и заточенное под конкретную задачу.

А вы в курсе, что при этом можно очень легко нарушить целостность файловой системы при сбое или отключении питания? Сколько было потрачено сил и убеждений в свое время, чтоб не жали на ресет по делу и без дела в старых компах... Хотя да, на древних винтах ускорение было заметным.

Естественно в курсе, но FAT и так не является отказоустойчивой ФС, по определению. И состояние ФС не гарантируется при отключении питания во время выполнения операции записи. С этой точки зрения мое предложение не ухудшает характеристик получаемого результата.

Вы с логикой дружите??? Я без понятия откуда Вы это взяли.

Я с логикой вполне дружу. Взял я это из Вашего же сообщения в этой теме:

И вообще - где все эти операции перемещения/перераспределения/...? В SD-карте? Вы уверены? Где блоки разного размера и выравнивание износа? Вы не путаете с какими-то другими типами flash-памяти?
Из спецификации SD:
....

Или Вы этого не писали?

Ведь это Вы утверждаете наличие неких механизмов внутри SD, поэтому я и спрашиваю - есть документальные подтверждения или это только Ваши
домыслы ничем не подкреплённые?

Я давал подтверждения выше по теме. В ответ Вы мне написали, что:

Но в спецификации это явно не указано! Т.е. - не указано что карта должна это делать. Какой-то конкретный производитель может конечно захотеть и реализовать внутри всё что угодно: и вести статистику использования блоков и даже перемещать самые популярные блоки не только по всему массиву блоков, но и в отдельную память, например FRAM и многое другое.

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

А Вы пробовали? 1000 раз стёрли и на 1001-й раз получили отказ?

Пробовали не с картами памяти, с флешом типа NAND. Требования выравнивания износа при использовании NAND взялись не из воздуха, а из практической необходимости. О чем я Вам и пытаюсь уже несколько раз сказать.

И исходя из чего же производитель назначает этот самый гарантийный срок? Вы считаете это как-то связано с числом циклов перезаписи??

Безусловно. И с механизмами, реализованными в носителях. В противном случае поток рекламаций сведёт на нет всю выручку. А крупные производители умеют считать деньги.

К вопросу о надёжности поинтересуйтесь рекомендациями того же Micron'а относительно eMMC. Пару слайдов прикрепил к этому сообщению.

Что именно Вы хотели этим сказать?

Ровно то, что и сказал: Ваши слова не аргумент возможно огромного числа циклов перезаписи или огромного запаса надёжности, заложенного производителем "на всякий случай".

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

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

Эскизы прикрепленных изображений

 

[jcxz]

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

Я тоже такой не знаю, у меня только есть:
1. SD Specifications. Part 1. Physical Layer. Simplified Specification. Version 3.01. May 18, 2010
2. SD Specifications. Part A2. SD Host Controller Simplified Specification. Version 2.00. February 8, 2007
3. SD Specifications. Part E1. SDIO Simplified Specification. Version 2.00. February 8, 2007
И я там не находил ничего, подтверждающего наличие внутри SD механизмов перераспределения износа. Хотя может что и пропустил, так как не изучал от корки до корки.

Пробовали не с картами памяти, с флешом типа NAND. Требования выравнивания износа при использовании NAND взялись не из воздуха, а из практической необходимости. О чем я Вам и пытаюсь уже несколько раз сказать.

Требования эти может выполнять например ПО системы, куда подключена SD. Т.е. - прослойка между например FatFS и интерфейсом SDIO/SPI карты. А не контроллер SD-карты, который останется "тупым". Нужно более эффективное использование SD при интенсивных модификациях - вносите соотв. драйвер в ваше firmware. А для подавляющего большинства применений SD-карт это не нужно и не нужно производителям париться добавляя эту мало кому нужную функцию в контроллер SD, тратя на это ресурсы SD-карты.

Но нужно понимать, что к разрушению данных во флеше приводит даже чтение, что роднит его с DRAM, в некотором смысле.

Да ну!!? А как же тогда работают например флеши программ микроконтроллеров, из которых код может читаться на скоростях около 20-30МГц???
Это что-ж - написали коротенький цикл while () {}, включили, поработала программа несколько суток и адье! - стёрлась!
К деградации ведёт только стирание.