Usb msd что это

Обновлено: 03.07.2024

У нас на плате контроллер STM32F205VG и память AT45DB321E . Эта плата подключается к ПК и прикидывается флэшкой.

Чтобы понять как работает USBD девайс на STM32 , который эмулирует USB флэш память, придется :

1. Воспользоваться какой-нибудь программой мониторинга USB портов на ПК ( у нас под Windows).

2. Поставить printf (SWO) на всех значимых USB функциях (а еще лучше на всех функциях) типа USBD_LL_Transmit, USBD_Ctl. SWO похоже все это без труда потянет (без зависаний).

3. Не будем разделять работу с флэш памятью и USB MSD на разные потоки (НЕ используем FreeRTOS), т.к. все-равно HAL реализация USBD MSD девайса не предполагает использование потоковой модели, т.к. USBD работает из прерывания.

Прерывания USB, коллбек функции

Откуда вызываются коллбеки

Коллбеки - это функции , которые нам надо заполнить своим кодом работы с флэш памятью AT45.

STORAGE_Read_FS

Источник,откуда вызывается callback функция - это прерывание от USB канала. Итак все тайное становится явным.

Коллбек функция STORAGE_Read_FS вызывается из прерывания OTG_FS_IRQHandler .

Нам надо успеть прочитать(записать) из микросхемы памяти AT45 512байт и поскольку делается это естественно в прерывании , то возникает много вопросов.

По любому из прерывания надо выходить как можно быстрее.

Но если STORAGE_Read_FS завершается с любым результатом >=0 , то сразу идет отсылка данных хосту. А мы их еще не прочитали (надо примерно 3мс). А если надо записать, или еще круче стереть. Что все ждем в прерывании?

И как ни странно - ответ - ДА!

Что будет , если в коллбеке STORAGE_Read_FS сделать задержку более 1мс, а точнее 0.960652050 .. 1.465651240 = 0.52 секунды!

Как ни странно все нормально продолжает работать! Не смотря на , то что вызов происходит из прерывания USB.

Главное во всех функциях вызываемых из STORAGE_Read_FS, надо убрать _IT функции , т.е. не использовать функции основанные на прерываниях.

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

Почему так работает? Потому,что контроллер продолжает во время (пока мы сидим STORAGE_Read_FS) нормально отвечать NAK-ом (типа : я занят):

То есть ответ NAK. реализуется на аппаратном уровне,как-то еще до контроллера прерываний.

файлы, файлы, файлы

Выбираем спокойный день и ковыряемся в исходниках кода , сгенерированного Cube Mx для STM32F205VG USBD MSD. В каждой функции добавляем printf ().

Все , что нам надо здесь :

Весь код открытый , нам надо просто разобраться в этой каше.

USB Core

Usbd_ioreq.c
usbd_core.c
usbd_ctlreq.c

MSC - Mass Storage Controller

Usbd_msc_bot.c
usbd_msc.c
usbd_msc_data.c
usbd_msc_scsi.c

Конфигурация и Callbacks функции

Usb_device.c
usbd_conf.c
usbd_desc.c
usbd_storage_if.c

еще это

И вот теперь становится кое-то явным , что от нас скрыто

А вот тоже маленький , но уже в текстовом представлении из того же LA1010.

Получается так :

OUT,0x20,0x01. 0x05 хост посылает команду
IN,0x20,0x01. 0x05 - это запрос хоста - ну , что готовы дынные?
NAK - (и их несколько) это ответ девайса, что он принял , но не данные у него еще не готовы
SOF - (иногда) это команда от хоста (просто каждую 1 милисекунду посылается по протоколу)
DATA1 это девайс передает наконец-то данные на очередной запрос IN,0x20,0x01. 0x05 (FF FF FF . это флэшка отдает содержание первой своей страницы) это STORAGE_Read_FS
ACK это девайс рапортует, что данные передал

И дальше опять
IN,0x20,0x01. 0x05
NAK
. много раз

Почему? - наверное потому , что хосту тоже надо время подумать для передачи следующей команды.

Периоды следования запросов IN,0x20,0x01. 0x05 - намного меньше 1 милисекунды.

Выводы

