USB for embedded controller

[dyrl]

Hello,

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.

Adrian Mateu

[Mel Wilson]

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.

You fix this by getting the udev rules right.

Mel.

[Rob Gaddi]

625 kbaud is pretty fast for RS-232. Possibly RS-485 instead, or just
put an FTDI USB-UART chip on your board; then you're just at CMOS logic
levels.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.

[MK]

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.

MK

[1 Lucky Texan]

On Feb 29, 11:21 am, Rob Gaddi <rga...@technologyhighland.invalid>
wrote:

yeah, 485/422 or ethernet 'should' be more reliable/exhibit noise
rejection with a power supply nearby too.

[upsid...@downunder.com]

On Thu, 1 Mar 2012 06:04:53 -0800 (PST), 1 Lucky Texan
<1luck...@gmail.com> wrote:

>> 625 kbaud is pretty fast for RS-232.  Possibly RS-485 instead, or just
>> put an FTDI USB-UART chip on your board; then you're just at CMOS logic
>> levels.

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).

>yeah, 485/422 or ethernet 'should' be more reliable/exhibit noise
>rejection with a power supply nearby too.

With external ethernet/serial converter, you also get "free" galvanic
isolation, which helps a lot, if the devices are powered from
different feeders.

[hamilton]

On 3/1/2012 7:58 AM, upsid...@downunder.com wrote:
> On Thu, 1 Mar 2012 06:04:53 -0800 (PST), 1 Lucky Texan
> <1luck...@gmail.com> wrote:
>
>>> 625 kbaud is pretty fast for RS-232. Possibly RS-485 instead, or just
>>> put an FTDI USB-UART chip on your board; then you're just at CMOS logic
>>> levels.
>
> 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 :-).

Too many people use "RS-232" too mean async-serial.

The RS-232 spec only addresses the voltage levels presented to the
interface, not any speed.

With that said, 625Kbaud in just as valid as "standard" values.

Many of the newer USB to Serial chips can go as fast as 920Kbaud.


The biggest problem is getting windows to select a speed that is not a
"standard" speed. ( I am sure this is leftover from the modem days )

[Bob]

> 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 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. ;)

> 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.

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.

[upsid...@downunder.com]

On Thu, 01 Mar 2012 09:04:06 -0700, hamilton <hami...@nothere.com>
wrote:

>
>Too many people use "RS-232" too mean async-serial.
>
>The RS-232 spec only addresses the voltage levels presented to the
>interface, not any speed.
>
>With that said, 625Kbaud in just as valid as "standard" values.
>
>Many of the newer USB to Serial chips can go as fast as 920Kbaud.
>
>
>The biggest problem is getting windows to select a speed that is not a
>"standard" speed. ( I am sure this is leftover from the modem days )

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 ?

[hamilton]

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.

hamilton

[Robert Wessel]

On Fri, 02 Mar 2012 09:46:22 -0700, hamilton <hami...@nothere.com>
wrote:

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.