STM32_USB_DIY(三) --- Custom HID (三) ：PC 端應用軟體及韌體開發

上回已經把我們所需要的驗證開發平台都做一個簡單的整理與介紹了。

接下來我們就可以開始拿原廠所附的參考原始碼做一個簡單的驗證開發了。

不過，因為USB 的東西，肯定是需要PC 端的軟體配合，尤其是這一種屬於

比較客製化的 Custom HID 的東西，雖然HID 是不需要PC端的驅動程式，

但還是得要準備自己的上層應用軟體，這個不像一般標準的Virtual COM 可以

用超級終端機；或是用一般俗稱隨身碟的MSDC，可以用電腦的檔案管理員。

Custom HID 就得要有自己的應用程式，上一篇我們也有提到原廠也有針對

這個範例程式所提供的應用程式：USB HID Demonstrator (V1.0.2)：

但這個程式真的太複雜了，一般新學者對於這樣子的軟體真的太難了。

我是有自己的軟體開發習性，還是選一個自己比較上手的方式開發吧。

當然啊，原廠所提供的程式就是給我們一個參考，就像原廠這支Custom HID 韌體

我們也只是先參考一下，然後還是會依照我們的實際需求，而進行改寫的。

就看每個人對於這樣子的學習條件與未來系統需求而定吧。

只不過，現在因為軟體開發工作跟我們那個年代不同了，不是每個人都還那麼

喜歡用 C 語言來開發上層應用軟體，那還是得看你如何從你所熟悉的工具去找出

適當的軟體開發工具平台吧，我們老人家用的方式你就加減參考一下吧。

上圖這個是我自己用我自己比較習慣的方式所寫的上層應用軟體。

他是用微軟的 Visual Studio 2010 的 MFC  所寫成的。重點還是在於USB 的相關功能吧。

因為軟體的東西，基本上是看不到你的裝置端系統所採用的USB MCU的，

這個東西基本上跟你所採用的 USB MCU (不管是八位元或32位元的MCU)都是一樣的。

所以有些東西你也可以參考以前我在八位元所講的軟體東西：

USB DIY-- 自學計畫（十）

USB DIY-- 自學計畫（十一）

---

當然這個軟體的架構，基本上還是跟你USB 裝置所宣告的USB HID Report Descriptor

內容是息息相關的，上一篇文章的最後我們也有交代一下原廠這一支範例程式的

一些USB 相關宣告，所以我們主要就是有SET REPORT 及SET FEATURE的輸出，

及EP1 的INTERRUPT 輸入，軟體上我們也是用類似原廠軟體的LED 燈號控制方式

來下達USB HID 輸出，而在EP1 的輸入方面，我們就用一個簡單的 List Control 表單

依序把USB 裝置所回報的USB 內容顯示出來。好吧，我們就先直接結果吧：

在影片中：我們可以透過UART 的超級終端機與PC 端的軟體操作，我們就可以

很快地了解到USB Custom HID 與PC 軟體如何交互作用關係了。

用USB 來搞PC 端的資料交換或控制方式無非就是如此這般而已。

我說過：基本上還是跟一般UART 的TX/RX 道理是一樣的。

---

但這個展示影片中有一個很奇怪的現象：

那就是我們用EP0 的SET Feature 的方式下命令時，我們的韌體卻會執行兩次點燈

控制，而用一般EP1 的SET Report 方式不會。

所以我跟你常說過：人非聖賢，原廠的工程師也是人啊，他們也是會犯錯的。

你不要以為拿到原廠範例程式，就認為這個程式就標準無誤的程式，你自己真的要小心

了。很搞笑的是：這是最新版本 4.1.0 的錯誤，舊版不會有這個問題。而且更搞笑的是：

原廠在程式庫更新說明中，還特別強調說：這個就是為了解某些BUG 而修改的，

Update History

V4.1.0 / 26-May-2017

Main Changes