Из выше проверенного понятно пока одно : исходники из CubeMX с HAL рабочие , т.е. флэшку мы реализовали.

Она форматируется нормально и туда даже можно записать сразу файл.

Но если все делать в потоках (по взрослому) , то надо все исходники переписывать и работать на уровне регистров USB.

Ниже выкладываю как обычно выстраданный проект на Atollic True Studio.

Файлы для скачивания

* STM32F205VGT6_MSD_AT45 Atollic True Studio [zip]
с SWO трассировкой, контроллер STM32 работает как флэшка , которую подключают к ПК

[* Несколько слов о книге и авторе. Здесь представлен перевод третьей части книги Йена Акселсона (Jan Axelson) "USB Mаss Storаge - Designing аnd prоgrаmming dеviсеs and еmbeddеd hosts".

Я КАТЕГОРИЧЕСКИ НЕ РЕКОМЕНДУЮ ЭТУ КНИГУ И ЭТОГО АВТОРА.

Есть, знаете ли, некоторая категория технических писателей, которые паразитируют на человеческой неосведомлённости. Таким, с позволения, "писателем" является, скажем, В.Д.Разевиг, специализирующийся на переводах справочных систем к различным программным пакетам. В условиях тотальной неграмотности населения переводы являются очень нужным делом (я и сам ими грешу). Но перевод должен сопровождаться хотя бы упоминанием источника знаний. г. Разевиг такой чепухой не затрудняется. Подобным же непотребством занимается и Акселсон, но он не ворует чужие хелпы, а списывает документы, относящиеся к стандарту USB, и обзывает их чем-то вроде "Полное руководство по шине USB ("USB cоmplеte"). Я выяснил этот печальный факт уже после того как выполнил основную работу по переводу и начал уточнять непонятные моменты в тексте стандарта. Тогда-то и выяснилась вся горечь катаклизма: плагиат чистой воды, буквально ничего своего. Он даже не утруждался стилевыми правками. То-то я удивлялся скучности и невыразительности его изложения. Переводить ещё и стандарт я уже не стал. Извините.

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

Вывод: не тратьте время на этого прохиндея, читайте сам стандарт.]

Данная глава описывает класс накопителей данных и представляет код для устройства, который демонстрирует обмен между управляющей системой и устройством. [* - не, не демонстрирует, так как книжный "код" является прямым переводом структур USB и SCSI из таблиц на естественном языке в исходники на языке Си. Если вы не можете сделать такой перевод сами, то поищите книгу в сети. ]


Общие требования

В добавление к совместимости со спецификацией USB 2.0 накопитель данных должен соответствовать требованиям класса "накопитель данных", включающих как требования к аппаратной совместимости, так и поддержке программных протоколов.


Спецификации

Класс "накопитель данных" обращается к нескольким документам. "Обзор спецификаций" (Specification Overview) и "Передача неструктурированных данных" (Bulk-Only Transport) касаются почти всех устройств. Документ "Требования к загрузочным накопителям" (Bootability) относится только к устройствам, с которых может запускаться операционная система. Два дополнительных документа - "Control/Bulk/Interrupt (CBI) обмен" и "Спецификация команд UFI" касаются только некоторых приводов гибких дисков.

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


Блоковая логическая адресация

Адреса чтения и записи данных накопителя задаются в формате блоковой логической адресации (Logical Block Address - LBA), описанной в части 1. Все USB накопители должны поддерживать доступ к данным в этом формате.


Запросы накопителей данных

В протоколе передачи неструктурированных данных (bulk-only) определены два управляющих запроса. " Bulk Only Mass Storage Reset " (Сброс накопителя данных) предписывает устройству быть готовым к приёму нового командного блока. " Get Max LUN " запрашивает наибольший номер поддерживаемого устройством логического накопителя. В операционной системе Windows каждому логическому накопителю или разделу соответствует своя буква диска. Устройство с единственным логическим накопителем должно возвращать ноль или переходить в состояние останова (stall). Устройство с двумя логическими накопителями "LUN 0" и "LUN 1" возвращает " 1 ". Максимальное значение - " 15 ". Весь остальной обмен идёт через передачу неструктурированных данных (bulk).

