Usb storage device что это

USB mass storage device и libopencm3

Моя работа связана с программированием микроконтроллеров, в частности STM32. Долгое время для работы с периферией я использовала STM32 Standard Peripheral Library, так как она предоставляется производителем и, соответственно, является наиболее полной. Однако работать с ней крайне неудобно: инициализирующие структуры зачастую избыточны, в функциях черт ногу сломит, в общем, очень скоро появляется непреодолимое желание слезть с этой библиотеки и перейти на что-нибудь более аккуратное, грамотно спроектированное и написанное «чистым кодом».

После долгих поисков была обнаружена open source библиотека libopencm3, которая отвечала всем требованиям. Отзывы о ней были положительные и работать с ней оказалось максимально приятно.

Одной из последних задач на работе было поднять USB MSD. Для решения задачи использовалась отладочная плата STM32F4-discovery и вот этот пример. Пример не завелся. Проблем было две:
1. Было невозможно зайти на диск и прочитать находящийся там файл.
2. Распознавание устройства как дискового занимало более 2-х минут.

Все это было связано с наличием нескольких багов в файле usb_msc.c. Таким образом, в данной статье я расскажу о том, как исправить эти ошибки и продолжать с удовольствием пользоваться библиотекой libopencm3.

Решение проблемы №1:
Суть ошибки в том, что когда устройство получает запрос на запись, оно правильно его обрабатывает, однако не посылает обратно статус обработки запроса CSW (Command Status Wrapper). Таким образом, usb хост (в нашем случае, это наш ПК) уходит в бесконечное ожидание ответа на запрос, все виснет, глючит, умирает до тех пор, пока не отсоединишь устройство=)

* Более подробно ознакомиться с Mass Storage Bulk-Only or CBI Transport Specification можно здесь.

Поэтому находим функцию msc_data_rx_cb в файле usb_msc.c и приводим ее к следующему виду:

Ура, теперь мы можем зайти на диск прочитать файл!

Решение проблемы №2:
Суть этой проблемы в том, что во все том же файле usb_msc.с не реализованы две SCSI команды. Это было выявлено с помощью очень полезной программы usblyser, которая позволяет в удобном виде просматривать обмен посылками между usb устройством и usb хостом.

Итак, во-первых, хост не получает ответа на команду READ_FORMAT_CAPACITIES. Следовательно, добавляем в файл usb_msc.с функцию scsi_read_format_capacities и приводим функцию scsi_command к следующему виду:

Во-вторых, хост не получает ответа на команду INQUIRY (SERIAL NUMBER). Для исправления данной ошибки необходимо создать массив _spc3_inquiry_sn_response и привести функцию scsi_inquiry к следующему виду:

* Более подробно ознакомиться сo SCSI командами можно опять-таки здесь.

После всех этих хирургических вмешательств библиотеку нужно пересобрать, предварительно выполнив команду make clean.

В скором времени я планирую сделать pull request в репозиторий с libopencm3, однако остается только предполагать, как скоро владельцы внесут эти изменения в библиотеку, а работать тем временем нам всем нужно здесь и сейчас.

Очень надеюсь, что хоть кого-нибудь эта статья избавит от лишней головной боли и будет полезной.

Источник

USB Mass Storage Device — что это?

USB Mass Storage Device — устройство, которое чаще всего является флешкой. Быстрый запуск диспетчера устройств: зажмите Win + R, введите команду devmgmt.msc, нажмите ОК.

Данное устройство вы можете увидеть в диспетчере задач, может быть например в разделе Universal Serial Bus controllers:

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

Хм, есть мысль, что если устройство неправильно обнаружено или если оно с воскликом — тогда может попробовать прогу по автоматической установки драйверов? Нет, я не рекламирую и не предлагаю какую-то ерундовину. Я лично пользовался DevID Agent, мне понравилось — вроде нет рекламы, все понятно, прога небольшая. Если будете ставить, то смотрите чтобы вместе с ней и Яндекс-софт не установился..

Нашел скриншот — получается USB Mass Storage Device может представлять из себя меню, раскрыв которое, вы увидите модель флешки:

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

Надеюсь кому-то инфа помогла. Удачи и добра, до новых встреч господа!

Источник

USB Mass Storage

