ฝัง
- เผยแพร่เมื่อ 23 ก.ย. 2019
- $2 for 5 PCBs Any Color jlcpcb.com Welcome to a new voltlog, today we’ll have a little chat on serial to usb converter chips, in particular I am looking at CP2103, CH340E and the well known FT232.
→Get some CH340E USB To Serial Converters
Aliexpress voltlog.com/y/xt24b
Ebay voltlog.com/y/1zuq6
Banggood voltlog.com/y/vt2dy
Amazon voltlog.com/y/fgy2h
→CP2103 has been replaced by the newer CP2102N
Aliexpress voltlog.com/y/vefu4
Banggood voltlog.com/y/mz3en
Amazon voltlog.com/y/jl6fw
Ebay voltlog.com/y/fvimx
→Get some FT232RL USB To Serial Converters
Aliexpress voltlog.com/y/5qrck
Ebay voltlog.com/y/rzc1d
Banggood voltlog.com/y/ucsgd
Amazon voltlog.com/y/unok7
→Support the channel via Patreon, Paypal or Bitcoin
www.voltlog.com/donations
→Blog Post
www.voltlog.com/
#VoltLog #USBtoSerial - วิทยาศาสตร์และเทคโนโลยี
These tests are testing the driver software, not the chipset. Perhaps it would be more appropriate to test with degraded signals eg by inserting additional inductance into the line to simulate a longer signal path. The chip itself has probably only a handful of bytes of buffer onboard so sending large blocks of data does not work without some type of flow control. Look also at bit error rates, implement some flow control and then send large volumes of data but checking the received data for bit errors.
Yup pretty much the feeling I had, I was looking at how the driver was performing and not the chip itself. I would have to write some test scripts to send, receive and compare data over longer periods of time and with flow control like you suggested, I'm just not sure it's worth it because that would be a whole project in itself. So far I haven't noticed any bad behavior from the CH340E so maybe that's enough info to start using it in my projects.
I prefer to avoid FTDI and Prolific due to the shit they pulled with their drivers.
FTDI decided it was a good idea to brick counterfeit chips if you used them with the windows driver.
Prolific dropped support for their older chips because they couldn't detect if they were genuine or not.
More reasons to use the CH340E 😁
I haven't had any issues with the CH340E and Ubuntu Linux.
Thanks for the upload.
-Jake
I like to use the CH340 chips, but never at those speeds 😄
Normally just at 115200, great stuff.
Like this video, thank you.
It's true, we mostly need them to work at 115k baud
Suggest do more tests on the electrical characteristics side, like: voltage level tolerance, reverse polarity protection, how much current it can sink or source on signal lines, performance under stress and high temperatures, immunity to electromagnetic interference, ESD tolerance... etc. And all of that without a PC (e.g. with a microcontroller interfacing and oscilloscope). Besides that, great content and appreciated efforts.
Running the suggested measurements would provide solid comparison data between these adapters but that would be a whole project in itself and I'm not sure I'm willing to go that far and spend that much time and resources on this. The CH340E seems to be working, I haven't noticed any bad behavior so I will be using the CH340 in future projects unless I noticed something wrong on the way in which case I will be reporting here on the channel.
I have seen some prolific chips passed off as chg340 and they cannot do 921600 etc.
Yes, I noticed that too. On some of my cheap ESP8266 modules the max upload speed is 265k baud while other work fine with the max speed of 921600 baud.
I wonder what has happened to that company. Prolific used to make quite good stuff back in the day.
While the idea of having standard procedure to test devices is quite interesting, as you have discovered already, there's too many variables to make this kind of test a reliable benchmark.
Windows does have an input and output buffer for serial communication (The default size, at least judging from the .NET API documentation, is 4096 bytes) and that can be increased by the application (In this case RealTerm). Devices also implement their own I/O buffers to deal with data that accumulates while it's not being read by a program. It's also quite likely that RealTerm has its own buffer as well. On top of that, there could be a delay between the "repeats" of RealTerm that may leave enough time for the buffers to be partially emptied sometimes, but not always.
With all that considered the amount of bytes you can transfer in one go will most definitely fluctuate, depending on the capacity of each buffer and timing at which they are filled/emptied.
Now, what happens if buffers are full? Well, that's also an issue, and the behavior will depend at least partially on the application. Does the application wait until the buffer has some space to send the rest? Does it timeout if it cannot send after a while? Does it discard the data? etc. This normally accounts for any missing data that did not make it past the first stream of bytes sent.
Whatever the case, I'm pretty sure these devices have a respectable serial buffer. At least "respectable" compared to other implementations of USART interfaces. Some old PIC devices (like the 16F628P) have a serial buffer of only 2 bytes.
Yup, everyone seems to agree here in the comments I was mostly measuring USB/OS/Driver performance in this test and not the actual usb serial chip performance. I would need to invest a lot more time and resources to properly test this chip and I'm not sure it's worth it. So far I haven't noticed any bad behavior from the CH340E so maybe that's enough info to start using it in my projects.
Which converter chip have better driver support for Windows 10? My existing converter with the older PL2302 chipset is no longer supported.
asgard168 I still using PL2303 at win8.1 or 10. You gotta to install any old 3.3.... driver version of Prolific. The actual 3.8 version will ask you to by an new adapter:)
CH340E, FT232, CP2102-2103 install automatically on win10. I have no experience with prolific..
Thanks guys for replying. Agreed with Night, I probably buy a new converter since they're inexpensive and save myself the trouble/time with the damn Prolific driver.
Two of the models seem to output 5V on the TX port, and the other one 3.3V.
Is it something you chose ?
I would not be surprised if on some cheap adapters the jumper/switch will only change the voltage on the VCC pin but the TX pin will still see 5V when you asked for 3.3V.
this varies a lot by model and as you hinted some of them just change the voltage on VCC pin.
Helpful information. I like it.👍
I would suggest doing a long overnight test sending data in a somewhat slower pace, e.g. 115200 baud which is a very common rate in real world devices. It would be nice to see that the devices run without issues overnight with data trickling through at a steady pace. This is a common use case for data logging applications. You could write some code on the PC to check that all received data is correct and have an Arduino transmitting the data continuously.
Linux is actually better at serial communication than windows, In linux I can go way faster than windows submitting data. Should try a RPI.
Doh. That's because it's integrated INTO THE PROCESSOR. :P Built-in sbc-uarts are in another league. Not comparable :)
@@Chriva I actually mean using CDC drivers, do not use the built in one.
while your designing a USB to serial adapter will it be possible to add a level shifter and also have the provision for USB to RS232
The usb to serial adapter I'm designing based on the CH340E has a switch for selecting 3.3V/5V operation. It will not have USB to RS232 conversion as that can be done with a separate module and I never really need it.
@@voltlog all it needs is a charge pump chip and the actual connector so why not add traces and don't populate it
@@xbipins because I don't need it.
All my USB to serial converters are CP2102. I never had a problem with them, neither on windows nor Linux (can't say the same about FTDIs or prolifics). I've ten or fifteen of them, because the modules are so cheap and small, that they just stay connected to my half finished projects, in case I want to continue them ;) .
What I like most about the CP2102 is that there is a software by the manufacturer Silabs, which allows you to program custom baud rates into the chip (just connect it, start the software and set your baud rate; it's stored in the controller). This is very handy when you have a device with an odd baudrate that isn't one of the typical ones. It also allows you to get a 2Mbps serial to an atmega328 (also it's hard enough to get the data fast enough into the serial registers), or better micros like STM32 that can actually make use of that quite high speed serial with DMA.
Yeah I would expect the CP2102 to have better support from the manufacturer but ultimately what I wanted to find out is if I can reliably use the CH340E in future projects. I don't think I've proved that with solid data because my measurement methods we're not optimal but I didn't notice any bad behavior either, for me that's enough to continue using the CH340E whenever the cost saving is needed.
No flow control? Without hardware flow control (RTS/CTS), I'm not surprised that there were buffer overflow issues. Also, putting stuff on the screen has always slowed things down for me. Perhaps you can "cat /dev/zero > /dev/ttyS0" or something like that, or use a Python script.
I agree, a script that will send, receive and compare data with flow control would be the better way to test this
Hi, there is a new Chip in the CH3xx Series of USB-UART Bridges, the CH330N its a SOIC8 Package with again Internal Clock, just with 2 less Lines , Cheers, Konstantin
Interesting chip, thanks for sharing!
what do you do when you don't get anything returned? I only see what I typed
Why there's that orange tape on those USB connectors?
I've seen it on raspberry pis HDMI ports, I believe it's insulating, but I'm not sure why it's there.
I always thought it was there to allow those parts to be used in a vacuum pick-and-place tool, because underneath that tape the connectors have holes in their shells that would render a vacuum pick-up tool useless. I definitely don't know for sure, though :)
You see similar things on strips of pin headers: small bits of plastic that sit on top of the pins, supplied that way from the factory, so they can be positioned by machines. Those bits of plastic are often removed before the finished product is sold to us, but you do sometimes see them on delivered boards (dev boards and such, rather than consumer electronics).
I think the tape is there to help the pick and place machine.
Now that I've woken up properly, here's a more definitive answer that's backed up by evidence! :D
Yes, the tape is for pick-and-place machines (it's likely Kapton tape, or a generic polyimide clone, for its heat resistance).
Check out the product listing for surface mount mini USB sockets on the Toby Electronics website, here: www.toby.co.uk/signal-to-board-connectors/usb-connectors/musb-valcon-mini-usb-type-b-surface-mount-socket/
The product details include this line: “With Pick and Place pad as standard (Yellow tape on top)”
And regarding pin headers, here's the page for a Samtec surface mount pin header: www.toby.co.uk/board-to-board-pcb-connectors/254mm-headers/tsm-samtec-254mm-dual-row-vertical-surface-mount-header-813mm-post-height-02/
The product page itself doesn't mention the pick-and-place pad, but the datasheet does: www.toby.co.uk/uploads/publications/2071.pdf mentions options "-K" for a “Polyimide Film Pick & Place Pad”, or "-P" for a “Plastic Pick & Place Pad” :)
Thank you guys, especially @@AndrewGillard for great explanation.
There is a bit of discussion here: www.eevblog.com/forum/microcontrollers/ch340-usb-uart-speed-tests/ but not too conclusive.
Interesting thread, thanks for sharing!
Have you noticed ftdi's annoying behaviour? They SUCK when it comes to smaller transfers in rapid intervals. For normal stuff it doesn't matter but with event driven stuff you get an additional delay of at least on ms before it empties the buffer
Even through not highly relevant, in the tests I performed the CH340E the FT232 seemed inferior to the CH340E. Whether that's driver related stuff or hardware related stuff I don't know.
Timeout can be configured in Windows in Device manager properties. In Linux there is some console command.
@@hubmartin and what is the minimum timeout? One ms. Did you even read my post :p
@@voltlog I think the delay is just how the hardware works. Granted ft232 is quite old by now so I'm perhaps being a tad harsh on it. Never had one act up on me, I just find them.. "less than optimal" for certain types of transfers when it comes to speed :P
@@Chriva I did. My brain overlooked "on" and evalueted "ms" as milliseconds :) If rapid intervals means under 1ms so there is nothing more to do.
Thanks ! Is good to know all that, even when I don't go to use ever FTxxx, just because the sh*tty company they are, I don't like their tactics. Thanks for sharing !