# Deciding between USB and UART for interfacing with a Qt application

I'm planning on writing GUI application using Qt in C++ that would interface with the microcontroller. In other words, it would be taking user input and displaying something received from the MCU.

Questions:

• does using UART over USB make sense? I have never used USB in this context but have used UART for a terminal-based embedded application before. I guess it's the speed that distinguishes them?

• does cubemx generate the driver code for USB (I doubt it but still curious) or I'd have to write the driver myself?

• I’m voting to close this question because this isn't about electronics design. Sep 14 '20 at 17:11
• @BrianCarlton it's uncomfortably opinion based and short on the details needed to make a decision, but it is very much an input into an electronic design decision - eg, use an MCU with a USB peripheral? Break out the UART to a connector? Place a distinct USB-UART chip on the board? I strongly believe in preserving the UART option in all cases, but there is an on-topic design decision here, it's just hiding behind an off-topic opinion question and a lack of detail that could be used to make a sound determination. Sep 14 '20 at 17:25
• USB CDC can use any baud rate you want, or actually, you can ignore baud rate setting, as it makes no sense unless you have a physical interface that needs a baud rate. I recall STM32 has examples how to implement USB CDC so yes, you can have a COM port by plugging in the USB to MCU. Sep 14 '20 at 17:30
• Previously I was able to use COM port by plugging in the USB to my PC connected to the MCU. Isn't that referred to as using USB for communication between a PC and an MCU? Or maybe i'm confusing the terms here... @Justme Sep 14 '20 at 19:41
• @Pokloha on what board? Does the board have direct connection from USB connector to MCU (it can be any USB device) or does the board have USB serial chip between USB connector and MCU? Sep 14 '20 at 19:53

Technically there's no such thing as "UART over USB".

What does happen is sending comparable data, sometimes with a custom USB scheme (most USB-interfaced UART chips), sometimes with the more standard CDC/ACM meant as a serial-port replacement for things like mobile data modems, but also sometimes used by MCU's with an on-board USB engine.

From a host software perspective you shouldn't assume any difference, and you should leave device drivers to the operating system. You do need to keep the millisecond-scale USB latency in mind in how you use a serial channel, but today you need to do that anyway as most host system's don't have local-bus UARTS, but can only be accessorized with USB connected ones.

From a hardware perspective, it's going to be simpler to get software working and debug it if you use the UART peripheral with an external USB-UART adapter. You can find example code for implementing a CDC/ACM virtual serial device but it will make your program structure or environment more complicated, and you can expect the connection to break any time your MCU hits a breakpoint or the program otherwise stops. When the connection breaks, the serial port will dissapear from the host operating system and your software will have to re-open it. On a typical Linux, when it comes back it will come back as a different port number (eg, /dev/ttyACM0 will become /dev/ttyACM1). It's more likely to keep the same identify on OSX and Windows but will still need to be re-opened before it works again.

If you design an STM32 board, definitely give yourself connections to a hardware UART, even if you do not plan to use it. Also have connections to the SWD pins, the reset, and the boot mode pin.

You seem to be asking for a recommendation to a bit greater degree than stack exchange sites are really meant for, but if I were designing this, in addition to leaving the possibility of a UART in all cases, I'd probably consider options like this:

• If the device is for personal use, or the serial interface will only be used occasionally, or where the device will see more time devoted to development than use, or where there need to be a lot of extremely cheap devices only occasionally connected to more expensive hosts, then UART with an external USB-UART converter module/cable.

• If the device is a product intended for end users, but it's important that the interface have the semantics of a serial port, then USB CDC/ACM implementation, with due care to the degree to which these can be confused, eg the many cases of people mistaking an obscure feature of their Mac's bluetooth implementation for their Arduino.

• If the device is a product which needs to just work, then a custom USB scheme unique to the product and its needs, and investing the effort in getting at least device-recognition level drivers signed for the needed platforms - hopefully libusb-based in at least the OSX and Linux cases.

