EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: VinzC on January 14, 2016, 02:18:35 pm
-
Hi all.
I'm currently designing a microcontroller-based project that relies upon a USB/serial interface – as a side note I'll definitely keep away from FTDI. I've looked up and seen there are basically two ways: either wire D+ and D- to the micro directly and use the V-USB libraries (on both PC and AVR sides) or whack in a specialized IC, such as Silabs CP120x or Cypress' CY7C64225. I understood that V-USB can eat up to 2KB of code memory on the microcontroller. Then there's the USB/serial bridge.
Both Silabs and Cypress bridges seem to support variable baud rates but I'm a bit confused as for the baud rate selection though. From what I understand there's no way (because there's no point) to select the [host side] baud rate from the microcontroller's side and it's only on the host side (i.e. the PC) that it's selected. In short the baud rate programmed in the microcontroller code has to match the baud rate selected on the host. Or vice-versa. Did I get it all right?
-
The baud rate you choose when you initiate the stream is the baudrate the usb-uart bridge will use on it's TTL side.
If you open the port in a terminal with 9600 8N1*, it will configure the uart side as such.
What is the motivation behind your opinion on ftdi?
*The very common 9600 baud, 8 data, No parity, 1 Stopbit.
-
Yes, both rates must match. This is exactly the same situation as with a 'real' serial line; the only difference is that instead of a serial cable, you have only the signal lines on your PCB between the AVR and the USB/serial chip.
-
Thank you guys. Sounds reassuring I still can read and interpret datasheet correctly ;-) .
What is the motivation behind your opinion on ftdi?
Sorry, it was me introducing the Troll so let's tip into it but slightly. Staying away from them is my way to «voice» my disapproval of their attitude – besides, you don't need to be «Genuine®©™» to be good enough when good enough is all that's needed to make it «just work». I despise that type of proprietary attitude in general (and all the fat arrogance that goes with it) of those suppliers, who spit at the hands of their customers. Beyond that I appreciate still having choices. Had FTDI been the only one on the market, we'd feel rather stuck and screwed but fortunately choices (https://www.eevblog.com/forum/reviews/alternatives-to-ftdi-usb-to-uart-converter/msg540422/#msg540422) exist.
-
You could also have had serious supply or errata with them. But you just disagree with their attitude. Which is your choice to make.
Note that silicon labs also have an hid-uart device. And other bridges, might be worth a look.
-
Note that silicon labs also have an hid-uart device. And other bridges, might be worth a look.
:-+ Will keep that in mind. Thanks.
-
In general you must match baud rates manually. "Auto-baud" is possible but that's another trick for after you've mastered the basics. UART communication is usually easy and uses minimal software size and processing overhead, especially compared to USB.
Keep in mind a couple things:
The overall error in bit rate between the two devices must be less than 4%, less than 3% (at 5% error, after the 10th bit* the accumulated error is 50% of a bit duration, making errors a certainty). Your USB-UART adapter may have some error to begin with, then there is the error on your microcontroller. If you are using a crystal for timing, you will likely have fewer issues, though the frequency is usually not ideal and you often end up with ~1% error even if the baud rate generator is set up correctly. If you use an internal RC oscillator, then be very careful. If you see random data errors, scope the Tx/Rx signals and compare timing. Don't think baud rate error not a thing to worry about. I have a very expensive terminal server (ethernet to multiple serial ports) that was consistently 4% low, causing much grief. Replacing a 25 MHz oscillator with a 26 MHz one fixed that right away :D
(* 10 bits per byte are transmitted: start bit, 8 data bits, stop bit.).
The UART data signalling at TTL levels is inverted. The bus idles high (5V). The start bit is a '1' which is low (0V), data bits are inverted ('0' is 5V, '1' is 0V), and the stop bit is a '0' or 5V. Then the bus may idle at 5V for any length of time before the next start bit. The LSb is transmitted first, so when viewing the waveform on a scope or logic analyzer, the bits appear reversed to typical reading order (LSb on the left, MSb on the right) in addition to being level-inverted.
-
You could also have had serious supply or errata with them. But you just disagree with their attitude. Which is your choice to make.
FTDI USB/serial bridges are less stable than the ones from Silabs on similar boards layouts (double sided with ground pours stitched together allover). I can easely demonstrate/repeat that on my bench by switching on/off the power supply to the board.
-
Your choices for USB-to-UART bridges are:
- CP2101, CP2102, CP2104
- PL2303 (a several variants)
- Texas' TUSB3410
- CH340G
- another atmega, such as the Atmega16U2, 16U4
The TI part is the hardest one to implement, specially because it needs to be programmed to work as a USB-to-UART bridge. The 16U2 also needs to be programmed, but the firmware for it is already available from Arduino's website. all the other ones are pretty much the same: a few resistors, caps, a 12Mhz xtal, USB protection diodes, TX+ RX leds (optional), and connect TX, RX and DTR to the Arduino.
-
I was going to use Silicon Labs CP2104 (http://www.digikey.be/product-detail/en/CP2104-F03-GM/336-2008-5-ND/2486177) but then I realized how damn small that chip is — 4mm x 4mm, not even one millimeter tall! With my eyesight I expect it to be a nightmare or so... I finally opted for Microchip's MCP2221 (http://www.digikey.be/product-detail/en/MCP2221-I%2FSL/MCP2221-I%2FSL-ND/4902586) but I need to know for sure it will be recognized by Linux as well as a CDC or ACM device. (FTR I have recently used a USB relay board from Velleman, which uses a PIC directly interfaced with the USB data lines and I didn't even need a driver, so it looks promising.) Also, from the MCP2221 datasheet (http://ww1.microchip.com/downloads/en/DeviceDoc/20005292B.pdf) I'd say it is supported but can anyone confirm?
EDIT: I stumbled (http://www.thebackshed.com/forum/forum_posts.asp?TID=7818&PN=1#83791) across this README (http://ww1.microchip.com/downloads/en/DeviceDoc/MCP2200_MCP2221_CDC_Linux_Readme.txt) and it looks like the chip is indeed well supported! :-+
-
I've just ordered myself a strip of PL2303SA chips. The only USB-UART bridge I'm aware of that comes in SOIC8 format - all the others are TSSOP or some quad flatpack. This SOIC8 chip doesn't need an external oscillator - just power, ground, USB D+ and D- lines, and it gives you TX and RX. No handshaking lines though, but quite sufficient for a simple USB-attached serial port for debugging purposes.
Of course, I've only just ordered it so I haven't had chance to try it out yet. It might be lovely, it might be terrible - I'll report back when it arrives. :)
-
The original reason that these sort of chips emerged onto the market was to allow existing systems using RS232 to be easily transitioned across to USB ports with no software changes and minimal hardware changes. It's surprising that they've remained widespread for so long without everything moving to native USB-equipped microcontrollers.
The chip goes in the middle, with UART lines to the target and a driver that creates a virtual UART in the operating system. The baud rate has to be matched between the existing software on the PC and the microcontroller target hardware, but the "man in the middle" chip is ideally completely agnostic to the baud rate, which is why there's no need to configure its baud rate, that doesn't make sense, it's up to the software and the hardware on either end of the link to decide that, and to match.
-
The chip goes in the middle, with UART lines to the target and a driver that creates a virtual UART in the operating system.
You can do more tricky thing with CP2104-use bit banging an by adding four optocouplers make I2C interface with a few kV optical insulation between PC and MPU ;)
-
Four optocouplers? Be more 2016 and use one of these: Si8600 or Si8640 from Silabs.
I did that before, most useful board ever. http://jeroen3.nl/isoftdi (http://jeroen3.nl/isoftdi)
-
Four optocouplers?
Yep, This ADUM1402 Quad-Channel Digital Isolators (http://www.analog.com/media/en/technical-documentation/data-sheets/ADuM1400_1401_1402.pdf) looks good but depending on needed speed even slow TCMT4100 might be good for I2C based on CP2104 ;)