• Official release to support  STM32F302x8 and STM32F303xE devices
• Use latest version of STM32F10x, STM32L1xx , STM32F30xx HAL  and CMSIS (for more details refer to each component's release notes)
• STM32_USB_FS-Device_Driver
• usb_core.c
• Add test variable (DevRemoteWakeup) to solve issue regarding the device cannot wake USB host when receiving a second SUSPEND.
• Fix issue in function DataStageOut regarding reporting status results for status IN stage.

而且這個問題已經更新三年多了，竟然也沒人發現。他的這段程式如下：

他的說法是為了USB Spec：Section 8.5.3.1 的規格說明。但這一部分早在USB 1.1 就有了。

只是他所加入的那行程式碼的位置不對，而應該移到上圖所示位置。

你應該要知道原廠的程式為什麼要這麼寫的？因為當USB 傳輸出了問題(STALL)，

我們系統應用程式怕會斷了，死在那裏，所以乾脆在回STALL 之後，執行一下

我們的應用程式，但如果系統沒有發生問題時，那原廠這支程式會跑兩次

    (*pProperty->Process_Status_IN)();

這段程式碼，原來在正常完成USB 標準協議之後，本來就會跑一次了。

真的是不改還好，越改BUG 越慘...唉，這個程式還是標準程式庫裡的函數呢。

(一般我們都會把他鎖住，而不能修改的。)

----

好了，你以為原廠的程式就這樣子而已嗎？錯，他還有另一個問題：

因為他原廠原來的程式是一開始時，四顆LED 是亮著的，然後在USB 插入時，

才會把LED 關掉，這好像很合理，但他程式裡關燈的程式碼是在上圖中。

我們透過UART 除錯軟體監看時，發現：他根本在我們USB 插入時，執行了兩次，

這當然不合理啊，所以他所給的範例程式也是錯的，很簡單：他程式中把一般標準

Chapter 9 標準命令跟一般 Class 的應用命令給混在一起了。

如果你沒有留意這一點的話：你系統當然就會覺得怪怪的，怎麼會突然會被其他

不明原因給干擾了？尤其USB 的東西非常在意系統相容性問題的。

而且USB 插入偵測與USB系統初始化，也不是這樣子做的。可見這是一般寫軟體的人

用自己寫PC 軟體概念寫的東西。

所以這個問題的解法是：將一般USB Chapter 9 標準命令與我們Class 命令組，

分開處理：

如上圖所示，這樣子我們就可以把這個問題給解了。

基本上，光我自己在驗證跑原廠所提供的USB Custom HID 範例程式時，

就發現了這些問題，有些還是屬於原廠所提供的標準底層函數庫的內容。

所以你平常要使用這些函數庫時，還是要多留意一點。

---

當然這些都不是一個很簡單就可以察覺發現的問題，有些真的是我個人經年累月

所得的一些經驗，當我在跑USB 這些程式時，往往有些我一覺得不對的地方，

他就可能會出錯，可能就是所謂的"莫非定律"吧。

而這些基本上還是都是屬於很基本的 Tx/Rx 的在系統上的使用的基本概念。

當然原廠這支範例程式跟我們一般USB 或是 UART 通訊協定程式還差很遠，

因為這些命令在下達或資料在交換時，還是沒有系統上檢查機制，

雖然USB 已經幫你保證傳輸內容無誤了，但在系統上的 Handshake 或是

系統穩定性的問題，這些原廠程式都沒有幫妳做到，這些還是都需要你自己

慢慢地去完善他，當然啊，基礎上，你就得對USB 的基本傳輸功能規格，

及PC 端應用軟體與韌體開發之間的關係還是要掌握才行。

而以我本身的經驗，這樣子簡單的三個步驟與三篇文章的交代，

我是可以掌握到 stm32 這一顆MCU 關於USB 介面的處理方式了。

不知道你還缺哪方面的了解呢？當然啊，USB 的系統應用千百種，

每一個人或每一個案子的系統需求與規範都不同，甚至還要求做到

以USB 介面完成韌體升級功能等等，這些都是從這些很基本的USB

架構出發的。

所以關於 stm32 USB 的 Custom HID 的說明的介紹，就先告一段落，

往後關於 stm32 的USB 系統應用可能就不會再從這個原廠的範例程式

再說明了。

感謝你的點閱。下回繼續。謝謝。