Usb mass storage bulk only что это
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_mob_reviewsalt.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 и 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, однако остается только предполагать, как скоро владельцы внесут эти изменения в библиотеку, а работать тем временем нам всем нужно здесь и сейчас.
Очень надеюсь, что хоть кого-нибудь эта статья избавит от лишней головной боли и будет полезной.