I am designing an embedded system to run 7/24/365, so it should be robust. The point now is that for a accelerating the design I am thinking going for an USB-rs232 converter that can handle up to 625Kbps.
I would like to know if the USB-rs232 converter solution is a good one, since no human handling will take place on this system, so there will be no one to insert or remove USB related things from this remote system.
Another point is that this system, will be inside a switching DC/DC power supply.
By the way, we are using: Congatec QA (QA7) Ubuntu Lucid (linux kernel 2.6.32-38)
Thank you in advance if any one can help out to evaluate this problem.
There's a potential problem with nondetermisitic peripheral polling that (I think) USB inherited from PCI. USB peripherals may not be assigned the same /dev entries from one boot to the next.
While I can't explain why I have never seen a USB application be truly reliable - for some reason every now and again things need to be unplugged or power cycled. This has been the case with FTDI chips talking to PCs, pretty much every USB debugging tool I've ever owned, printers, mice, my home weather station talking to a PC running some kind of Ubuntu (forgotten which) etc etc.
I would be very cautious - why not use Ethernet (quick look found no rs232 support on the QA board). Can handle your data rate easily and is usually much more reliable.
625 kb/s is a strange speed, how many converters support this speed ? There are plenty at 115k2, 230k4 and some at 460k8.
Anyway, remaining within the RS-232 specification with +/-5 V swing (minimum) and 30 V/us (max) slew rate might also be a bit problematic at those speeds :-).
At these parameters the driver power consumption is going to be huge with high capacitive loading (long unmatched lines).
RS-422/485 has a smaller voltage swing and the impedance levels are much closer to the 100-120 ohm twisted pair line, thus the system works as an transmission line rather than a voltage driven high stray capacitance line (RS-232).
With external ethernet/serial converter, you also get "free" galvanic isolation, which helps a lot, if the devices are powered from different feeders.
I have been working with USB on an industrial product, and I have found USB to be highly unsuited for the task. On paper, it seems that USB is an ideal way to move on from RS232 connections. It's cheap and universal, what is not to like ?
In practice, USB is very susceptible to the typical noise you get inside industrial boxes, and it is very hard to filter effectively. In addition, after a certain number of bad packets, the protocol gives up, and the device becomes unusable without manual intervention to recover it. Neither the application nor device appear to have any way to recover after the failure. I guess there might be some non-standard tricks, but the guts of the interface are buried in device drivers or chipset on the application side. Creating a non-standard device behaviour may be OK if you have a bespoke host application, but the U in USB is supposed to stand for Universal. Cynics refer to it as the Unusable Serial Bus. ;)
People are often disappointed with the actual throughput of USB CDC devices. There are ways to get better throughput, but then you start to lose compatibility again. Writing and supporting device drivers for every version of Windows plus Unix is not very appealing.
For this and all the reasons mentioned, I think ethernet is probably a much better choice for industrial grade applications.
Those "standard" speeds are typically multiples of 2 and hence a single crystal at say 16 times the highest bit rate is used. To generate a lower speed, simply insert a number of divide by 2 frequency dividers between the oscillator and the UART.
To generate "non-standard" bit rates, you at least would have to use a programmable divide by N integer divider and hope that Fcrystal/N will fall within 1-2 % of the desired bit rate. Of course, this is quite unlikely for high bit rates, in which N is quite small.
To get closer to a desired frequency, some fractional (dual modulus) approaches or PLLs would have to be used. Do these USB to serial converters contain dual modulo or PLL clock generators ?
This is fine for an embedded processor where you have direct control of the baud rate registers.
On PCs, Windozes or Linux, you do not have access to the baud rate registers.
Standard terminal programs have a list of baud rates to select from.
As you say, multiples of 2.
Some PC programming languages have the ability to get just about any strange baud rate you want, but most people do not know this.
Just like the term "RS-232", the CDC profile needs a baud rate to init the USB "serial port". But the truth is USB knows no baud rate, its only at the hardware serial port of the USB peripheral chip that this number is actually used.
While the Win32 API provides a standard set of values for the baud rate (CBR_1200, CBR_9600, etc.), it's just a 32 bit field in the DCB, and you can set a specific baud rate other than the ones with standard definitions. The actual interpretation is left to the device driver.
But the standard CBR values are not really powers of two in any sense. Much original hardware used a divider that divided a clock (1.843MHz) by some multiple of 16*. So the original serial ports could be programmed for 115,200 baud by setting the divisor to 1. You'd get
57600 with a divisor of two, but rates like 9600 or 19,200 required non-power of two divisors (12 or 6). Nor did 110 ever work out quite right (but close enough of async serial communications). And Windows supplies "standard" values of CBR_128000 and CBR_256000, which don't fit the pattern at all.
Of course many applications that can drive a serial port only present a fixed set of choices. Often those lists are slightly odd - Windows's Hyperterminal, for example, included 230,400 and 460,800, which don't have standard CBR_ definitions, as choices, but not the
128,000 or 256,000 values. Also many device driver only implement the standard values, even if the hardware they're supporting can handle other values.
*The most common async receiver technique sampled the signal 16 times per bit - and while other techniques were occasionally used, the 16 times sampling was used on dozens, if not hundreds of UART designs, including the 8250 and its successors using in hundreds of millions of PCs.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.