MSC сообщает о том, что протокол входит в число утвержденных стандартных «классов устройств» в рамках спецификации USB и тем самым является индустриальным стандартом де-юре. UMS говорит об универсальности протокола, который на сегодня поддерживается большинством операционных систем и бесчисленным множеством конечных устройств, что делает его стандартом и де-факто. Вариант расшифровки UMS как USB Mass Storage дополняет эту информацию, уточняя, что в качестве физической линии используется интерфейс USB. Буквы MS (Mass Storage), общие для всех аббревиатур, показывают, что перед нами протокол, предназначенный для работы с устройствами хранения больших объемов данных. Именно для них и был разработан данный стандарт.

К классу устройств USB mass-storage относятся устройства, передающие файлы в одном или в двух направлениях. Типичные представители этого класса устройств: жесткие диски, CD-, DVD-приводы и флешки. Файловая система позволяет пользователю копировать, перемещать и удалять файлы в устройстве.

Почти все устройства USB mass-storage используют протокол передачи только массивов (bulk) данных (bulk-only transport, BOT, также называемый BBB). (исключение составляют некоторые полноскоростные дисководы для дискет, которые используют несколько типов передач данных: управляющие, передача массивов и передачи по прерываниям (control, bulk, interrupt), такой протокол называется CBI). Устройства USB mass-storage также используют команды SCSI, определяемые различными стандартами SCSI (Small Computer System Interface).

Протокол передачи только массивов данных определяет способ, с помощью которого USB хост может посылать команды и получать ответы используя передачу массивов данных, определенную в спецификации USB. В протоколе передачи только массивов данных каждый обмен информацией требует 2 или 3 USB передач данных. В первой передаче хост посылает команду в структуре, называемой CBW (Command Block Wrapper ). За множеством CBW следует передача, которая содержит данные, посылаемые хостом или устройством. В последней передаче устройство возвращает статус в структуре, называемой CSW (Command Status Wrapper ).

Немаловажным является существование спецификации USB host (on the go), позволяющей подключать Mass Storage устройства к другим портативным (и не портативным) аппаратам.

Источник

alt_mob_reviews

alt.mobile.reviews

По поводу режима USB Mass Storage, неизвестно куда «исчезнувшего» из Android Ice Cream Sandwich, в интернете нынче бушует много страстей. Высказались все, и знающие, но редко высказывающися, и незнающие, зато всегда имеющие мнение. Страсти бушуют настолько нешуточные, что мне даже пришлось «вернуться» с блоггерской пенсии, зайти в ЖЖ и написать несколько строк.

Начнем издалека. С кофигурацией хард драйвов при сборке домашнего компьютера сталкивались все гики. Кто-то покупает один большой и разбивает его на несколько разделов, кто-то покупает небольшой SSD для установки на него системы и большой внутренний SATA для хранения файлов, кто-то докупает еще и внешний USB для хранения/переноса фильмов, фотографий и музыки. Надо прикидывать, какого размера покупать диски, какой скорости, с каким интерфейсом подключения, какой фирмой произведенные, и т.п. Знакомая ситуация? Так вот с аналогичной ситуацией сталкиваются и производители телефонов при проектировании и производстве очередной модели.

Что нужно хранить на телефоне? Да практически то же самое:
1. Системные файлы (ОС)
2. Установленные программы и их файлы
3. Файлы пользователя

Продолжая аналогию microSD с USB внешним хардом, скажем, что процесс подключения его к другому устройсву (компьютеру, медиа плееру, и т.п.) требовал его полного отключения от вашего смартфона. Нельзя же USB хард воткнуть сразу в два устройства. Вот и при включении USB Mass Storage Mode контроллер чтения/записи SD карты полностью переключался на USB. В результате телефон доступа к SD карте больше не имел, а контроллер ее выступал в роли USB ридера. Как и в случае с любым ридером, компьютер работал с SD картой напрямую. То есть если бы она была отформатирована под файловую систему, неизвестную ОС, стоящей на компьютере, ОС вам просто сказала бы, что целостность SD карты нарушена, и ее надо бы отформатировать. Так работает любой ридер, он не понимает файловой структуры на накопителе, он просто дает доступ к «блокам» (кластерам) на нем, остальное должна «понять» ОС.

В качестве замены нам предлагается протокол MTP (Media Transfer Protocol), при использовании которого ваш компьютер видит телефон как MP3 плеер. В Windows такой протокол понимает Windows Media Player (да и сам Windows понимает, начиная с Vista), позволяя переливать на телефон медиа контент из вашей медиатеки (из того же Media Player). Решение менее демократичное, чем USB Mass Storage, но более демократичное, чем тот же iTunes. Решение спорное и не всем понравится, но давайте учтем следующее:

— Galaxy Nexus, хоть и является флагманским устройством для Android Ice Cream Sandwich, создан для демонстрации не всех возможностей ОС, а лишь их части. И ни в коем случае возможности ОС не ограничены возможностями данного телефона.

— Если вы настоящий гик, вы всегда найдете способ перебросить любые (не только медиа) файлы на телефон. Подсказка: adb push file /sdcard/

P.S. Любителям конспирологических теорий: а как вам идея, что Гугл избрала такую конфигурацию, чтобы избежать использования VFAT (обязательный при использовании SD card), опасаясь судебного иска от Майкрософта на основе патента 17-летней давности на использование длинных имен файлов в файловой системе FAT?

Рекомендованные материалы к прочтению:
— Отличная заметка от cd_riper на эту тему: http://cdriper.blogspot.com/2011/11/android-ics-usb-mass-storage.html
— Перевод комментариев Дэна Моррила к обсуждению на reddit: http://habrahabr.ru/blogs/android/133172/
— Само обсуждение на reddit: http://www.reddit.com/r/Android/comments/mg14z/whoa_whoa_ics_doesnt_support_usb_mass_storage/

Источник

Прокачиваем USB Mass Storage Device на STM32F103 с помощью FreeRTOS и DMA

Недавно я ковырялся с подключением своего устройства на микроконтроллере STM32F103 как USB Mass Storage Device, или по русски — как флешку. Вроде бы как все относительно несложно: в графическом конфигураторе STM32CubeMX в пару кликов сгенерировал код, добавил драйвер SD карты, и вуаля — все работает. Только очень медленно — 200кбайт/с при том, что пропускная способность шины USB в режиме Full Speed гораздо выше – 12 мБит/с (грубо 1.2 Мбайт/с). Более того, время старта моей флешки в операционной системе составляет около 50 секунд, что попросту некомфортно в работе. Раз уж я нырнул в эту область, то почему бы и не зачинить скорость передачи.

Вообще-то я уже писал свой драйвер для SD карты (точнее драйвер SPI), который работал через DMA и обеспечивал скорость до 500кб/с. К сожалению в контексте USB этот драйвер не заработал. Причиной всему сама модель общения USB — там все делается на прерываниях, тогда как мой драйвер был заточен под работу в обычном потоке. Да еще и припудрен примитивами синхронизации FreeRTOS.

В этой статье я сделал парочку финтов, которые позволили выжать максимум из связки USB и SD карточки подключенной к микроконтроллеру STM32F103 по SPI. Также тут будет про FreeRTOS, объекты синхронизации и общие подходы к передаче данных через DMA. Так что, думаю, статья будет полезна и тем кто только разбирается в контроллерах STM32, и инструментах вроде DMA, и подходах при работе с FreeRTOS. Код построен на основе библиотек HAL и USB Middleware из пакета STM32Cube, а также SdFat для работы с SD картой.

Обзор архитектуры

Если не вдаваться в подробности отдельных компонентов, то реализация Mass Storage Device (он же Mass Storage Class — MSC) на стороне микроконтроллера — штука сравнительно простая.

С одной стороны находится библиотека USB Core. Она занимается общением с хостом, обеспечивается регистрацию устройства и реализует всякие низкоуровневые штуки USB.

Драйвер Mass Storage (с помощью ядра USB) может принимать и отправлять хосту данные. Примерно как COM порт, только данные передаются блоками. Тут важно смысловое наполнение этих данных: передаются SCSI команды и данные к ним. Причем команд бегает всего несколько видов: прочитать данные, записать данные, узнать размер запоминающего устройства, узнать готовность устройства.

Задача драйвера MSC интерпретировать SCSI команды и перенаправлять вызовы в драйвер запоминающего устройства. Это может быть любое запоминающее устройство с блочным доступом (RAM диск, флешка, сетевое хранилище, компакт диск и др.). В моем случае запоминающее устройство это карточка MicroSD, подключенная через SPI. Набор функций, которые требуются от драйвера примерно такой же: читать, писать, отдавать размер и состояние готовности.

И вот тут появляется один важный нюанс, из-за которого собственно весь сыр-бор. Дело в том, что протокол USB — хост ориентированный. Только хост может стартовать транзакции, отправлять или забирать данные. С точки зрения микроконтроллера это означает что вся активность связанная с USB будет проходить в контексте прерывания. При этом у драйвера MSC будет вызван соответствующий обработчик.