Центральная система может использовать управляющие передачи для выведения оконечных точек из состояния блокировки (halt), для чего следует послать устройству стандартный управляющий USB запрос " Clear Feature (ENDPOINT_HALT) ".

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

СОДЕРЖАНИЕ

Использует


Доступ к экшн-камере осуществляется через класс запоминающих устройств.

К устройствам, подключенным к компьютерам через этот стандарт, относятся:

  • Внешние магнитные жесткие диски
  • Внешние оптические приводы, в том числе приводы для чтения и записи CD и DVD
  • Портативные устройствафлэш-памяти
  • Адаптеры между стандартными картами флэш- памяти и USB-подключениями
  • Цифровые аудио и портативные медиаплееры

Устройства, поддерживающие этот стандарт, известны как устройства MSC (Mass Storage Class). В то время как MSC - это первоначальное сокращение, UMS (Universal Mass Storage) также вошло в широкое употребление.

Поддержка операционной системы

Большинство основных операционных систем включают поддержку запоминающих устройств USB; поддержка в старых системах обычно доступна через исправления.

Майкрософт Виндоус

Microsoft Windows поддерживает MSC с Windows 2000. Поддержка USB от Microsoft в Windows до Windows 95 и Windows NT 4.0 отсутствует . Windows 95 OSR2.1, обновление операционной системы, имеет ограниченную поддержку USB. В то время Microsoft не производила универсального драйвера USB-накопителя (в том числе для Windows 98 ), и для каждого типа USB-накопителя требовался драйвер для конкретного устройства. Сторонние бесплатные драйверы стали доступны для Windows 98 и Windows 98SE, а сторонние драйверы также доступны для Windows NT 4.0. Windows 2000 поддерживает (через универсальный драйвер) стандартные запоминающие USB-устройства; Windows Me и все более поздние версии Windows также включают поддержку.

Windows Mobile поддерживает доступ к большинству запоминающих устройств USB, отформатированных с помощью FAT, на устройствах с USB-хостом. Однако портативные устройства обычно не могут обеспечить достаточную мощность для корпусов жестких дисков (2,5-дюймовый (64 мм) жесткий диск обычно требует максимум 2,5 Вт в спецификации USB) без концентратора USB с автономным питанием . Устройство Windows Mobile не может отображать свою файловую систему как запоминающее устройство, если разработчик устройства не добавит эту функциональность. Однако сторонние приложения добавляют эмуляцию MSC к большинству устройств WM (коммерческий Softick CardExport и бесплатное хранилище WM5torage). Обычно можно экспортировать только карты памяти (не внутреннюю память) из-за проблем с файловой системой; см. доступ к устройству ниже.

Функция автозапуска Windows работала на всех съемных носителях, позволяя запоминающим устройствам USB стать порталом для компьютерных вирусов . Начиная с Windows 7 , Microsoft ограничила автозапуск компакт-дисками и DVD-приводами, обновив предыдущие версии Windows.

MS-DOS

Ни MS-DOS, ни большинство совместимых операционных систем не поддерживают USB. Универсальные драйверы сторонних производителей, такие как Duse, USBASPI и DOSUSB, доступны для поддержки запоминающих устройств USB. FreeDOS поддерживает USB-накопители в качестве интерфейса расширенного программирования SCSI (ASPI).

Классическая Mac OS и macOS

Apple Computer «s Mac OS 9 и MacOS поддержка хранения USB массы; Mac OS 8.5.1 поддерживала запоминающее устройство USB через дополнительный драйвер.

Linux

Linux ядро поддерживает USB запоминающих устройств , так как его серии 2.4 (2001) и портировать на ядре 2.2.18 было сделано. В Linux существует больше возможностей в дополнении к родовым драйверам для класса USB массового хранения устройства устройств, в том числе причуд, исправления ошибок и дополнительные функциональные возможности для устройств и контроллеров (производители с поддержкой функций , такими как ATA команда сквозной для ATA-USB мостов , который полезен для SMART или мониторинга температуры, управления ускорением и замедлением жестких дисков и других параметров). Это включает в себя определенную часть устройств на базе Android благодаря поддержке USB-OTG , поскольку Android использует ядро ​​Linux.

