* The Overview
前日，接到老板部署的任務，將現有的基于STM32L151與L432的LoRaWAN程序中添加USB CDC(Communication Device Class)功能，并枚舉為VCP(Virtual Com Port)用以替代以往的串口打印。很疑惑為什么以前架構代碼的時候沒有添加進去。。。估計是那時候大家都不太懂CDC。
以前的開發板通過CP210X芯片來進行串口轉USB，實測效果并不太好。
CP210X芯片在WIN7電腦上還必須得手動安裝驅動，最關鍵的成本，又是一部分開支。
在重新設計了L151、L432節點之后，取消了板載的CP210X轉而通過VCP方式是聰明的選擇。
? 在調試VCP過程中并不是想像中的非常順利，雖然在CubeMX生成的VCP代碼中很容易就搞通了VCP部分，直插L151mircoUSB口之后可以觀察到PC顯示成功枚舉成了VCP，并且打印也比較順利。
? 在VCP的驗證中沒有遇到許多朋友描述的heapsize0x200導致CDC枚舉失敗的問題，但在將VCP部分移植到LoRaMAC中時，工作與工作量變得復雜了起來。因為LoRaMAC對晶振時鐘配置和外設中斷的配置要求比較復雜，以及現有的LoRaMAC工程的啟動文件HAL庫等文件與新版本有較大不同，導致VCP植入后原本的LoRaMAC程序不能運行。對基本毫無移植經驗的我來說，還在移植過程中踩了不少的陷阱。。。
為了避免以后的工作中有類似的開發需求，所以在此對移植過程中所遇見的比較重要的某幾處地方做一個筆記：
1. 首先需要注意的是端口映射，許多的STM32芯片支持端口映射和IO復用，例如可以在不同的引腳做相同的外設。所以在配置外設端口時需要注意請不要犯跟我一樣的低級錯誤，配置PB67，測試PA910.....
2. 注意移植的宿主代碼中是否有對IO進行的低功耗處理，在許多高性能，低功耗設備應用場景中，為了做到最低的功耗，往往會對沒有用到的IO口做低功耗處理，一般做法為將IO置為input。此時在移植程序時，例如在移植VCP功能時需要檢查確保PA1112引腳沒有進行低功耗處理。
3. 對于新生成的STM32工程，Cube會把一般外設的中斷處理(Handler)函數放到一個叫stm32xxx_it.c文件里，但往往老舊的工程代碼會擁有自己的中斷處理函數，有可能在編譯沒有出現重復定義的情況下他會默認執行的處理函數并不是你想要的那一個，導致你完全找不到原因！所以在處理中斷處理函數時必須要小心注意并做相應的調整。例如中斷優先級，搶斷優先級，也即是對循環嵌套的配置，對于代碼邏輯是否合理。
?
在排除了晶振和中斷優先級以及驗證SPI通訊正常等各種因素之后，LoRaMAC程序依然存在這無法接收下行幀的問題。此問題暫未解決，待后天出差回來之后再研究。
?
?
?
?
---有事做，有人愛，有所期待
?
)
)
)
)
