Looking for a suitable MCU for USB to 4 UART and I2C

[Bill_W]

Hi Sir,

I'd like to choose STM32F103V/R/Z to achieve the USB to 4UART and I2C in my system.

Because it's said this MCU's USB support up to 8 bidrectional end ports. I don't know whether it's right or not.

Could you help to review it or propose another suitable MCU? Thanks a lot.

 

[BarryWhit]

 

See this related thread from a few months back, specifically the comments in which @gbm shares his experience.

[Pavel A.]

What is the host on the picture?

If you want the UARTs of STM32 behave all independently as "virtual COM ports", and work with in-box Windows driver, you'll need 4 sets of endpoints for 4 CDC ACM interfaces. And some endpoints for I2C function, which does not have a "standard" driver in Windows.

If you can go for a custom software interface (winusb or libusb API), then all the functions can be handled with a few endpoints: maybe just 4: IN interrupt, IN bulk and OUT bulk and the EP0. STM32 program will multplex and buffer data for the bulk EPs.

[Bill_W]

Could you help to check if need to customize VCP drivers for different OS? 

[Pavel A.]

Which different OS you need to support?

All current Windows versions have in-box VCP drivers. All decent Linux distros have such drivers. Not sure about MAC OS but expect the same.

That's it. If you want a single VCP interface (or two) - no need to customize host VCP driver, instead ensure that firmware behavior is compliant. Once Microsoft used to have a test suite for custom hardware and drivers, so called HCT (hardware compatibility test) or WHQL. it performs thorough test for various scenarios - I/O stress, sleep, hibernation, restart of drivers etc. You can check the current state of this on Microsoft Q&A forum.

If you want to have more separate "channels" than possible with standard USB CDC interfaces, this can be done without a custom driver, just use winusb or libusb with small number of EPs and multiplex in software. Nothing custom in this case as well.

Worst variant is wanting too many independent VCPs exposed to applications as  separate devices. This requires a custom driver. This want comes with a price tag ))

[Bill_W]

You can consider the Host as a server which is to print the system log thru USB port. I2C is connecting Host's BMC. Yes, your understand is all right.

And how about STM32U575 which have 5 IN and 5 OUT EPs and EP0?

[Andrew Neil]

---

@Bill_W wrote:

You can consider the Host as a server which is to print the system log thru USB port.

---

Then why does it need to emulate 4 separate UARTS?

Why not just have the microcontroller send all its information on a single VCP?

:thinking_face:

[Bill_W]

There're 4 ASIC's UART log independently output frequently. 

[FBL]

Hi @Bill_W 

Given the specifications from the datasheet, the STM32F103 series could be a suitable choice for your application for one single CDC not 4 CDC ACM interfaces. U575 provides greater flexibility embedding UCPD controller and is well-suited as well.

As @Pavel A. mentioned:

EP0 used for control requests

EP1 IN used to send notifications to host

EP2 IN used to send UART data from MCU to host

EP3 OUT used to receive UART data from host to MCU

[waclawek.jan]

As @Pavel A. said above, if you want somewhat "out of the box" solution, you'll go for the CDC ACM a.k.a. VCP; and as said in the thread @BarryWhit linked to above, for VCP  you essentially need 2 pairs of IN endpoints (one in/out pair plus one extra in endpoint). If you'd solve the I2C using VCP too, which is probably a sane expectation, that, plus the default/control EP0 pair is 5x2+1 = 11 endpoint pairs.

AFAIK no STM32 has this in one USB module (you could use two in some STM32, but that means two cables, too, or a hub chip, both somewhat cumbersome solutions); so you either go for some different solution - custom driver on host side and custom (your own) USB class/protocol, where you'd multiplex several or all UART/I2C data into one pair of endpoints - or use a different mcu which does that much endpoints natively. If host is something you design too, this may be a quite viable option.

JW

[BarryWhit]

The endpoint math can be a bit confusing (I know, since I made such mistakes in that thread), so I suggest you read the thread carefully.

Bear in mind that the throughput of a VCP is unrelated to the serial baud rate you set (in that context, it's just a piece of metadata). The throughput depends instead on the USB interface (FS/HS) and software/CPU performance.

I don't have hard numbers for USB HS, but it's plausible that you could get at least several tens of Mbps over a single VCP channel using it (you should test this, if it matters to you).

If this meets your host application requirements, you could have an arbitrary number of interfaces on the MCU side, multiplexed over one VCP channel on the OS side, while still enjoying the convenience that comes from having a default OS driver available. The latter makes makes deployment and (arguably) development much easier.

If the aggregate bandwidth requirements for all your client devices are modest, you may not even require a USB HS interface (which limits your choice of parts, and is generally available only on pricier part numbers) .

 

 

For various reasons, I don't think new designs should pick the old STM32F103 - even if it could do the job.