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_]

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

Можно пойти другим путём:
1. Например 4х проводный интерфейс у меня пишет быстрей однопроводного.
2. Взять контроллер с большей внутренней памятью.

Кстати карта имеет право осуществлять запись доли секунды. У моей, согласно даташиту - 250мС. Поэтому я, для надёжности, всегда использую внутренний буфер более чем на четверть секунды.