You might (or might not) be interested in the conclusion of some of our
investigations with a colleague of mine concerning the use of the ST
USB driver (STM32_USB-FS-Device_Lib_V4.0.0 archive) and the conclusion
we reached of mixing libstm32 and libopencm3 software.
Just as an introduction, why not use libopencm3 in the first place ? I need
to add USB support to legacy software all written at a time when libopenstm32
was not stable to be considered (neither was libstm32, but then ...) so I end
up with a rather large piece of code to which USB must be added. On the other
hand, as discussed on at least one thread on the web (https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2FUSB%20OTG%20HOST%20Enumoration&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=956) the libstm32 USB support will not compile out of the box (or
not at all in my case) using gcc as provided by SAT.
So based on the libopencm3 usb-cdcacm example, I managed to mix enough libstm32
software to remain compatible with my legacy software with no need to re-write
all hardware initialization, while obtaining the additional USB support I needed.
The piece of software, which operates simultaneously the USART using libstm32
and USB using libopencm3 is at http://sequanux.org/jmfriedt/t/usb_cdcacm.tar.gz
for you to enjoy. The Makefile.include is a significant part of the compilation