Что касается отправки данных от микроконтроллера в сторону хоста. Микроконтроллер не может самостоятельно инициировать передачу данных. Максимум что может микроконтроллер это сигнализировать ядру USB, что есть данные, которые хост может забрать.

С самой SD картой тоже не все так просто. Дело в том, что карта является сложным устройством (по всей видимости там свой микроконтроллер стоит), а протокол общения весьма нетривиальный. Т.е. это не просто отправил/принял данные по определенному адресу (как в случае с каким нибудь I2C EEPROM модулем). Протокол общения с картой предусматривает целый набор различных команд и подтверждений, проверок контрольных сумм и соблюдений всяких таймаутов.

Я использую библиотеку SdFat. Она реализует работу с SD картой на уровне файловой системы FAT, что я активно использую в своем устройстве. В случае подключения по USB все что связано с файловой системой отключается (эта роль переходит хосту). Но что важно, библиотека отдельно выделяет драйвер карты с интерфейсом, практически таким как хочет того драйвер MSC — прочитать, записать, узнать размер.

Драйвер карты реализует протокол общения с картой через SPI. Он знает какие именно команды слать карте, в какой последовательности и какие ждать ответы. Но сам драйвер не занимается общением с железом. Для этого предусмотрен еще один уровень абстракции — драйвер SPI, который транслирует запросы чтения/записи отдельных блоков в собственно передачу данных по шине SPI. Вот именно в этом месте мне удалось организовать пересылку данных через DMA, что увеличило скорость передачи данных в обычном режиме, но поломало всю малину в случае USB (DMA в итоге пришлось отключить)

Но обо всем по порядку.

Какую проблему мы решаем?

Этот вопрос часто задает мой коллега, чем очень озадачивает собеседников во время технических споров.

Со всей этой кухней есть 2 проблемы:

Самый простой способ сократить количество операций чтения при подключении устройства – уменьшить таблицу FAT. Достаточно просто переформатировать флешку и увеличить размер кластера (тем самым уменьшить их количество и размер таблицы). Я отформатировал карту установив размер кластера в 16кб – размер таблицы FAT стал чуть менее 2 Мб, а время инициализации сократилось до 20 секунд.

В любом случае переформатирование флешки не решает проблему линейной скорости (скорости с которой последовательно читаются большие файлики). Она по прежнему остается на уровне 200кб/с и грузит процессор по самое не хочу. Посмотрим что можно с этим сделать.

Что не так с DMA из-под USB?

Перейдем наконец к коду и посмотрим как у меня устроены чтение/запись на флеш карту (драйвер SPI)

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

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

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

Проблема в том, что такой подход сложно натянуть на модель USB где вся логика работы происходит в прерываниях, а не в обычном потоке выполнения. Т.е. получается, что запрос на чтение/запись мы получим в прерывании, и завершение передачи данных также придется ждать в этом же прерывании.

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

Тут гораздо интереснее было бы по запросу от хоста начать передачу данных по DMA и выйти из прерывания. А потом как нибудь на следующем прерывании отчитаться о проделанной работе.

Но это еще не вся картина. Если бы чтение с карты заключалось только в пересылке блока данных, то такой подход было бы не сложно реализовать. Но ведь передача по SPI это, безусловно, самая важная часть, но не единственная. Если посмотреть на чтение/запись блока данных на уровне драйвера карты, то процесс выглядит примерно так.

Но не все так плохо. Если посмотреть еще выше — на уровень драйвера MSC — то ему вообще по барабану как именно будет происходить передача данных — одним блоком или несколькими, с DMA или без. Главное передать данные и отрапортовать о статусе.

Идеальным местом для экспериментов будет прослойка между драйвером MSC и драйвером карты. Перед всеми издевательствами этот компонент выглядел весьма тривиально — по сути это адаптер между интерфейсом, который хочет видеть драйвер MSC и тем что выдает драйвер карты.

Как я уже говорил, драйвер карты не работает если его вызывать из-под прерывания. Но ведь он хорошо работает в обычном потоке. Так вот и запустим ему отдельный поток.

Этот поток будет получать запросы на чтение и запись через очередь. Каждый запрос включает информацию о типе операции (чтение/запись), номер блока, который нужно прочитать или записать, количество блоков и указатель на буфер данных. Еще я завел указатель на контекст операции — он нам понадобится чуть позже.

