LPC2478. Разобрался с MassStorage с SD картой, но скорость, мягко говоря, низкая, на LPC 33-35 ед., та же карта с кардридером ~5000 ед. Как заставить эту парочку быстрее работать?

А что такое "единица" ? Давайте уж без загадок. У меня очень похожий проект, но на AT91SAM9XE512 (Full Speed). Тоже SD-карточка, тактовая частота для карточки - 22.5 МГц. По чтению и по записи достигнуты скорости примерно 606-616 КБайт в секунду. Фабричная флэшка на Full Speed дает такой же результат. А у вас какая скорость достигается ?

Да какие загадки, просто лень было Кбит/сек писать Сейчас ещё раз проверил кардридер 1100 kbytes/s, LPC 33,6 kbytes/s.

Явная аномалия. Причем если картридер работает на High Speed, то тоже анамалия, но уже не ваша. А чем мерили ? Я мерил HD_Speed:
http://www.steelbytes.com/?mid=20

Карточка на какой частоте работает ? 1 МГц ? По SPI или по параллельному четырехразрядному ?

Сообщение отредактировал kovigor - Dec 22 2010, 07:22

Хм, что-то у вас медленная флешка.
У меня mass storage на STM32 по SPI 18 МГц чтение/запись 850-900 KB/sec.

Кард ридер, если его ограничить Full speed портом, думаю, выдаст даже больше благодаря параллельному интерфейсу.

Скорость мерил обычным копированием в Total Commander. Если он врёт, то врёт одинаково.
Исходник для работы с картами взял отсюда c:\Keil\ARM\Boards\Keil\MCB2470\RL\FlashFS\ (устанавливается по умолчанию, mdk412.exe, rlarm412.exe). Макетка у меня SK-MLPC2478 (12 МГц)

Аналогично, тоже пользовался Тотал Коммандером.

Для этого надо быстро закидывать в трубу чанки, а не щелкать клювом.

Если упрощенно, то когда хост забирает у вас первый чанк 64 байта, он тут же требует следующий чанк. Если вы его не предоставите в течении 43 мкс (для FS), то планировщик хоста решит, что ваш девайс тормозит безмерно и в следующий раз запросит у него чанк только в следующем фрейме, т.е. через 1 мс, или даже через фрейм. Так что для тормозных девайсов предел скорости обмена - 64 кбайт/сек, а в действительности еще меньше. А если будете подсовывать чанки оперативно, без жевания соплей, то хост может забрать у вас до 19 чанков за один фрейм, это дает в пределе 1216 кбайт/сек для FS.

На практике используется два буфера. Пока хост выкачивает чанк из одного буфера, вы заполняете второй, а потом ваша USB железяка мгновенно и автоматически меняет их местам, как только хост выкачал чанк и потребовал следующий. При скорости 12 Мбит/сек хост выкачивает чанк в 64 байта примерно за 43 мкс . Вот за это время вам надо успеть заполнить второй буфер. Не успели - кирдык, будете загорать как минимум до следующего фрейма.

Примерно понятно, не знаю только, что есть чанк. Часть cектора? Как определить какой сектор хост потребует в следующий раз? Работу программы понимаю так (разбирая исходник, может и ошибаюсь), хост запрашивает данные из куска заданного сектора, эти данные вычитываются с карточки и пересылаются в хост. Пока данные пересылаются, могу вычитать следующий сектор, но какой? Ходя по программе дебагером видно, что сектора не всегда вычитываются последовательно.

"Чанками" (от английского chunk - "кусок") я называю USB-пакеты. В USB длинное сообщение не передается целиком, а разбивается на куски и передается пакетами.

Для балк-трубы (а масс-сторадж качает данные через балк) размер пакета может быть 8, 16, 32 или 64 байта, он декларируется в дескрипторе устройства. Как правило для балка все используют пакеты в 64 байта.

К секторам это не имеет отношения. Когда вы перекачиваете файл или массив через USB, низкоуровневый софт и железо (или даже вообще одно только железо, надо смотреть, кто это делает в вашем случае) разбивает его на чанки и закидывает в USB. Если размер очередного чанка равен 64 байта, значит, файл еще не закончился, хост будет требовать еще. Если чанк меньше 64 байт (вплоть до нуля), то хост знает, что это последний чанк файла.

Хм, вообще-то, в случае mass storage, хост всегда знает, каков размер запрашиваемого пакета, так как сам выставляет девайсу эту информацию в виде: логический номер первого нужного сектора + количество байт.

Поэтому никакого смысла в лишней транзакции с нулевой длиной нет.

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

Читать на опережение нужно те сектора, которые запросил хост.
А он может запросить пакет размером от одного сектора до 128 (65 килобайт).
Сектора в пакете всегда идут последовательно, то есть параллельно с передачей/приёмом данных хосту/от него необходимо считывать/записывать их на носитель.

Речь шла не о транзакциях. Смысл "лишнего" чанка нулевой длины объясняется в спецификации USB, параграф 5.8.3 "Bulk Transfer Packet Size Constraints".