Другие системы, связанные с Unix

Solaris поддерживает устройства с версии 2.8 (1998), NetBSD с версии 1.5 (2000), FreeBSD с версии 4.0 (2000) и OpenBSD с версии 2.7 (2000). Цифровая UNIX (позже известная как Tru64 UNIX ) поддерживает USB и USB-устройства хранения данных, начиная с версии 4.0E (1998). AIX поддерживает запоминающие USB-устройства начиная с версий 5.3 T9 и 6.1 T3; однако он плохо поддерживается и не имеет таких функций, как разделение на разделы и общая блокировка.

Игровые консоли и встраиваемые устройства

В Xbox 360 и PlayStation 3 поддерживает большинство запоминающих устройств для передачи данных средств массовой информации , таких как изображения и музыка. По состоянию на апрель 2010 года Xbox 360 (a) использовала запоминающее устройство для сохраненных игр, а PS3 позволяла передавать данные между устройствами на запоминающем устройстве большой емкости. Независимые разработчики выпустили драйверы для TI-84 Plus и TI-84 Plus Silver Edition для доступа к USB-накопителям. В этих калькуляторах драйвер usb8x поддерживает приложение пользовательского интерфейса msd8x .

Доступ к устройству

Маленькая тонкая серая коробка с картой данных, вставленной в нижний слот.

USB- устройства чтения карт обычно реализуют класс запоминающих устройств USB.

Спецификация USB-накопителя обеспечивает интерфейс для ряда стандартных наборов команд, позволяя устройству раскрывать свой подкласс. На практике указание набора команд через его подкласс практически не поддерживается; большинство драйверов поддерживают только прозрачный набор команд SCSI , обозначая свое подмножество набора команд SCSI своим типом периферийного устройства SCSI (PDT). Коды подклассов определяют следующие наборы команд:

  1. Сокращенные команды блока (RBC)
  2. SFF -8020i, MMC -2 (используется приводами CD и DVD в стиле ATAPI)
  3. QIC- 157 (ленточные накопители)
  4. Унифицированный интерфейс гибких дисков (UFI)
  5. SFF-8070i (используется устройствами в стиле ARMD)
  6. Набор прозрачных команд SCSI (используйте «запрос» для получения PDT)

Спецификация не требует наличия определенной файловой системы на соответствующих устройствах. На основе указанного набора команд и любого подмножества он предоставляет средства для чтения и записи секторов данных (аналогично низкоуровневому интерфейсу, используемому для доступа к жесткому диску ). Операционные системы могут рассматривать запоминающее USB-устройство как жесткий диск; пользователи могут разделить его в любом формате (например, MBR и GPT) и отформатировать в любой файловой системе.

Из-за своей относительной простоты наиболее распространенной файловой системой на встроенных устройствах, таких как USB-накопители , камеры или цифровые аудиоплееры, является файловая система Microsoft FAT или FAT32 (с дополнительной поддержкой длинных имен файлов ). Большие жесткие диски на базе USB можно отформатировать в NTFS , которая (за исключением Windows) менее поддерживается. Однако ключевой диск или другое устройство может быть отформатировано в другой файловой системе ( HFS Plus в Apple Macintosh , Ext2 в Linux или файловая система Unix в Solaris или BSD). Этот выбор может ограничить (или запретить) доступ к содержимому устройства для оборудования, использующего другую операционную систему. Варианты хранения, зависящие от ОС, включают LVM , таблицы разделов и программное шифрование.

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

Производители предварительно отформатированных устройств используют две основные схемы разделения. Один помещает файловую систему (обычно FAT32) непосредственно на устройство без разбиения на разделы, заставляя ее запускаться с сектора 0 без дополнительных загрузочных секторов, заголовков или разделов. Другой использует таблицу разделов DOS (и код MBR), причем один раздел охватывает все устройство. Этот раздел часто выравнивается по высокой мощности двух секторов (например, 1 или 2 МБ), что является обычным для твердотельных накопителей для производительности и долговечности. Некоторые устройства со встроенным хранилищем, напоминающие USB-накопитель (например, MP3-плееры с USB-портом), сообщают о повреждении (или отсутствии) файловой системы, если они переформатируются с использованием другой файловой системы. Однако большинство устройств с разделами по умолчанию можно переразбить (уменьшив первый раздел и файловую систему) с помощью дополнительных разделов. Такие устройства будут использовать первый раздел для своих операций; после подключения к хост-системе все разделы доступны.

