День добрый!
если у кого есть опыт, был бы весьма признателен за ответ на следующий вопрос:

утрированно задача следующая -
есть необходимость считывать с SD карты данные из разных файлов, причём относительно мелкими порциями (килобайт по 16). Т.е допустим на карте 1000 файлов, необходимо открыть их все и последовательно считывать,
из первого файла 16 кило, из второго 16 кило итд, и так по кругу, складывая это в буфера в озу.

Так вот в разрезе этой задачи интересуют оценки сверху по времени на следующие операции -

1 - переключение чтения с одного файла на другой (получается переключение с одногосеткора на другой, для нанд флэши эти данные есть, но ведь в карте свой контроллер)

2 - время открытия файла, если это FAT

А если файлов не 1000 а 64 допустим?

чтение будет требоваться, примерно 3-6 мегабайт в секунду...

Сорри за расплывчатое объяснение, необходимо понять стоит ли покупть отладочную плату для опытов в принципе - или затея изначально не решаемая.

По АРМ-ам - смотрю в сторону атмелов SAM9X или NXP (по перефирии подкупает новая серия 3130, но отладочные платы видимо будут ещё не скоро...), у них есть SDIO - тюе можно получить (видимо) вменяемую скорость...

Спасибо!

Смотри разницу между CMD_17 (READ_SINGLE_BLOCK) и CMD_18 (READ_MULTIPLE_BLOCK).
Грубо говоря, задержка на выдачу и респонс одной команды.


Читаеш один раз фат во внутреннее озу и работай с ним.


Я на SAM7S делал 1.5, а там SDIO нет. ПЛИСина помогала. Так что думаю, вполне возможно.
А если SDHC так уж точно.

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

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

т.е это десякти микросекунд, сотни, или милисекундны...

Думается мне, что держать "открытыми" 1000 файлов уже дело хорошее. Дла начала можно было бы это дело испытать на PC. USB-ный reader не так уж медленно работает.

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

Для SDIO думаю выложу результаты, а вот для SPI 20 МГц на ARM 100 МГц мной был для FAT получен результат: открытие файла - 2.5...10 мс, закрытие файла - 8...10 мс. Очень предварительно, статистика буквально с нескольких попыток.

Самое большое влияние на скорость оказывает состояние самой SD карты. Собственно оно не предсказуемо. Чем больше было записано и стерто файлов на SD тем тормознее она становится.

Совершенно абстрактные цифири, ибо зависят от реализации работы с FAT. Ну и 10ms для закрытия файла открытого на чтение вообще совершенно дикое число для просто "забыть" про файл.

Ну может товарищ дескриптор файлов динамически в куче создает, а по закрытию - освобождает. Можно и такие цифры заполучить.

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

Т.е задача сводится к чтению со случайного места в одном, ну или в нескольких файлах.

При этом мне необходимо только чтение, никакой записи.

Если для карт существуют какие-то градации "качества" (я читал про подобные для SDHC), то тоже могу вполне ограничиться использованием только карт "класса АБС и выше".

Всё что мне нужно, быть у веренным что в данных условиях я могу заложиться на время доступа меньше допустим к примеру 10-ти милисекунд, т.е какого-то ограниченного времени, ну и конечно хотелось бы минимального =)

Скорость доступа к отдельному произвольному сектору карты на 90% зависит от самой карты. При чтении по одному сектору на "правильном" контроллере (который держит тактовую при обмене в пределах 20-25МГц или даже выше для новых карт) основное время - это ожидание готовности карты после посылки ей команды чтения - за это время контроллер карты найдет внутри сектор, выполнит все необходимые внутренние процедуры ремаппинга и коррекции и будет готов отдавать данные по шине контроллеру.
Так вот, это характерное время составляет порядка 1 миллисекунды. Время самого обмена данными сектора - пренебрежимо мало - 512*8 - 4Кбита - 1К циклов на 4-х битной шине - при 25МГц - всего 40мкс. И если читать по одному сектору "вразброс" то получим скорость - порядка 512*1K (1000 циклов по 1мс) - всего 512Килобайт. Эта скорость может быть чуть выше или чуть ниже - в-основном зависит от карты, но на двух десятках проверенных мной карт, включая самые новые SDHC, не поднималась выше 2Мбайт/сек.
Другое дело, что контроллер карт очень сильно оптимизирован на операции с последовательными секторами -тут уже скорость может существенно быть выше - при чтении по 32 сектора мне удавалось на SD подняться и до 8Мбайт/сек. Если используется файловая система - то, скорее всего, читать можно будет именно кластерами по нескольку секторов за одну операцию, и оптимизацией контроллера под групповые операции вполне можно воспользоваться.

P.S. Вот результаты испытаний на S2410 - аппаратный контроллер MMC/SD - частота тактирования шины MMC/SD 16.625МГц (и дело было в 2006 - карты были не особо новые)

MMC SD
Теоретическая пропускная способность (max): 2.08MBps 8.31 MBps

Результаты практических испытаний
Чтение по одному 512-байтному блоку: 0.83 MBps 1.79 MBps
Чтение группами по 8 512-байтных блоков: 1.40 MBps 5.41 MBps
Чтение группами по 12 512-байтных блоков: 1.54 MBps 5.70 MBps
Чтение группами по 16 512-байтных блоков: 1.60 MBps 5.81 MBps
Чтение группами по 120 512-байтных блоков: 1.87 MBps 7.78 MBps

Запись по одному 512-байтному блоку: 0.19 MBps 0.42 MBps
Запись группами по 12 512-байтных блоков: 0.40 MBps 1.69 MBps

Такой обьем можно и в ОЗУ кешировать. Если выберете ARM с внешней памятью.

Ну раз разговор зашёл про SD,не стал создавать тему. Спрошу малость не по теме.
Может кто знает, как заставить EFSL не буферить данные. Уменьшил IOMAN_NUMBUFFER до 1-го - но один чёрт не сбрасывает, пока файл опять не откроешь.
Последовательность работы такова:
1) открыть файл
2) записать пару сотен байт
3) закрыть файл
4) вернуться к пункту 1-н
Если пропадает питание или ресет, то получается кривой файл. Пропадает не только последняя запись, но и повреждается FAT.
Выяснил, что EFSL скидывает всё на диск только когда даётся команда размонтировать.

EFSL вся из кривостей. Чем быстрее переберешься на FatFS, тем меньше проблем в будущем.

В FatFS для таких случаев есть функция f_sync():


Так что брось ты эту efsl
FatFS вполне вменяемая FS.

Да, только прикрутить к ней буферизацию нормальную.