Many years ago, I did design some products which incorporated a fixed-function USB-UART chip wrapping a UART-based MCU. But I'd probably not do that today, except in the case where the MCU is intended to host experimental end-user software, ie, where the product is a development board. The sorts of Arduino boards which have a USB-UART bridge distinct from the target processor, and the many ARM MCU demonstrations which have a second chip implementing an SWD adapter with a USB-UART mode for debug messages are good examples - but that's a development board architecture rather than a product one.

The USB connector on the Nucleo board goes to a separate ST-LINK programming MCU (F103) which provides the ST-LINK and serial port functions over USB.

The F103 connects to the target F401 via UART. The F401 does have an USB interface, but it is not wired to any USB connector on the board, so you cannot use direct USB connectivity with the F401.

So basically, on that board, all you see is the USB serial port provided to the PC by the F103, and that's all the Qt program can open to communicate via UART with the target F401 on the PA2 and PA3 pins. There is no other way to communicate via the USB connector, than the USB serial port, also known as COM port in Windows and perhaps ttyUSB device in Linux.

• so based on the following schematic, PA2 acts as an RX pin of the UART and PA3 acts as a TX pin, and each of them connects to the RX and TX of the ST-link respectively forming TX<->RX connections, yeah? google.com/… but where's the connection provided to the USB serial port by the STLink here? (3rd image from the top) luyao-han.online/diy-stlinkv2-debugger. Sep 14 '20 at 22:43
• If you look carefully, that link contains parts of schematics of a differerent board, Nucleo-F407. It does not have UART connection between F407 and F103. The schematics may also be outdated, if ST has updated to a newer version of Nucleo-F407 at some point. Only use schematics from ST website for up to date schematics of ST boards. And separate ST-Link dongles do not have UART pins, they only provide JTAG interface, while only the integrated ST-Link interfaces on boards may offer it. Clone products can offer UART pins, but they are clones and they can do whatever they want of they even work. Sep 15 '20 at 4:14
• I recall them having the entire schematic in the user manual, which I can't seem to find anymore -> (st.com/resource/en/user_manual/…). Found another schematic from a 3rd party source but still uncertain about the connection to USB port from ST-Link: dallasmakerspace.org/w/images/d/dc/NUCLEO-F401RE_Schematic.pdf Sep 15 '20 at 14:10
• The schematics are on ST website. What are you uncertain about? Sep 15 '20 at 16:04
• It's clear from the schematic that I posted earlier that the UART pins of the MCU are connected to the respective TX/RX pins of the ST-link but how is ST-Link hooked to the USB port? Sep 15 '20 at 16:27

Yes, to create Hardware independent and easy to reuse application, it will be good to utilise UART peripheral of MCU and USB-UART interface adapter(CP210X based are good ones).

That way even if you change hardware in future, you software application will stay same as almost all MCUs provide UART peripheral.

• This does not answer the question. The question is about whether to implement communication from PC application to MCU over USB as COM port or something else . Besides, regarding your answer, if the MCU already has USB interface and can implement a CDC COM port with USB, why add another chip to do UART conversion? Sep 14 '20 at 17:28
• I assume, Question is USB or 'UART over USB'. UART is available with most of MCUs vs USB. So make it hardware independent and easy to evolve, its still good to implement UART. I think I am think more of modular,agile designs. Sep 14 '20 at 18:09
• But that is exactly what I find odd in your answer. It makes no sense to me to put a separate USB serial chip there, if the MCU already has direct USB connectivity, as it will cost more money to buy the extra chip you don't need, the other components around the chip you don't need, it costs time to design it into schematics and layout, and it costs to have more PCB area dedicated to it. It would make sense to put a separate USB serial chip there, if the MCU does not already have direct USB connectivity. Especially, if MCU firmware can be natively programmed via USB too. Sep 14 '20 at 20:00
• yes, you are right when MCU has USB interface built in. Sep 14 '20 at 20:07