* 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程序依然存在这无法接收下行帧的问题。此问题暂未解决，待后天出差回来之后再研究。
---有事做，有人爱，有所期待
)
)
)
)
