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 ?

[jcxz]

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

У ТСа нет ОЗУ даже для буферизации основного потока, не то что ещё и FAT. Ведь в этом-то и вся проблема. Если-б ОЗУ было - проблемы и не было-бы: выкинуть вообще любую файловую систему и писать просто поток блоков на SD через буфер.

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

Эти "прослойки" есть и на современных компах. Иначе - операции с мелкими файлами на SD становятся оооооочень затратны по времени. Да и на МК при интенсивных модификациях файлов, кеширование очень полезно.
А чтобы не слетали файловые системы - тут разработчик, на этапе проработки идеологии всей системы в целом, должен голову включить и подумать как этого добиться (или супервизиром питания, дающим запас времени после сигнала аварии питания; или дополнительной non-volatile памятью, в которую ПО будет делать журналирование любых критических операций с файловой системой; или ещё какими другими методами).

[MiklPolikov]

Если-б ОЗУ было - проблемы и не было

Если б были ОЗУ в небольших корпусах с каким-то примитивным интерфейсом. А то они все с параллельной шиной, из-за чего у микросхемы и процессора много ног т.е. либо огромные корпуса, либо BGA. Габариты критичны, а BGA дорого

[_4afc_]

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

Приведу пример про конкретный чип на основе родственника SDcard - eMMC:

In addition to the mass-storage-specific flash memory chip, SanDisk eMMC includes an intelligent controller, which manages interface protocols, data storage and retrieval, error correction code (ECC) algorithms, defect handling and diagnostics, power management, wear leveling, and clock control.

Ещё раз: Где в спецификации SD говорится, что карта что-то там внутри себя переписывает???? Дайте ссылку.

Приведу пример из стандарта 84-A441 на eMMC:

Terms and definitions:
Copies: Copies of erase group(s) or copies of write groups shall be defined as copies of data that are generated by the deviec controller during internal device controller operations. These can include (but are not limited to) copies generated during error handling, wear-leveling or garbage collection. Copies does not refer to write block data, at a specific address. This overwritten data may still remain in the memory array but is no longer accessible by the host. If this data must be secure trimmed, it is the host application’s responsibility to mark this data for secure trim prior to the overwrite event.

Ну и при вызове Trim:

Since the minimum size for an erase operation is an erase group and a write group is smaller than an erase group. The trim operation implies that write blocks in an erase group that are not marked for erase
must be copied to another location before the erase is applied.

Вообще ничего волшебного в Trim нет, просто он позволяет посекторно флушить память. Другое дело непонятно, можно ли на MLC вообще не вызывать TRIM, ERASE или ACMD23?

Протестировал тут стирание группы в моей eMMC через CMD35,CMD36,CMD38: при стирании 2/20МБ - то 30мс, то 2 секунды, в не зависимости от длины и наличия данных.