USB for embedded controller

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

dyrl wrote:

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

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.

On Wed, 29 Feb 2012 14:47:30 +0100
dyrl <> wrote:

> 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

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.

On 29/02/2012 13:47, dyrl wrote:
> 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

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

On Feb 29, 11:21*am, Rob Gaddi <rga...@technologyhighland.invalid>
wrote:
> On Wed, 29 Feb 2012 14:47:30 +0100
>
>
>
>
>
>
>
>
>
> dyrl <adrma...@yahoo.com.br> wrote:
> > 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
>
> 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.


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

On Thu, 1 Mar 2012 06:04:53 -0800 (PST), 1 Lucky Texan
<> 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.

On 3/1/2012 7:58 AM, wrote:
> On Thu, 1 Mar 2012 06:04:53 -0800 (PST), 1 Lucky Texan
> <> 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 )

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

On Thu, 01 Mar 2012 09:04:06 -0700, hamilton <>
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 ?

On 3/1/2012 11:48 PM, wrote:
> On Thu, 01 Mar 2012 09:04:06 -0700, hamilton<>
> 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 ?
>

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