EEVblog Electronics Community Forum
General => General Technical Chat => Topic started by: vlad777 on November 04, 2019, 02:58:45 am
-
I want to program NXP uC LPC810M021FN8FP using FlashMagic software.
Now I need to chose the COM to TTL UART converter board.
Those boards are based on chips FT232RL CH340G CP2102 and others.
FT232RL is FTDI and has good support for windows drivers. (but we had that bricking fiasco)
CH340G is the Chinese one.
CP2102 is Silicon Labs. Good win driver support.
It is also important that they work with 5V and 3.3V UART signaling.
Also it would be good if I could use it in other projects as well.
So which should I choose, what else to look for?
Many thanks.
https://www.youtube.com/watch?v=eU66as4Bbds (https://www.youtube.com/watch?v=eU66as4Bbds)
-
The CP2102 is a 3.3V device, and its Tx, DTR, and RTS outputs are 3.3V. I think in most cases 3.3V would be read as high in a 5V system, so they probably would work, but technically not a match. I don't know what happens when you apply 5V from the processor to the Rx pin of the CP2102. So my feeling is that this would be great for a 3.3V system such as your NXP, but maybe not for 5V.
My memory is that the FT232 modules on Ebay, etc., have a 3.3V/5V jumper that switches both the Vcc output and the I/O pins between those two levels. If that's correct, that would be a good way to go. I don't think we will have a repeat of the FTDI driver fiasco.
I think the CH340 works the same as the FT232. Most Arduino clones use the CH chips, so I think they are fine. By the way, the CH340G requires a crystal. But they make another version that doesn't - CH340C maybe.
-
FT232 supports both I/O voltages and has a reasonable selection of baud rates up to 3M.
PL2303 is 3.3V which will be interpreted as high by most 5V systems and has 5V tolerant inputs and supports just about any bitrate up to 6M.
These are IMO the best USB UARTs from the technical standpoints, but if you want to buy those cheap modules found on auction sites and hobbyist shops and use them on Windows you are running a risk of getting fake chips which may be unsupported by future version of vendor drivers. Not a problem on Linux.
So perhaps the CH340 is not a bad choice for Windows. There are even CH340 dongles which support SPI mode 0 and I2C in addition to UART, although some special software is required to use that functionality. IIRC the CH340 can be switched to either 3.3V or 5V and some boards provide a jumper.
-
The CP2103 has a seperate IO voltage supply and works from 5V down to 1.8V. I have made a USB to UART converter box which has a switch to put it in programming mode (basically connect the control lines for reset and getting into the bootloader).
-
I chose the CP2102 because it's built in 3.3V reg can officially be used to also power other 3.3V devices (within reason).
It meant i didn't need a separate 3.3V reg on my PCB.
EDIT: Looks like the FT232RL now says you can do that too, i don't think it did when i picked the CP2102.
-
I use a CP2102
(https://www.eevblog.com/forum/index.php?action=dlattach;topic=47932.0;attach=851168;image)
Used to change the bootloader of a router, it supports 3.3V and 5V.
https://www.waveshare.com/product/CP2102-USB-UART-Board-micro.htm (https://www.waveshare.com/product/CP2102-USB-UART-Board-micro.htm)
-
If time permits, I'd consider WCH CH552 or Silabs EFM8UB, both are programmable MCU with USB stack and peripheral, and you can implement your own serial port with it plus some custom IO functions, so they also serve as board controller if you are designing a more complex board.
I'm currently working on a design with CH552E, and I have to say I'm impressed by its feature set and price.
MCS-51... isn't that an 8 bitter of the 80's? (it's a rhetorical question)
I like the CP2102. The CH340 resets for unknown reasons my esp32s every time I do a screen.
-
Some drivers assert RTS/DTR signal when being opened and closed. That, if not filtered properly, can trigger ESP32 reset (since RTS and DTR are used to set boot mode and reset).
Many ESP32 boards have a logic circuit to inhibit simultaneous RTS/DTR to prevent this from happening, but some don't.
Yes, that's exactly what's happening!
-
The CH340 resets for unknown reasons my esp32s every time I do a screen.
ESP32 uses DTR and RTS pins to trigger an automatic reset to enter the bootloader:
https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection#automatic-bootloader
Maybe tweaking the flow control settings might help? https://stackoverflow.com/questions/41266001/screen-dev-ttyusb0-with-different-options-such-as-databit-parity-etc
-
The CH340 resets for unknown reasons my esp32s every time I do a screen.
ESP32 uses DTR and RTS pins to trigger an automatic reset to enter the bootloader:
https://github.com/espressif/esptool/wiki/ESP32-Boot-Mode-Selection#automatic-bootloader
Maybe tweaking the flow control settings might help? https://stackoverflow.com/questions/41266001/screen-dev-ttyusb0-with-different-options-such-as-databit-parity-etc
Thanks! I don't know, but stty -a and -e return the same for both:
10-YOSEMITE:~ admin$ stty -e -f /dev/cu.wchusbserialfd130
speed 9600 baud; 0 rows; 0 columns;
lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
-echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
-nokerninfo -extproc
iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -iutf8
-ignbrk -brkint -inpck -ignpar -parmrk
oflags: -opost -onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
discard dsusp eof eol eol2 erase intr kill lnext
^O ^Y ^D <undef> <undef> ^? ^C ^U ^V
min quit reprint start status stop susp time werase
1 ^\ ^R ^Q ^T ^S ^Z 0 ^W
10-YOSEMITE:~ admin$ stty -e -f /dev/cu.SLAB_USBtoUART
speed 9600 baud; 0 rows; 0 columns;
lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
-echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
-nokerninfo -extproc
iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -iutf8
-ignbrk -brkint -inpck -ignpar -parmrk
oflags: -opost -onlcr -oxtabs -onocr -onlret
cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts -dsrflow
-dtrflow -mdmbuf
discard dsusp eof eol eol2 erase intr kill lnext
^O ^Y ^D <undef> <undef> ^? ^C ^U ^V
min quit reprint start status stop susp time werase
1 ^\ ^R ^Q ^T ^S ^Z 0 ^W
When flashing (with esptool) both do it fine and manage to /reset and pull gpio0 to GND to enter the bootloader when needed as intended, but with a 'screen <port> 115200' the ch340 /resets (GRRR!) and the cp1202 doesn't.
-
I ended up buying FTDI.
Check out my new thread:
https://www.eevblog.com/forum/chat/programming-nxp-uc/ (https://www.eevblog.com/forum/chat/programming-nxp-uc/)
-
How about the FT231X?
- FTDI
- Cheaper and simpler than the FT232RL
- 5v and 3v3
- 300 baud to 3M baud
https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT231X.pdf (https://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT231X.pdf)