Далее от Автора :
Прочитав пару статей других пользователей, захотелось самому начеркать чего-то полезного для остальных. Как все поняли из названия, речь пойдет о создании USB mass storage device класса на програмной реализации V-USB.
Знакомство мое с данной библиотекой произошло случайно и оч. давно. Как и большинство(наверное) на то время любителей я все работал на микрухах типа pl2303 и FT245(232), а они, как известно, не позволяют изменять класс устройства (тока то, что зашито на заводе и все). Купить контроллер с аппаратной частью USB возможности не было, вот, как говорится, и понеслось!) Бодяжил много чего полезного и бесполезного, но как говориться тока для себя зануды любимого. Как-то читал на одном известном форуме, что реализовать то или иное устройство на данной «псевдо» USB нереально, а передавать большие объемы данных и подавно. Так и задался целью замутить чегонить вроде USB флешки или микрофона. И то и другое сделал, но из-за того что я тяжелый на подъем, в массы так и не выкладывал. Вот и моя первая проба познакомить уважаемое сообщество со своим проектом.
Сразу оговорюсь, что все приведенные фотки моего девайса тока для ознакомления, потому как это платка мой программатор AVR по USB со своим бутом и прогой для апдейту. Схему я конечно выложу, но плату разводить, наверное, специально для этого проекта, не буду.
Проект выполнен на IAR’е, sPlan, SprintLayout, Device Monitoring Studio и утюге под пиво =) Ну, в путь!
Для начала, немного теории. MSD или Mass Storage Class это ничто иное, как один из стандартных классов USB для описания и взаимодействия с утройствами хранения информации. Реализаций и стандартов MSD довольно много и заморачиваться на каждом из них нет смысла. Опишу самый распространенный из них(он же самый простой на мой взгляд): Bulk-only или BBB.
В стандарте USB есть такое понятие, как конечная точка(end-point). Конечная точка — это часть USB-устройства, которая имеет уникальный идентификатор и является получателем или отправителем информации, передаваемой по шине USB. Проще говоря, это буфер, сохраняющий несколько байт. Обычно это блок данных в памяти или регистр микроконтроллера. Данные, хранящиеся в конечной точке, могут быть либо принятыми данными, либо данными, ожидающими передачу. Хост также имеет буфер для приема и передачи данных, но хост не имеет конечных точек.
Конечная точка имеет следующие основные параметры:
1 - Частота доступа к шине
2 - Допустимая величина задержки обслуживания
3 - Требуемая ширина полосы пропускания канала
4 - Номер конечной точки
5 - Способ обработки ошибок
6 - Максимальный размер пакета, который конечная точка может принимать или отправлять;
7 - Используемый конечной точкой тип посылок
8 - Направление передачи данных
Любое USB-устройство имеет конечную точку с нулевым номером (Endpoint Zero). Эта точка позволяет хосту опрашивать устройство с целью определения его типа и параметров, выполнять инициализацию и конфигурирование устройства.
Кроме нулевой точки, устройства, обычно, имеют дополнительные конечные точки, которые используются для обмена данными с хостом. Дополнительные точки могут работать либо только на прием данных от хоста (входные точки, IN), либо только на передачу данных хосту (выходные точки, OUT). Число дополнительных конечных точек устройств определяется режимом передачи.
Для низкоскоростных устройств допускается наличие одной или двух дополнительных конечных точек, а для высокоскоростных — до 15 входных и 15 выходных дополнительных точек.
Но это тока теория, которая выглядит довольно абстрактно. Будем считать, что конечная точка, это ничто иное как фунция в языке C, которая тока принимает параметры, или только возвращает значения.
Так вот, мы строим устьройство, отвечающее спецификации bulk-only. И тут самое приятное: все события делятся на три фазы:
1 - Прием команды от хоста(копьютера)(CBW)
2 - Прием/Передача запрашиваемых данных(DATA)
3 - Передача хосту результата выполнения принятой комманды(STATUS)
Здесь видно, что мы принимаем данные и отправляем данные, значит мы имеем 2 конечные точки (от хоста к устройству и наоборот), а, исходя из выбранной спецификации, эти точки используют bulk передачу данных.
Следовательно мы должны сконфигурировать библиотеку V-USB соответсвующим образом:
1 - Описываем конечную точку-in
2 - Конечную точку-out
3 - Указываем v-USB, что мы используем 2 конечные точки помимо основной (control-endpoint)
4 - Задаем класс устройсва USB — Mass Storage Class Bulk-only (Не пугайтесь, все это легко видно из файлов прошивки).
На этом весь процесс создания устройства MSD bulk-only закончен и мы приступаем к тому, что принимаем от хоста комманды и соответсвенно реагируем на них!
Теперь вкратце о тех самых коммандах от хоста. Их не так много и большинство из низ поступают только пару раз. Итак хост может попросить от нас следующее:
► Inquiry — запрос основных характеристик устройства
► Test unit ready — проверка готовности устройства, в т.ч. наличия диска в дисководе.
► Request sense — возвращает код ошибки предыдущей команды.
► Read capacity — возвращает ёмкость устройства.
► Read (4 варианта) — чтение.
► Write (4 варианта) — запись.
► Mode select — установка параметров устройства.
► Mode sense — возвращает текущие параметры устройства
Теперь далее. Пересмотрев массу устройств хранения информации (EEPROM, nand и т.д.) я выбрал, наверное, самое распространненое SD/MMC карту памяти. Подключение ее к AVRке давно известно, а протокол хорошо разжеван. Еще один плюс в том, что эти карты могут читать/писать по 512 байт данных, что очень подходит для данной задачи.
Так, основными коммандами MSD bulk-only устройстве являются чтение и запись блоков информации. Драйвер Windows (да простят меня пользователи Linux) обращается к нашему устройству по принципу LBA, то есть адрес логического блока (или его номер, что одно и тоже) и их количество.
В нашем случае один логический блок это сектор размером в 512 байт. Так если ОС запросит у нас данные из 20-го LBA, то мы просто умножим 20 на 512 и получим линейный адрес на устройстве носителя. Затем прочитем/запишем нужное число блоков и все! Знать что-то о данных на устройстве хранения информации и способе их размещения AVR не должна. Наша задача обеспечить возможность чтения и записи этих самых блоков из/на устроство хранения информации, а остальное сделает ОС.)
Теперь я представлю Вам мою схемку. Сразу оговорюсь, делал на быструю руку, так как печатку делал из головы (схема не сложная):
Многие заметят, что практически стандартная схема для устройств на V-USB, и что я немного перемудрил с ней, на я повторюсь, что собрал флешку из моего программатора, поэтому здесь немного изврата присутствует. Перемычка JP2 предназначена для прошивки нашего устройства и должна быть установлена только во время обновления прошивки устройства(разъем Х2). Диоды D1 и D2 предназначены для задания рабочего напряжения питания ~3.6V. Можно обойтись и одним(проверено неоднократно), хотя при грамотном подходе лучше сделать не так как я=)
Ну а теперь немного по коду программы. Сначала опишем конфигурацию аппаратной части нашего устройства в файле «usbconfig.h»:
Здесь мы указали, что порт, к которому подключены дифференциальные сигналы D+ и D-, это порт PORTD, а выводы, к которым они подключены, соответсвенно 3 и 2. Частота кварцевого резонатора равна 16 Мгц. Затем мы описали, что мы сами управляем процессом подключения нашего устройства к шине USB. Для этого мы сделали следующее:
Это видно из схемы: резистор R7, подключенный к выводу 1 порта PORTD. Далее в программе нам это понадобиться для того, чтобы произвести подключение к хосту в момент времени, который нам более всего подходит. (напомню, что Хост определяет наличие подключения устройства к шине в случае подтягивания линии D- к Vdd. Это я для низкоскоростных устройств).
В рекомендации от V-USB сказано, что линия D+ должна быть подключена к INT0, но я внес некоторые изменения и подключил ее к INT1, что в принципе не запрещено (подключают к IN0 т.к. прерывание INT0 имеет наивысший приоритет в системе прерываний AVR. прим. DH), поэтому я указываю на соответствующие изменения в следующих строках:
В принципе, в описании аппаратной части USB это все.
В этом же файле мы указываем, что класс и подкласс устройства определяется классом и подклассом интерфейса (это я про то, что мы используем стандартный интерфейс MSD bulk-only). Это делается следующим образом:
Так же мы помним, что мы имеем 2 конечные точки (т.к. мы принимаем и отправляем данные от хоста), значит мы указываем на это библиотеке V-USB:
Теперь пару слов о следующих определениях:
Поскольку мы использовали стандартный класс USB MSD, то и описать устройство это класса обязаны мы. Позже я вернусь к этим строкам, а пока мы оставим их в покое.
В принципе в этом файле вроде как и все, но я оговорюсь для наиболее дотошных (как я=): я не пират и не пытался нарушить чьета права? использовав VID/PID, которые в моем файле usbconfig.h. Мало того, я даже не знаю чье они, просто первые попавшиеся под руку==)
Пожалуй, распишу немного процесс инициализации устройства на V-USB.
Немного выше я определил небольшой макрос USB_CFG_PULLUP_IOPORTNAME в соответствии со схемой, что в свою очередь дало мне возможность производить подключение и отключение от шины USB в произвольные моменты времени. Так вот, для подключения к шине используется макрос
usbDeviceConnect();
при вызове которого происходит подтяжка линии D- к напряжению питания устройства. Хост определяет это событие и начинает процедуру конфигурации устройства USB: Сброс девайса, присвоение адреса и т.д.
Во всей этой рутинной суете главное для нас это этап запроса дескриптора устройства, который в свою очередь содержит поддерживаемую версию USB, максимальный размер пакета для control конечной точки, идентификаторы устройства и производителя VID/PID, версию устройсва, строковые номера индексов(если таковые присутсвуют) и количество конфигураций нас родимых.
Поскольку мы проектируем свое собственное ни на что не похожее устройства, то давайте опишем этот дескриптор (Здесь и далее я рассматриваю файлы «MassStorage.h» и «MassStorage.cpp»)
Помните, выше мы описали #define USB_CFG_DESCR_PROPS_DEVICE. Так вот, определив это, мы сообщили библиотеке V-USB, что используется пользовательский «описатель устройства», и при запросе хостом данной информации V-USB передаст то, что мы с вами только что описали. Мы видим, что я описал в usbDescriptorDevice количество конфигураций устройтва равным 1. Что это значит? Это значит что наше устройство может работать только в одном режиме, который мы определим чуть ниже. Так вот наш режим(или конфигурация, если правильнее):
Хочу отметить, что в дескрипторе кофигурации мы встраиваем дескриптор интерфейса и дескрипторы конечных точек. Этот (или эти, если хотите) дескриптор передается V-USB благодаря ранее описанному определению
#define USB_CFG_DESCR_PROPS_CONFIGURATION USB_PROP_LENGTH(32)
В этом же десрипторе (usbDescriptorConfiguration) мы указали, пожалуй, самую важную информацию для нашего устройства, а именно:
► устройство класса MSD
► тип передачи — bulk-only
► размеры конецчных точек и их направление
После того, как хост получил дескрипторы устройства, конфигурации, интерфейса и конечных точек, он (хост) начинает «общаться» с нашим устройством как MSD bulk-only. Поскольку мы работаем со стандартным интерфейсом MSD, то никакие control передачи для control конечной точки нас не интересуют. Вместо этого мы определим функцию
USB_PUBLIC void usbFunctionWriteOut(unsigned char* ucData, unsigned char ucLen)
которая будет принимать все interrupt/bulk передачи данных от хоста к нашему устройству для всех конечных точек, кроме 0 (это control точка). Напомню, что максимальное количество байт, которое может быть принято через usbFunctionWriteOut за один вызов равно 8 байтам (это ограничение V-USB). Ну вот, теперь мы готовы принимать поступающие от хоста байты =))) И на этом этапе мы перейдем к следующему этапу — разделение потока байт от хоста на вменяемые пакеты, которые несут нам полезную информацию. Как мы узнали ранее, хост может направлять в MSD устройство толька комманды и данные. Теперь мы сделаем следующее:
► разделим входной поток данных на комманды и данные
► обработаем комманды в соответсвие с их предназначением или примем данные от хоста
► ответим хосту на обработанную комманду (предварительно отправив запрошенные данные, если необходимо)
Для того, чтобы воплотить в жизнь написанное чуть выше, давайте разберемся с несколькими положениями, которые касаются Mass Storage Class в целом и bulk-only в частности. Как я уже оговаривал, Mass Storage Class(MSC) не подразумевает того, что устройство, которое работает согласно этой спецификации, занет что-либо о фойловой системе на своем насителе. Оснойвной задачей такого устройсва является предостваление запрашиваемой информации с носителя в нужном объеме и с нужного адреса. Это, с одной стороны, облегчает работу нам с вами, с другой стороны позволяет строить устройства, не привязанные к конкретным накопителям. Все, что мы должны уметь, это выполнить требуемое хостом действие. А действия эти не так уж и сложны(если не вдаваться во все мелочи данного протокола) — выполнять команды из набора SCSI. Я описал все необходимые из них ранее.
Далее. Раскажу немного о том, как согласно MSC bulk-only происходит обмен информацией между нашим устройством и хостом. Опознав нас свами на шине, сбросив, инициализировав и настроив наше устройство, хост посылает нам комманды в так называемом Command Block Wrapper(CBW). Содержимое этого блока разнится от комманды к команде, но самое главное, размер этого CBW остается неизменным. Это положение позволяет нам принять весь CBW при помощи V-USB не смотря на ограничение в 8 байт. Итак, приняв при помощи функции usbFunctionWriteOut CBW, мы можем выделить из него нужные нам данные, а именно — комманды, отсылаемые на исполнение хостом и параметры, которые зависят от принятой комманды. Наверняка у некоторых появится вопрос: А что же будет, если хост будет часто посылать комманды в наш адрес или мы долго будем на них отвечать??? Вот тут проявляется еще один аспект выбранного нами варианта MSD. Хост не будет посылать в наш адрес следующую комманду до тех пор, пока мы не сообщим о результате выполнения предыдущей(есть нюанс с таймаутом, но в программе для нашего устройства мы это обойдем)!!! Также хост присваевает каждому отсылаемому нам CBW уникальный тэг(или номер), так что мы можем обработать одну комманду и ответить на нее даже в случае если хост не дождался нас и отослал еще чтото в наш адрес. Вы скажете, а если мы зависли? Не беда, попытавшись пару раз и не получив никакого КПД с нашей стороны, хост просто будет нас игнарировать. С другой стороны bulk передача согласно спецификации USB не гарантирует доставку данных конечной точки, так что это дает нам дополнительное время на «ногодрыгание».
Но что-то меня опять понесло в теорию=) Давайте все-таки опишем этот самы загадочный CBW:
Вроде, на первый взгляд, ничего сложного. Теперь давайте пройдемся по его основным элементам (распишу только самые необходимые, если кому интересно, могу лично и подробнее). dCBWSignature — сигнатура блока CBW. Ничего интересного для нас, просто константа(чтото вроде USBD если смотреть в char. dCBWTag — вот это один из камней приткновения в CBW. Значение этого поля и есть тот самы номер пакета. Позже мы будем использовать это занчение для сообщения хосту орезультате выполнения операции с таким тегом. dCBWDataTransferLength — вроде понятно из названия и указывает на размер передаваемых за данную транзакцию, байт. Никогда и никого не интересовало и врядли будет. bCBWFlags — всевозможные флаги. значений много и интерпритаций еще больше. Просто не обращаем внимания. bCBWLUN — номер логического устройства, которому адресован CBW. У нас вроде одно такое устройство, но если кто будет делать картридер, то может и пригодится =) bCBWCBLength — размер переданного CBW. CBWCB[16] — вот она, полезная информация. Этот массив содержит и номер комманды, и параметры для нее, и многое другое. С этим блоком мы познакомимся позже, когда будем знакомиться с коммандами SCSI.
Мы помним, что в MSD bulk-only все транзакции делятся максинум на три этапа. Так вот, приняли мы CBW и выделили из него нужную нам информацию. Это и есть первый этап: так называемый command transport. Из приведенной блок-схемы выше мы видим, что следующим этапом в нашишем диалоге могжут быть передача данных хосту (либо прием их от него) или передача статуса обработки принятого CBW. Так вот, передача того самого статуса являестя обязательным этапом для любой комманды. Этот этап как бы подтвердает тот факт, что мы приняли от хоста CBW с номером dCBWTag и выполнили ее(вне зависимости от результата ее выполненя). Этот этап называется status transport, а данные передаются определенным блоком, имя которому CSW. Давайте опишем и его:
Эта небольшая структурка как бы является завершением транзакции MSD вида коммандв->данные->статус. Поля этой структуры означают следующее: dCSWSignature — сигнатура блока CSW (это константа, в char это USBS), dCSWTag — номер блока(должен совпадать с номером CBW, для которого высылается статус), dCSWDataResidue — разности между ожидаемым чилом байт от хоста dCBWDataTransferLength в блоке CBW и реально принятыми(при OUT передаче) и наобоот, между запрошенным чилов байт в dCBWDataTransferLength и переданным хосту. Ну и наконец bCSWStatus — результат выполнения комманды с тегом dCSWTag. Нуль — значит все впорядке, другие значения — смотрим в спецификации =))).
Ну и на последок в этапах транзакций осталась стадия передачи данных(data transport). Напомню, что этот этап не всегда присутствует в процессе общения MSD с хостом. Есть энное количество комманд, которые не требуют передачи данных. Но все же этот этап присутствует и мы его сейчас рассмотрим. Мы знаем, что данные могут передаваться как от хоста к MSD, так и наоборот(мы же помним, что мы описали 2 конечные токи in и out). Так вот, в данной реализации MSD от хоста к MSD могут передаваться только данные для записи на носитель информации, а от MSD к хосту как данные прочитанные с носителя, так и запрашиваемые хостом параметры нашего устройства.
В принципе про этапы передачи информации MSD наверное и все. Теперь я коснусь реализации всего написанного выше. Примем исходное сосояние(назовем его RxCBW)=) Хост нам не передал не байта и мы ожидаем от него CBW. Размер этого блока мы занем, а следовательно первые sizeof(CBW) приятых байт и будут CBW. Как только мы приняли CBW мы начинаем его анализировать. Анализ блока CBW начинается с того, что мы распознаем комманду, которая находиться в USB_MSD_CBW.CBWCB[0]. Значение этого байта и есть комманда, которую хост просит нас выполнить. На этом этапе, в зависимости от предложенной нам комманды, устройство может перейти в одно из нескольких состояний: прием данных от хоста(RxData), передача данных хосту(TxData) или передача статуса(TxStatus). При переходе в состояние RxData мы принимаем от хоста n байт информации, записываем ее на носитель и переходим в состояние TxStatus. При переходе в состояние TxData мы передаем хосту запрошенную информацию n байт и переходим в состояние TxStatus. Из состояния TxStatus, передав блок CSW хосту, переходим в состояние RxCBW и ожидаем новые байты от хоста. Сейчас попробую предстваить это во временной диаграмме.
Ну как-то так (я понимаю, что не все, наверное, понятно, так что готов ответить на вопросы).
Выложу немного скринов, для разнообразия
Я так пологаю, что расписывать работу с картой SD(MMC) не имеет смысла, т.к. про это написано очень много. Пожалуй опишу основные грабли, на которые я наступал в этом процессе (так думаю будет логичнее). Так вот, первое(и наверное основное), я не вседа использую внешнюю подтяжку на линии _CS карты памяти, из-за чего иногда возникают довольно большие неприятности. потому (хотя это и не очень красиво) в таких случаях я всегда первым делом настраиваю должным образом вывод _CS. Второе, не все карты, с которыми я работал(а их было не мало, поверьте), подразумевают размер блока для чтения/записи равным 512 байт. Потому при инициализации карты я страхуюсь и устанавливаю размер этого блока 512. Видел пару карт, которые поддерживали размер блока для чтения/записи в 1 байт, а есть, которые тока 2048 и ни грамом больше(тока 1 раз встречал). В данном проекте я использовал карту kingston на 1гб, хотя можно и другие, думаю проблем не возникнет. Третье, не всегда карта памяти инициализируется на максимальной скорости SPI(возможно это зависит и от разводки, использование проводов и много от чего еще), поэтому можно производить инициализацию на меньших скоростях, хотя у меня на 16Мгц все прекрасно работает на максимуме. Четвертое, линия MISO avr'ки. Я раньше не использовал внешнюю подтяжку на этом выводе, от чего поимел много головной боли. Теперь использую всегда, чего и советую начинающим. Наверное это основное, поэтому поедем дальше.
Мы разобрали процесс(или логики) работы нашего MSD. Научились принимать пакеты CBW, отправлять CSW и данные.
Файлы с исходным кодом.
Вроде как все. Если у общественности возникнут вопросы, замечания, пожелания более подробного описания или чего-то еще, то буду рад помочь!
Жду откликов, предложений и т.п. Мот у кого возникнет идея создания устройства на V-USB, то готов поучавствовать в коммандном проекте. Сейчас займусь работой с v-usb и сенсорной панелью вместо мышки=) Всем удачи!
Файлы : mmc_test.zip, MassStorage.Mega8.libusb.zip