Устройства, подключенные через один порт USB, могут функционировать как несколько устройств USB, одно из которых является запоминающим устройством USB. Это упрощает распространение и доступ к драйверам и документации, в первую очередь для операционных систем Microsoft Windows и Mac OS X. Такие драйверы необходимы для полноценного использования устройства, обычно потому, что оно не соответствует стандартному классу USB или имеет дополнительные функции. Встроенное запоминающее устройство USB позволяет устанавливать дополнительные драйверы без дисков CD-ROM, дискет или доступа в Интернет к веб-сайту поставщика; это важно, поскольку многие современные системы поставляются без оптических дисководов или дисководов для гибких дисков. Доступ в Интернет может быть недоступен, потому что устройство предоставляет доступ к сети (беспроводная связь, карты GSM или Ethernet). Встроенное запоминающее устройство USB обычно постоянно предоставляется производителем только для чтения, что предотвращает случайное повреждение и использование для других целей (хотя оно может быть обновлено с помощью проприетарных протоколов при обновлении прошивки). Преимущества этого метода распространения - более низкая стоимость, упрощенная установка и обеспечение переносимости драйверов.

Дизайн

Некоторые расширенные команды жесткого диска , такие как Tagged Command Queuing и Native Command Queuing (которые могут повысить производительность), ATA Secure Erase (которая позволяет безопасно стереть все данные на диске) и SM

ART (доступ к индикаторам надежности диска) существует как расширение наборов команд нижнего уровня, таких как SCSI , ATA и ATAPI . Эти функции могут не работать, если диски помещены в дисковый корпус , поддерживающий интерфейс USB-накопителя. Некоторые интерфейсы USB-накопителя являются универсальными и предоставляют базовые команды чтения-записи; хотя это хорошо работает для базовой передачи данных с устройствами, содержащими жесткие диски, не существует простого способа отправлять расширенные, зависящие от устройства команды на такие запоминающие USB-устройства (хотя устройства могут создавать свои собственные протоколы связи через стандартный интерфейс управления USB. ). Протокол USB Attached SCSI (UAS), представленный в USB 3.0, устраняет некоторые из этих проблем, включая очереди команд, каналы команд для оборудования, требующего их, и управление питанием.

В определенных наборах микросхем USB 2.0 были запатентованные методы обеспечения сквозного подключения SCSI, которые можно было использовать для чтения данных SMART с дисков с помощью таких инструментов, как smartctl (с использованием параметра -d, за которым следует «набор микросхем»). Более поздние наборы микросхем USB-накопителей поддерживают преобразование SCSI / ATA (SAT) в качестве общего протокола для взаимодействия с устройствами ATA (и SATA). Использование скрытых команд ATA или SCSI (таких как безопасное стирание или защита паролем), когда диск подключен через мост USB, может вызвать сбой диска, особенно с помощью утилиты hdparm .

Проект создаём из проекта I2CLCD80. Назовем его USB_HOST_MSC_FATFS. Запустим проект в Cube, включим USB_OTG_FS в режим Host_Only включим там Activate_VBUS.

image03

В USB_DEVICE в разделе Class For FS IP выберем пункт Mass Storage Host Class

image05

Лапки портов PD4-PD7, PB8, PB9 отключим, это пережиток прошлых занятий

image04

В разделе FATFS включим USB Disk

image07

Лапку PC0 включим на выход

image06

Включим на выход ещё лапки портов отвечающие за красный и зеленый светодиоды

image01

В Clock Configuration выберем следующие делители (нажмите на картинку для увеличения изображения)

image00_0500

В Configuration прерывания там выставились сами.

Единственное можно включить поддержку кластеров до 4 кб

image02

Сгенерируем и запустим проект, подключим lcd.c и настроим программатор на автоперезагрузку.

В main уберем весь пользовательский код кроме инициализации и очистки дисплея

/* USER CODE BEGIN 2 */

