虽然ARM mbed认为USB不应该归类于IoT。但我依然认为在IoT Gateway设计中，基于USB的DFU/CDC-ACM/CDC-ECM是必须得到支持的。
- DFU用于固件升级；
- ACM可以用于一些简单的转换设计，比如SPI/I2C/GPIO/LIN的转换；
- ECM可以用于网络相关的设计，可以直接提供socket接口，比如socket CAN，还有IPv6/6LowPAN等。
在对内核缺乏了解的情况下，只有通过不同的固件来做黑箱测试了。来自ARM mbed的STM32 USB CDC代码本质上依然是来自STM Semicon CubeMX的C HAL SDK代码，但是却被封装为C++了。其中F4XX是mbed官方移植版，F1XX/0XX是第三方移植的，但不知为何第三方固件虽然也源自ST固件，在Ubuntu 12.04/14.04中却工作不太正常，目前仅支持Windows系列操作系统，以及Ubuntu 15.04以上版本。而F4xx的USB堆栈虽然工作正常，但是价格偏高。
USB CDC + ?
不管如何，将USB CDC/HID堆栈和其他低速I/O进行整合，是常见的设计方式。今天我完成了CDC/ACM收发演示程序，但是硬件流控和波特率引脚还没有配置好。可能会针对I2C元器件，SPI总线的RF收发器、CAN/LIN收发器、LED/LCD/OLED显示屏、RFID/NFC读卡器等做些桥接。以实现连接模块、传感模块的热插拔。
STM32F103无法支持USB/CAN同时操作，如果使用USB，则只可以通过SPI外接CAN控制器和收发器。这一点上说，STM32F103 + CAN controller + CAN transceiver缺乏实际意义。必须使用STM32F072来替代，甚至LPC11CXX都比STM32F103信价比高。但如果节点使用STM32F103 + CAN transceiver，不使用USB，性价比和F072是一样的。
至于ECM，需要学习更多的内核和驱动编写技术。
更新
偶尔发现，我所谓的USB CDC不工作，其实是工作的。但是USB设备枚举后，会stall好一会儿才开始收发数据。这应该和操作系统无关，但是和硬件的晶振以及固件中断配置有关。这种现象在OpenWRT/Ubuntu 12.04/Raspibian上都可以验证。换而言之，基于STM32的USB CDC的IoT设备已经具备可行性。搁置的项目可以继续了。
