stm32--USB（作為U盤）+FatFs的實現

一、USB功能的添加（作為U盤）

添加文件

將官方庫中的Library文件夾中的所有有效文件添加到工程中，分為4個文件夾：

1. usb class為硬件相關(Library\Class)；
2. usb driver為底層驅動(Driver)；
3. usb library為設備核心庫(Library\Core)；
4. usb application為自建目錄，存放上述三個文件夾中的各需要修改的template文件（.c.h各2個），和官方例程中的幾個文件（3個.c1個.h）。
5. 前三個目錄下的文件均為只讀，不修改；移植時只修改usb application目錄下的文件。

移植修改

1. usbd_desc.c、.h, usbd_pwr.c, usbd_usr.c：來自官方例程，不修改
2. usb_conf.h：去掉eval相關的兩個.h包含；添加#define INTERNAL_PULLUP
3. usbd_conf.h：刪除MSC Class之外的所有Class defines；修改MSC_MEDIA_PACKET為單扇區大小（4096）
4. usb_bsp.c：
1. USB_BSP_Init函數：修改輸入參數，符合頭文件；使能USB APB時鍾；將RCC_USBCLK_HSI48選為USB CLK；配置CRS（時鍾恢復系統）。
2. USB_BSP_EnableInterrupt函數：配置、使能USB中斷。
5. usbd_storage.c：
1. 將USBD_MICRO_SDIO_fops的定義移到相關函數聲明下方，修改STORAGE_GetCapacity函數第三個參數的參數類型（2處），為STORAGE_Inquirydata加上強制類型轉換
2. 修改STORAGE_GetCapacity、STORAGE_IsReady、STORAGE_Read、STORAGE_Write函數。

調試修改

出現的問題：編譯一直無法通過，提示某些宏定義不存在——可是它們都已經正確地定義了。

解決：將SPIFlash的頭文件從usbd_conf.h中移走，僅在usbd_storage.c中包含，問題解決，原因未明。

 

二、USB與FatFs不沖突的方案選擇

 USB和FatFs都會操作SPIFlash、對文件頁表、目錄表做出修改。如果同時在程序中開啟USB、掛載FatFs，有可能出現同時修改文件頁表、一方修改文件數據與另一方修改文件頁表沖突、二者操作SPIFlash沖突等情況，導致系統崩潰。

為了避免這個可能會發生的問題，設想了三種方案：

1. 方案1：在需要用FatFs寫入時禁用USB中斷，檢測完畢打開中斷。
   1. 程序中的現象：程序可以正常運行，USB功能沒有崩潰；但可能是由於禁用USB中斷后沒有清空中斷標志位，使能中斷后有時會錯誤地進入中斷（不影響程序功能）。
   2. PC端的現象：在程序禁用USB中斷后，PC端依舊能看到可移動磁盤，但無法正常對其進行有效操作；使能中斷后，PC又可以正常訪問可移動磁盤。
   3. 選擇：這種方法雖然可行性、操作性上沒有問題，但這是不合規范的、有風險的，如果有更優方案，應選擇更優方案；如果找不到更優方案，只能選擇此方案。
2. 方案2：通過三極管，在需要用FatFs寫入時斷開D+D-。
   1. 因需進行硬件修改，暫時無法測試，但這可能是手機上選擇充電模式/傳文件模式的原理。硬件上直接斷開這兩根線，相當於拔出了USB線（僅保留供電），理論上完全可行，並且沒有風險。
   2. 選擇：此方案優於方案1，但需要對硬件進行更改，如果有其他方案優先選擇不更改硬件的方案。
3. 方案3：僅在需要USB時初始化USB（其他中斷控制），其他時候不初始化USB。
   1. 實現方式：開機后不初始化USB；在收到設定的某個中斷時（比如串口收到"connect"）break出原while(1)，初始化USB；收到另一個中斷信號后（比如串口收到"disconnect"），軟件復位單片機。
   2. 測試結果：完全可行，USB和FatFs在完全分隔開的兩端程序中，完全沒有交叉，不會互相影響；也不用擔心USB的注銷問題，直接軟件復位即可。
   3. 選擇：選擇方案3。