/* USER CODE END 2 */

В файле usb_host.c подключим файл для файловой системы

/* USER CODE BEGIN 0 */

/* USER CODE END 0 */

Также в этом файле кое-что заменим в функции USBH_UserProcess

static void USBH_UserProcess (USBH_HandleTypeDef *phost, uint8_t id)

/* USER CODE BEGIN 2 */

f_mount(NULL, (TCHAR const*)"", 0);

/* USER CODE END 2 */

В файле main.c объявим некоторые переменные

/* USER CODE BEGIN PV */

extern ApplicationTypeDef Appli_state;

FATFS USBDISKFatFs; /* File system object for USB disk logical drive */

FIL MyFile; /* File object */

extern USBH_HandleTypeDef hUsbHostFS;

/* USER CODE END PV */

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

/* USER CODE BEGIN 0 */

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_12, GPIO_PIN_SET);

/* USER CODE END 0 */

Добавим код в бесконечный цикл

/* USER CODE BEGIN 3 */

/* USER CODE END 3 */

Подключим флеш-диск к компьютеру, создадим на нем текстовый файл «123.txt» с каким-нибудь содержимым, извлечем его из компьютера.

Подключим контроллер, флеш-диск к нему через кабель OTG.

Соберем проект, прошьем контроллер и посмотрим, попадём ли мы в нашу функцию по свечению зеленого светодиода.

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

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_12, GPIO_PIN_SET); // здесь видим, что мы сюда попали

FRESULT res; /* FatFs function common result code */

uint32_t byteswritten, bytesread; /* File write/read counts */

uint8_t rtext[100]; /* File read buffer */

Вызовем функцию подключения нашего флеш-диска. Результат также смотрим с помощью светодиодов

uint8_t rtext[100]; /* File read buffer */

if(f_mount(&USBDISKFatFs, (TCHAR const*)USBH_Path, 0) != FR_OK)

/* FatFs Initialization Error */

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_12, GPIO_PIN_RESET);

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_14, GPIO_PIN_RESET);

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_12, GPIO_PIN_SET); // здесь видим, что мы сюда попали

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

if(f_mount(&USBDISKFatFs, (TCHAR const*)USBH_Path, 0) != FR_OK)

/* FatFs Initialization Error */

if(f_open(&MyFile, "123.txt", FA_READ) != FR_OK)

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_12, GPIO_PIN_RESET);

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_14, GPIO_PIN_RESET);

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_12, GPIO_PIN_SET); // здесь видим, что мы сюда попали

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

if(f_open(&MyFile, "123.txt", FA_READ) != FR_OK)

res = f_read(&MyFile, rtext, sizeof(rtext), (void *)&bytesread);

if((bytesread == 0) || (res != FR_OK))

В следующей части данного занятия мы попробуем создать файл и записать в него информацию.

STM32 USB. Host Mass Storage Class

20 комментариев на “ STM Урок 36. USB. Host Mass Storage Class. Часть 1 ”

Чем обусловлено изменение кода USBH_UserProcess?

f_mount(NULL, (TCHAR const*)"", 0);

и здесь (в тексте статье удаленный элемент отсутствует):

Следующее: "Лапку PC0 включим на выход". Зачем включали, если нигде не используем возможность отключения питания на устроймтво?

Нельзя. Нужен USB OTG интерфейс. Подойдут, например, stm32F105, stm32f107 или любые другие с интерфейсом USB OTG_FS или USB OTG_HS.

STM32 MSC for SD in SPI mode

Thanks Silvio
(sorry for the language)

в исходнике изменения в USBH_UserProcess вообще не сделаны. Более того, программа вообще не обращается к этой функции. По-крайней мере, явно. я не увидел. и вообще не работает, а ваш исходник даже не собирается. в чем дело?

По всей видимости, что-то изменили со времён выхода урока в HAL.

А какая ошибка при сборке?
Хотя даже ещё один вопрос предварительный, так как от Вас очень мало данных:
Что именно не собирается? не генерируется проект в Cube MX (надеюсь объяснять не надо, чтобы версия Cube была та же какая была во время выхода урока, иначе пляски с бубном) или проект нормально генерится, но потом не собирается в Keil?