Сам поток спит в ожидании команд. Если пришла команда, то выполняется нужная операция, причем синхронно. По окончании операции вызываем коллбек, который в зависимости от реализации сделает то, что нужно по окончании операции чтения/записи.

Поскольку все это выполняется в рамках обычного потока, то драйвер карты внутри может использовать DMA и синхронизацию FreeRTOS.

Функции MSC стали чуть сложнее, но ненамного. Теперь вместо непосредственного чтения или записи этот код отправляет запрос в соответствующий поток.

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

А пока, чтобы проверить эти функции сделаем еще один тестовый поток. Он будет эмулировать USB ядро и посылать запросы на чтение.

Этот код считывает всю карту от начала до конца блоками по 1кб и измеряет скорость чтения. Каждая операция чтения отправляет запрос в поток SD карты. Там синхронно происходит чтение и рапортует об окончании через обратный вызов. Я подставил свою реализацию этого коллбека, которая просто сигнализирует тестовому потоку, что можно продолжать (тестовый поток все это время спит в функции ulTaskNotifyTake() ).

Но самое главное, скорость чтения в таком варианте составляет около 450кб/с, а процессор загружен всего на 3-4%. По моему неплохо.

Прокачиваем драйвер MSC

Итак, драйвер карты мы победили, включив DMA. Но семантика чтения/записи поменялась с синхронной на асинхронную. Теперь нужно подправить реализацию MSC и научить ее работать с асинхронными вызовами. Т.е. на первый запрос от хоста нам нужно начать передачу через DMA, а на все последующие как-то отвечать, мол “предыдущая операция еще не закончилась, загляни позже”.

Вообще-то протокол USB предоставляет такой механизм прямо из коробки. Приемная сторона подтверждает пересылку данных неким статусом. Если данные приняты и обработаны успешно, то приемник подтверждает транзакцию статусом ACK. Если устройство не может обработать транзакцию (не инициализировано, находится в состоянии ошибки или не работает по какой либо другой причине), то ответом будет статус STALL.

А вот если устройство распознало транзакцию, находится в работоспособном состоянии, но данные еще не готовы, то устройство может ответить NAK. В этом случае хост обязан обратиться к устройству с точно таким же запросом чуть позже. Этот статус мы могли бы использовать для отложенного чтения/записи – на первый вызов хоста начинаем передачу данных через DMA, но отвечаем на транзакцию NAK. Когда хост приходит с повторной транзакцией и пересылка через DMA уже закончилась – отвечаем ACK.

К сожалению я не нашел в библиотеке USB от ST хорошего способа отправлять сигнал NAK. Коды возврата функций либо не проверяются, либо могут обрабатывать только 2 состояния – все хорошо, либо ошибка. Во втором случае все конечные точки закрываются, везде выставляется статус STALL.

Я подозреваю, что на уровне самом низком уровне USB драйвера подтверждение NAK используется довольно активно, но как правильно воткнуться с NAK на уровне драйвера класса я не разобрался.

По всей видимости создатели библиотек от ST вместо различных подтверждений предоставили более человечный интерфейс. Если устройству есть что отправить хосту оно вызывает функцию USBD_LL_Transmit() — хост сам заберет предоставленные данные. А если функция не была вызвана, то устройство будет автоматически отвечать NAK ответами. Примерно такая же ситуация с приемом данных. Если устройство готово к приему, то оно вызывает функцию USBD_LL_PrepareReceive(). В противном случае устройство будет отвечать NAK если хост попытается передать данные. Воспользуемся этим знанием для реализации нашего MSC драйвера.

Давайте посмотрим какие транзакции бегают по шине USB (анализ производился до изменений в драйвере карты).

Тут интересно даже не сами транзакции, а их временнЫе отметки. Транзакции на этой картинке я выбрал «легкие» — такие, которые не требуют обработки. Микроконтроллер на такие запросы отвечает захардкоженными ответами, особо не размышляя. Важно тут то, что хост не пуляет транзакциями сплошным потоком. Транзакции идут не чаще чем раз в 1 мс. Даже если ответ готов сразу, хост заберет его только на следующей транзакции через 1мс.

А вот так выглядит чтение одного блока данных в терминах транзакций на шине USB.

Сначала хост отправляет SCSI команду на чтение, а потом отдельными транзакциями читает данные (вторая строка) и статус (третья). Первая транзакция – самая длинная. Во время обработки этой транзакции микроконтроллер как раз и занимается вычиткой с карты. И, опять же, между транзакциями хост выдерживает паузу в 1мс.

