The USB connection between the host and the USB-to-Serial chip, its bandwidth, negotiated speed etc. does not matter for Klipper
This USB connection is transparent to Klipper and the actual bandwidth is controlled by Klipper and the chosen “Serial” communication interface settings during make menuconfig
It is basiclly behaving as if the chip was not there and it is a “real” serial connection
Since the MCUs usually have native USB connection capabilities, why do some manufacturers choose to have such an adapter chip in between? What are the advantages?
I’ve been watching this conversation and I’m not sure it’s heading in a productive direction.
I did quite a bit of work with USB to Serial chips about twelve years ago and they’re pretty finnicky things to get working right. Arduino did things right by putting the chips on the Arduino board so the connection is largely trouble/configuration free for the user and the Arduino serial connection is pretty tolerant of delays in the line.
I don’t think any of these assumptions are correct - Kevin/Arksine can correct me on the details but host USB communications going through a USB to Serial chip is not the same to the MCU as a direct serial connection. When there is a USB controller built into the MCU, there is generally a certain amount of handshaking and protocol communications involved even when just the Communications Device Class (CDC, which is typically used for USB to Serial Chips) is used and it gets more complex with the USB to CAN bridge.
The handshaking and protocol code means that data bytes are not sent immediately and often the adapter and the driver will wait for an entire packet of data to be ready to send. Reducing the packet payload to one byte is possible but there’s a lot of overhead to deal with.
A large number of MCUs have USB controllers built in but I would not describe them as “usually” have them built in. I think you’re looking at the devices typically used for 3D printers and that, in no way, is representative of “MCUs” at large. If you look at the “STM32” series of devices, there are 21 families with a wide variety of processor cores and IO features designed for a wide variety of different applications with maybe a third of them having USB built in:
I don’t think that considering a USB to Serial chip is a viable solution for Klipper based 3D printers. Maybe somebody’s looking at their main controller board that’s worked well for years and thinking that it’s only $20 for a USB to Serial adapter but it’s (potentially) adding another layer of complexity to Klipper and (definitely) increasing the support workload.
The best solution, all around, is for the user to get a new main controller board (which for something like a BTT Pico is about the same cost as a USB to Serial adapter) and connect things via USB.
I’m not sure what your answer is adding or how it relates to my questions.
Question 1:
Is a USB-to-Serial Bridge “transparent” to Klipper, i.e. it acts as if it was not there? The settings in make menuconfig would indicate so.
Question 2:
Why do manufacturers choose to use such a bridge chip, although the MCU has a native USB interface. E.g. the Creality 4.2.2 board uses a STM32f103XE MCU, which according to its data-sheet has a native USB interface and nevertheless Creality is using such an interface bridge.
I was just wondering why.
I suspect the answer is “mostly”, but Kevin or Arksine will have to answer definitively. As I pointed out before, you do not get a deterministic serial stream from a USB to Serial device and I suspect that it will work most of the time but I expect there will be problems that will be a bitch to run down and probably close to impossible to fix completely.
The basic reason is that the built in USB chip does not do the job required. “USB” is not an all encompassing term. There are different speeds and protocols (“Classes” in USB parlance) that have different hardware and software requirements. Handling video (such as from a camera) requires a lot more resources than simple 9,600 bps communications (like in the Arduino).
How USB is implemented is dependent on application requirements, cost constraints, part and software availability. When I was at RIM, I worked on two products which used MCUs that had built in “Full Speed” (3Mbps) USB Drivers but “High Speed” (480Mbps) USB was required.
There is overhead to sending USB packets, but there is also significantly more capacity. For what it is worth, everything else being equal, I’d prefer using a native USB connection (select “USB” in “make menuconfig”) over a serial connection. In the context of Klipper, USB will have lower latency, lower overall system load, and dramatically higher available bandwidth. (See the bandwidth tests at Benchmarks - Klipper documentation for some comparisons.)
I understand some people have various reasons to prefer serial connections (eg, frees a USB port, is easier to wire, seems to reduce EMI on a particular machine, etc.). So, if serial is working better than that’s fine. But, if someone wants my opinion on the general case, I’d personally recommend native USB.
If Klipper is compiled for “Serial” (aka UART) in “make menuconfig” then the micro-controller is using a UART connection. The micro-controller is not using USB and the micro-controller software is unaware that communications to/from it also transits via USB along the way.
The Klipper host software also doesn’t care if a micro-controller it is communicating with is actually transiting via USB (as opposed to some SBC boards that allow one to communicate using UART via GPIO pins). So, the Klipper host software is unaware (and doesn’t care) if the UART connection is direct or involves a 3rd party USB-to-serial converter.
I’m not aware of any compelling reason. I’d guess “inertia” of the particular manufacturer (that is, their engineers got used to including them).