1. не находит USBH_Path, впрочем, я нашел пример, откуда вы взяли ваш пример и там USBH_Path декларируется.
2. однако ж, больше интересно про USBH_UserProcess?

При входе в этот модуль
LCD_Clear()
LCD_SetPos(0,0)
LCD_String((char*)rtext)
f_close(&MyFile)
зависает в первой же функции, пробовал в дебаге
а также зажигал диод в разных местах, после LCD_Clear() не горит.
А вот запись на флэш получается.
Ну и заодно огромное СПАСИБО за ваш нелёгкий труд!

Более подробно: в дебаге очищает экран LCD_Clear() и далее виснет на двух функциях
в файле stm32f4xx_hal.c
__weak uint32_t HAL_GetTick(void)
return uwTick;
>

Всем привет, Подскажите stm32f103С8Tx способен работать как USB HOST. Все примеры что нашел, это имитация HID устройств. А у меня задача USB клавиатуру подключить к МК.

Здравствуйте, прежде всего большое спасибо за ваши уроки, вы лучшие.

Я следил за вашей SD-картой с помощью SPI и FATFS Tutorial, и это было замечательно, оно работало отлично.
Я хотел бы реализовать подключение USB этой работы. Я хочу добавить устройство USB Mass Sotrage в проект SPI FATFS на SD-карте.
Я использую ядро STM32F072RB, и я использую внутреннюю конфигурацию часов.

Спасибо большое! Я остаюсь внимательным. Ты самый лучший!

Hello, fist of all thank you very much for your tutorials, you are the best.

I have followed your SD Card with SPI and FATFS Tutorial and it was wonderful, it worked perfect.
I would like to implement a USB connection of that work. I mean, I would like to add a USB Mass Sotrage Device to the SD Card SPI FATFS project.
I am using a STM32F072RB Nucleo, and I am using internal clock configuration.

Thank you very much! I remain attentive. You are the best!

После просмотра не понятно как переменная USBH_Path должна быть объявлена и проинициализирована.

Это стандартная переменная USBHPath. Не надо ее объявлять и инициализировать ИМХО

Нашел решение. Неделю возился не видел, у Вас уже помощь попросил и решил еще раз все проверить, строчка за строчкой. Итак Cube в main.c в фукцию int main(void) вставляет вызов MX_USB_HOST_Init(), в этой инициализации есть вызов USBH_Start(&hUsbHostFS), далее вызов USBH_LL_DriverVBUS(phost, TRUE), в итоге вызывается MX_DriverVbusFS(state). В параметре передается TRUE. А вот описание:

void MX_DriverVbusFS(uint8_t state)
uint8_t data = state;
/* USER CODE BEGIN PREPARE_GPIO_DATA_VBUS_FS */
if(state == 0)
/* Drive high Charge pump */
data = GPIO_PIN_SET;
>
else
/* Drive low Charge pump */
data = GPIO_PIN_RESET;
>
/* USER CODE END PREPARE_GPIO_DATA_VBUS_FS */
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_6,(GPIO_PinState)data);
>.

Т.е. при конфигурировании USB_OTG_FS в режиме HOST only на PG6 (для NUCLEO-F767ZI управление VBUS) выдается низкий уровень. Должно быть наоборот иначе как запитать USB флешку. В примере от ST (FatFs_USBDisk), который у меня работал изначально, логика верная. Там в итоге череды вызовов вызывается:

USBH_StatusTypeDef USBH_LL_DriverVBUS(USBH_HandleTypeDef *phost, uint8_t state)
if(state == 0)
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_6, GPIO_PIN_RESET);
>
else
HAL_GPIO_WritePin(GPIOG, GPIO_PIN_6, GPIO_PIN_SET);
>

HAL_Delay(200);
return USBH_OK;
>

Параметр state == TRUE, на PG6 высокий уровень, выключатель U12 выдает запитывает USB флешку и светодиод LD8 светится, а я улыбаюсь.

Вот и причина неработоспособности. В итоге сам спросил, сам ответил))). Но может кому понадобится. Спасибо за внимание.

Возможно, что-то изменилось в библиотеках. Посмотрите примеры в репозитории.

Читайте также: