USB Virtual COM port on STM32, documentation analysis

The theory is perfect. You can take only a standard and a datasheet. Then simply implementing clear and univocal algorithm from the standard using opportunities of your hardware, described in datasheets. Looks like a simple lab work in the university, but the real world is a little complicated.

On the practice I have a standard whom chapters tree looks like labyrinth. And two mainstream OS whom authors do not notify me which requests and data streams their drivers are expected. That complication is unpleasant, because I never want to confess that I haven't got money for buying a multiple expensive development boards and debugging tools. I just want to write a system code who will work at the first time with any OS and software. While use of the only one 2$ integrated circuit.

Complicated standard

At basic level it is clear. For the every type of device we have a separate specification who adds it's requests and pipes to the lowest possible configuration from main USB 2.0 spec. Virtual com port considered in this post is a device of communication device class (CDC). But when we obtains that documentation we deals with a yet another heap of acronyms consisting of unobvious terms. And at that moment I could feel that I deal with a professional technology, not with child's toy. On the whole, USB-UART adapter in vision of USB IF team is a "Public switched telephone network analogue modem adapter communication device with an abstract control model". Not as obvious as it may was, but put up with it. Yet another complication is in control pipes. For VCP control null control endpoint is not enough, we need separate pipes for requests and notifications in addition to the data endpoints. And the notifications datastream protocol is not represented in documentation (USB PSTN 1.2, chapter 6.5.4), only meantioned. The problem is in that such spaces in documentation makes impossible writing stable firmware working with any OS. Suggested by the standard device structure is shown at the picture.

OS documentation analysis

Even if standard describes the feature, the OS may couldn't support it. Let's take a look to OS documentation to see what say OS driver programmers about theory what we read in standard recently. Most understandable case is linux. Linux default generic serial driver can add any CDC device if it have at least input and output bulk data streams. The whole configuration data in that case will be ignored.

The windows help website says that it can connect any communication device (a device with bDeviceClass = 0x02, bDeviceSubClass = 0x02 constants) using it's usbser.sys default driver. But this article nothing says about configuration and notification data, or this driver ignore it, or serial port configuration requests and notifications are mandatory, no information. But there is a good news in that I can make a VCP which will be connected without driver installation.

Code examples analysis

Check working code of another opensource projects. There are stm32 VCP example and LUFA library. Both of they have an additional master interface with interrupt endpoint and slave interface with data input and output bulk endpoints. Both of they have an constant who says that they supports modem AT commands, obviosly they do not need them. Both of them ignores existing configuration datastream.

Complete ICs reverse

lsusb output of both most popular USB-COM ICs like FT232 and PL2303 mixed all finally. PL have configuration interface, FTDI haven't. Why PL needs a management endpoint linux drivers do not knows. While FTDI have only two interfaces with input/output datastream pairs. Any other addictive features implemented using their proprientary protocols, drivers and PC libraries, ingnoring standard. What is acceptable but not interesting for me, as for me standards must work and give only one working solution in opposite to a heap of incompatible commercial proprietary ones.

Conclusion

An additive configuration or notification interface with an interrupt endpoint is mandatory as it sayed in standard. But existing microcontroller devices examples ignores it, i.e. it is implemented but never use. More than that some of hardware solutions haven't got any configuration interface, even if they have it, it is ignored by the driver. In that case the half standart solution with standard descriptor but with only one data interface is turned out to be an working variant anywhere. I will would try it at the following post.

As for requests, only GetLineCoding()/SetLineCoding pair is useful. They reads and sets baud rate and all other parameters of the UART interface through the control endpoint.