Алгоритм драйвера MSC на стороне микроконтроллера выглядит примерно так

У меня не получилось существенно (скажем до 1Мб/с) ускорить чтение данных – видимо такова пропускная способность карты подключенной по SPI. Но мы можем попробовать поставить к себе на службу 1мс паузы между транзакциями.

Я это вижу так (слегка упрощенно)

В коллбеке нужно обращаться к нескольким переменным, которые определялись в функции SCSI_ProcessRead() — указатель на хендл USB, длину передаваемого блока, LUN. Вот тут как раз и пригодился параметр context. Я, правда, не все передавал, а только pdev, а все остальное можно выудить из него. Как по мне такой подход проще чем тягание целой структуры с нужными полями. И, во всяком случае, это лучше чем заводить несколько глобальных переменных.

Добавим двойной буфер

Подход, в целом, заработал, но скорость была по прежнему чуть больше 200кб/с (хотя загрузка процессора починилась и стала около 2-3%). Давайте разбираться что же мешает работать быстрее.

По советам в комментариях к одной из моих статей я таки обзавелся осциллографом (пускай и дешевеньким). Он оказался очень кстати для понимания что вообще там происходит. Я взял неиспользуемый пин и выставлял на нем единицу перед началом чтения и ноль после того как чтение закончилось. На осциллографе процесс чтения выглядел так.

Т.е. само чтение 512 байт занимает чуточку больше 1мс. Когда чтение с карты заканчивается данные передаются в выходной буфер, откуда в течении следующих 1мс хост их забирает. Т.е. тут либо происходит чтение с карты, либо передача по шине USB, но не одновременно.

Обычно такая ситуация решается с помощью двойной буферизации. Более того, USB периферия микроконтроллеров STM32F103 уже предлагает механизмы для двойной буферизации. Только они нам не подойдут по двум причинам:

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

Оригинальная реализация работала на прерывании DataIn — сигнале о том, что данные отправились. Т.е. по команде от хоста запускалось чтение, после чего данные прекладывались в выходной буфер. Чтение очередной порции данных “перезаряжалось” по прерыванию DataIn. Нам такой вариант не подходит. Мы будем начинать чтение сразу после того как предыдущее чтение закончилось.

Эта функция немного поменяла структуру. Во-первых, именно тут реализована поддержка двойной буферизации. Поскольку эта функция вызывается когда чтение с карты закончено, то мы сразу можем запустить следующее чтение вызовом SCSI_ProcessRead(). Чтобы новое чтение не затерло только что прочитанные данные как раз и используется второй буфер. За переключение буферов отвечает переменная bot_data_idx.

Но это еще не все. Во-вторых изменилась последовательность действий. Теперь сначала заряжается чтение очередного блока данных и только потом вызывается USBD_LL_Transmit(). Так сделано потому, что функция cardReadCompletedCB() вызывается в контексте обычного потока. Если вызвать USBD_LL_Transmit() вначале, а потом менять значения полей hmsc, то потенциально в этот момент может вызваться прерывание от USB, которое также захочет менять эти поля.

В-третьих пришлось прикрутить дополнительную синхронизацию. Дело в том, что обычно чтение с карты занимает чуточку больше времени чем передача по USB. Но иногда бывает наоборот и тогда вызов USBD_LL_Transmit() для очередного блока случается раньше чем предыдущий блок был полностью отправлен. USB ядро от такой наглости дуреет и данные отправляются неверно.

Отправка данных (Transmit) подтверждается событием Data In, но иногда несколько Transmit’ов происходят подряд. Для таких случаем нужна синхронизация.

Решается это очень просто добавлением небольшой синхронизации. Я добавил в интерфейс USBD_StorageTypeDef парочку функций с довольно простой реализацией (хотя, возможно, названия не очень удачные). В реализации используется обычный семафор в режиме signal-wait. OnFinishOp(), которая вызывается, в коллбеке cardReadCompletedCB() будет спать и ждать пока предыдущий пакет данных отправится.

Факт отправки подтверждается событием DataIn, которое обрабатывается функцией SCSI_Read10(), которая вызовет OnStartOp(), которая разблокирует OnFinishOp(), которая отправит очередной пакет данных, в доме который построил Джек. Даже если функции будут вызываться в обратном порядке (а именно так и будет происходить во время первого чтения — сначала SCSI_Read10(), потом cardReadCompletedCB() ) то все также будет прекрасно работать (свойство семафора в режиме signal-wait).

