fleemy 
Which USB-RS232 bridge would you guy’s recommend, those from FTDI or the ones from Silab? I am asking as I need to make a decision for the PCB board layout.
I know most people are using FTDI’s chips but what is the reason for it? Is it for the drivers on the pc side, or is it pure hardware related or something else?
Thanks.
Both Fleemy.
Hardware is powerfull and flexible, and SW for PC-side is good and complete (as far as I can see/say)
OTOH, I haven't used Silab yet, so my judgement is poor ...
Nard
They are called Rosa, Sylvia, Tricia, and Ulyana. You can find them https://www.linuxmint.com/
Dragon broken ? http://aplomb.nl/TechStuff/Dragon/Dragon.html for how-to-fix tips
microcarl 
I use the FTDI devices because that is the first USB-->TTL converter that I used. It worked perfectly the very first time I used it in a design, and it's worked every time. It's easy to use, it's reliable, and it has worked for everything that I have tried.
I can't speak for Silabs as, I've never used that device...
peter_smith Another vote for FTDI.
I alway used FTDI chips when I needed USB communication. Very easy (even easyer with new FTDI devices), as a lot of things are integrated in the IC.
For AVR it is simple Parallel or UART communication. Both are very easy.
On PC side you will have all stuff you need to make your program in any language. There are dlls, or you can use the device as a real COM port.
I also have never used Silab's USB ICs, but FTDI is used by lot of people and it is proven to work very well. Also proved that the work is easy with it. So I do not see any reason to experiment with Silab, only if you have some special needs that is only available in those ICs.
Peter
I switched from SiLabs to FTDI when the FT232R part came out because it required fewer external components than the SiLabs part. SiLabs has since then released a similar low component part, but by then I was committed to the FTDI. I've got some introductory materials on my website if you want to get an idea of how to use the FTDI part.
Smiley
microcarl I also think that FTDI has made some good improvements to the Virtual Communications Port (VCP) drivers between the time when Microsoft released Windows XP SP2 and the time when the TF232R was released. It use to be that while Windows was processing background tasks, the VCP would stall. Then when Windows released the system, the VCP would go like a bat out of hell. On the rare occasion, if the Queue filled, a character or two might get lost.
I recently updated the FTDI drivers on all of my machines and, I'm not seeing any stalling of the data transfers anymore during the execution of the Windows background tasks. I have to believe it was FTDI that made the improvement, as it seems that Microsoft couldn't have cared less.
... as it seems that Microsoft couldn't have cared less.
This is an understatement. They threw together their serialPort class which has some serious bugs that you have to learn about the hard way to work around. I've implemented a working C# terminal based on their serialPort class, but had I known how bad that class is at the beginning, I would never have wasted the time on it since I already had some working C++ code that I could have encapsulated and used. In several places in their documentation they mention their example code that follows, only thing, the example code doesn't follow and I suspect they couldn't get it working properly and just deleted it.
Two examples are: One, the function to return the names of the devices connected the COM port doesn't work since it simply reads the data in the register which can and does get trashed. I scan for the actual devices. And, two is that the function that reports the number of bytes that have been read lies and is never correct. I count the bytes myself.
There are other such stupidities.
Since the serial port is like microscopic part of their profit stream I think they just let it slide.
Smiley
fleemy Hi, first of all, thanks for the responses.
@Smiley, it’s good to know where the culprits are when using the serialPort class, I might need it some time. I also read in an old topic what language is best to use to drive USB and VCP ports, are you still convinced with C sharp?
On topic,
I’ve had some little experience with the Silab’s USB chip on a chip45 module that a bought some time ago. Both PC side (tried only XP) and hardware side worked fine for me, the only problem I had with the module, was that the hardware handshaking lines where not routed and I needed them (DTR and DCD, which I discovered, is rarely used this days).
What I am trying to do is this; I have the USB chip on one side (PC side), connected to a level shifter on the other side (device side), and the AVR in the middle (display side).
When nothing is connected on the USB port, the AVR UART is connected to the RS232 level shifter to display the streamed data from the device, this is the first scenario.
When the USB port is connected to the PC, I want to be able to do the following things; second scenario, connect the USB chip directly to the RS232 level shifter to connect the device directly with the PC. Third and last scenario, be able to reflash the AVR firmware with a bootloader via the USB port.
It will be the AVR (Display) that will decide which connection to make.
I think it should be doable, but will I need a latch (or switch) to select the TTL level lines TXD, RXD, DTR and DCD, between the USB chip, AVR and level shifter. Or is it enough to simply disable (high z) the USB chip in the first case, disable the AVR UART port pins in the in the second case, and disable the level shifter in the last case?
I recently tried it with the AT90USBKey to have it all in one chip (except for the level shifter), it does work (albeit slow, but that’s only at 8MHz) the USB part alone gives much overhead of course (and I am not experienced enough for that at this moment) and finally I discovered that the CDC driver does not really work on a Vista PC.
I think I’ll go the USB + AVR chip route, is it possible to do what I’ve explained above?
microcarl I'm a bit confused as to why you even need the RS232 level converter.
The FT232BM or FT232R connect directly to the TTL levels of the AVR USART.
So it would be:
PC <---USB---> FT232R <--- TTL ---> AVR <---+---> Boot-loader Code
|
|
+---> Target Code
If there is a boot-loader in the AVR, you'd need nothing else, with the exception of possibly an I/O pin to tell the AVR to enter the boot-loader during initialization. I think the boot-loader might even be able to be entered from the main FLASH area by a command via the USB channel.
fleemy Carl, the 'device' I am talking about is connected via a RS232 port only. What I try to do is to use the display for two things, first, which is the main application, display the data streamed from the 'device', two use the display (which has the USB-UART Bridge chip on board) as a simple USB-RS232 convertor. But also be able to upgrade the firmware for the display via USB.
The only thing I could not test so far is the USB-RS232 convertor, connected from PC directly to the device, as the hardware handshaking lines are not routed on the chip45 module (AVR ATmega128 + CP2102 USB-UART Bridge).
That's why I want to make a PCB using the same components, but with the hardware handshaking lines routed to the RS232 level shifter(MAX3232 2-input's, 2-output's).
peter_smith The only thing I could not test so far is the USB-RS232 convertor, connected from PC directly to the device, as the hardware handshaking lines are not routed on the chip45 module (AVR ATmega128 + CP2102 USB-UART Bridge).
That's why I want to make a PCB using the same components, but with the hardware handshaking lines routed to the RS232 level shifter(MAX3232 2-input's, 2-output's).
Peter