С такой синхронизацией картинка приобретает следующий вид.

Красными стрелками показана синхронизация. Последний Transmit ждет предыдущий Data In

Последний кусочек паззла — функция SCSI_Read10().

В оригинальной реализации SCSI_Read10() на первый вызов функции проверялись параметры и запускался процесс чтения первого блока. Эта же функция вызывается позже по прерыванию DataIn когда предыдущий пакет уже отправлен и нужно запускать чтение следующего. Обе ветки запускали чтение с помощью функции SCSI_ProcessRead().

В новой реализации вызов SCSI_ProcessRead() переехал внутрь if’а и вызывается только для чтения первого блока (bot_state == USBD_BOT_IDLE), тогда как чтение последующих блоков запускается из cardReadCompletedCB().

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

Как видно из этой картинке затея удалась. Новая операция чтения стартует сразу как только предыдущая закончилась. Паузы между чтениями довольно маленькие и диктуются, в основном, хостом (та самая задержка в 1мс между транзакциями). Средняя скорость чтения больших файлов достигает 400-440кб/с, что весьма неплохо. И, наконец, загрузка процессора составляет около 2%.

А как же запись?

Пока я тактично обходил тему записи на карту. Но теперь с полученными знаниями и пониманием работы драйвера MSC реализация функции записи не должна быть сложной.

Оригинальная реализация работает примерно так.

Точно также как и в случае чтения нужно как то доставить некоторые переменные из первой функции во вторую. И для этого я использую параметр context и передаю хендл USB устройства (из него можно выудить все необходимые данные).

Скорость записи в таком режиме составляет порядка 90кб/с и в основном ограничена скоростью записи на карту. Это подтверждается осциллограммой — каждый пик это запись одного блока. Судя по картинке, запись 512 байт занимает от 3 до 6мс (каждый раз по разному).

Более того, запись иногда может залипать от 100мс до 0.5с — видимо где то в карте возникает необходимость в различных внутренних активностях — ремаппинг блоков, стирание страниц, или что нибудь в таком духе.

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

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

В такой схеме несколько пакетов могут быть приняты подряд, но не все из них успеют быть записаны на SD карту. Скорее всего часть данных пререзатрется следующим блоком.

Нужно делать синхронизацию. Только где? В случае операции чтения двойную буферизацию и синхронизацию мы организовывали в месте где заканчивается чтение с карты и данные перебрасываются в USB. Этим местом была функция cardReadCompletedCB(). В случае операции записи таким центральным местом будет функция SCSI_Write10() — именно в ней мы окажемся, когда будет принят очередной блок данных, и именно отсюда мы будем стартовать запись на карту.

Но между функциями cardReadCompletedCB() и SCSI_Write10() есть одна принципиальная разница — первая работает в потоке SD карты, а вторая в прерывании USB. Обычный поток может быть приостановлен в ожидании некоторого события или объекта синхронизации. С прерыванием такой фокус не пройдет — все функции FreeRTOS с суффиксом FromISR неблокирующие. Они либо работают как надо (захватывают ресурс, если он свободен, отправляют/получают сообщения через очередь если там есть место или необходимое сообщение), либо эти функции возвращают ошибку. Но они никогда не ждут.

Но если нельзя организовать ожидание в прерывании, то можно попробовать сделать так, чтобы прерывание вообще не вызывалось лишний раз. Точнее даже так: чтобы прерывание возникало ровно столько раз и в такие моменты когда нам нужно.

Давайте рассмотрим несколько случаев, которые могут возникнуть в процессе приема/записи.

Случай №1: прием первого блока. Как только принят первый блок, то можно начинать запись этого блока. Одновременно с этим можно начать прием второго блока. Это избавит от паузы, когда мы не принимаем следующий блок, пока предыдущий пишется на карту.

Случай №2: прием блока в середине транзакции. Скорее всего оба буфера уже будут заполнены. Где нибудь в потоке SD карты идет запись блока данных из первого блока, тогда как второй блок мы только получили от хоста. В принципе ничего не мешает зарядить запись второго блока — там на входе стоит очередь (см функцию SD_MSC_Read() выше), которая регулирует входные запросы и будет писать блоки по очереди. Нужно только убедится, что в этой очереди есть место на 2 запроса.

Но как регулировать прием? У нас всего 2 приемных буфера. Если сразу после приема второго блока начать прием следующего, то это перезатрет данные в первом буфере, откуда в данный момент идет запись на карту. В таком случае правильнее будет начинать прием очередного блока данных когда буфер освободится — когда закончится запись (т.е. в коллбеке функции записи).

Наконец, случай №3: нужно уметь правильно завершить процедуру приема/записи. С последним блоком все понятно — нужно вместо приема очередного блока отправить хосту CSW, что данные приняты и транзакцию можно закрывать. Но нужно помнить, что вначале транзакции мы уже организовали лишний прием, поэтому предпоследний блок не должен заказывать прием лишнего блока.

Вот картинка которая описывает эти случаи.

Случай 1: на первый DataOut сразу же начинаем прием второго блока. Случай 2: начинаем прием очередного блока только после того как запись закончена и буфер свободен. Случай 3: на предпоследней записи прием не начинаем, на последней — отправляем CSW

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

Попробуем реализовать задуманное. Для реализации первого случая (прием дополнительного блока) нам понадобится специальное состояние

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

Нужно не забыть изменить размер очереди записи в потоке SD карты

Функция SCSI_Write10() изменилась мало, добавилась только инициализация индекса двойного буфера и переход в состояние USBD_BOT_DATA_OUT_1ST

Вся самая интересная логика будет сосредоточена в функции SCSI_ProcessWrite() — именно там будут распределятся буфера и строится вся цепочка чтений и записей.

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

Наконец, специальный случай (случай №1) — организуем дополнительный прием данных в случае первого блока (состояние USBD_BOT_DATA_OUT_1ST)

Ответная часть этого кода — коллбек о завершении записи на карту. В зависимости от того какой блок был записан либо организовывается прием следующего блока, либо отправляется CSW, либо ничего не происходит.

Финальный аккорд это синхронизация, суть работы которой проще показать на картинке.

Очень редко, но все же иногда возникает ситуация, когда запись на карту заканчивается раньше, чем принят следующий пакет. В итоге код (если бы не было синхронизации) мог бы запросить прием еще одного пакета, хотя текущий ещё не до конца принят. Чтобы такого не происходило пришлось добавить синхронизацию. Теперь прежде чем запросить прием следующего блока код будет ждать пока закончится прием предыдущего. Средства синхронизации, которые использовались при чтении (OnStartOp()/OnFinishOp()) вполне подойдут.

Условия при которых нужно синхронизироваться достаточно хитрые. За счет приема дополнительного блока в начале транзакции синхронизация идет со сдвигом в один блок. Поэтому коллбек записи N-того блока ждет приема N+1 блока. Это в свою очередь означает, что прием первого блока (происходит в контексте прерывания от USB) и запись последнего (происходит в контексте потока SD карты) в синхронизации не нуждаются.

Может показаться что красная стрелка дублирует черную, которая стартует запись следующего блока. Но если посмотреть на код, то видно, что это не так. Красная (синхронизация) синхронизирует код в драйвере MSC (синий квадратик), тогда как очередь обрабатывается в драйвере карты (там где основной цикл потока SD карты). Мне не очень хотелось мешать код разных компонентов.

Я расставил немного дебажного логирования, запись 4кб данных выглядит примерно так

Как и ожидалось, существенного прироста к скорости это не добавило. После переделки скорость составила 95-100 кб/с. Но как я говорил, делалось это все из спортивного интереса.

А еще быстрее можно?

Давайте попробуем. Где-то в середине работы я случайно обратил внимание, что чтение одного блока и чтение последовательности блоков — это разные команды SD карты. Они даже представлены разными методами драйвера карты — readBlock() и readBlocks(). Точно так же различаются команды записи одного блока и записи серии блоков.

Поскольку драйвер MSC по умолчанию заточен на работу с одним блоком в единицу времени, то был смысл заменить readBlocks() на readBlock(). К моему удивлению скорость чтения даже выросла и стала на уровне 480-500кб/с! Аналогичный трюк с функциями записи, к сожалению, прироста скорости не дал.

Но меня с самого начала мучал один вопрос. Давайте еще разок взглянем на картину чтения. Между зазубринами (чтение одного блока) — около 2мс.

Тактирование SPI у меня настроено на 18МГц (используется делитель частоты ядра 72МГц на 4). Теоретически передача 512 байт должна занимать 512 байт * 8 бит /18 МГц = 228мкс. Да, тут будет определенный оверхед на синхронизацию нескольких потоков, обслуживание очереди и прочие штуки, но это никак не объясняет разницу почти в 10 раз!

С помощью осциллографа я измерил сколько реально времени занимают различные части операции чтения