EmbeddedRelated.com
Forums
Memfault Beyond the Launch

Please suggest USB to RS232 adapter that works 100%

Started by Unknown June 12, 2008
On Jun 13, 9:37=A0am, Tom=E1s =D3 h=C9ilidhe <t...@lavabit.com> wrote:
> I need an RS232 port for the following two reasons: > =A0 =A0 * For use with the GT ROM program for re-flashing firmware > =A0 =A0 * For programming PIC chips > > The device that Don suggested looks very attractive but I'd just like > ask one more question: > =A0 =A0 My laptop has an "express card" slot. Would I be better off > getting an RS232 adapter that goes into the express card slot, or > should I go with the EasySync USB adapter?
Absolutely. As I mentioned in the other thread, these end up providing a real hardware serial port, and behave as such. These are available as PCMCIA (AKA Cardbus/PC Card/ExpressCard) cards, as well as PCI and PCI Express cards for desktops.
James Beck wrote:
> The only BIG problem I have ever had was the fact that most of the > adapters we tested had some strange glitches occurring on the outputs at > very consistent intervals. Like 50KHz and ~100KHz on two I recall. I > presume this was some artifact introduced by the chipset and the polling > rate of the USB system/driver. In some instances these spikes were > interpreted as start bits and things didn't go well after that.
We had a situation with FTDI chips which could have been that one. We saw a zero-byte (i.e. \x00) inserted into the data stream every so often. We changed our protocol to send an escape sequence instead of a zero byte, and strip all zero-bytes on receive, and the system's been behaving well ever since. We suspect some kind of timing effect: with the USB side running on a 200MHz ARM we got a spurious byte every 1e5 bytes or so -- running a 600MHz VIA processor we see one bad byte in maybe 1e8. Mel.
In article <4852277C.2049C6BA@yahoo.com>, CBFalconer says...
> CBFalconer wrote: > > Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe wrote: > > > > ... snip ... > > > >> Can anyone suggest a USB to RS232 adapter that does its job > >> perfectly 100% of the time under Microsoft Windows, i.e. it > >> trully behaves exactly just like any other serial port? > > > > Impossible. USB is not a serial port. > > I'm hearing some objections to my statement above. My point is > that USB is a shared system, and that it queues up traffic for > transmission at intervals. You can't use the adaptor to respond to > an input event in microseconds, as you can with the original port. > What you can do is asynchronous transmission and reception, which > is most people's objective. > > For example I believe that the original X-modem protocol will fail > miserably. That requires responding to a transmission with an ACK > (or NAK) within a very short time. Z-modem will probably work.
Very short? I remember the timeouts being quite large (considerable fractions of a second to several seconds as I recall). Maybe my memory is faulty? Robert ** Posted from http://www.teranews.com **
Robert Adsett wrote:
> CBFalconer says... >
... snip ...
> >> For example I believe that the original X-modem protocol will fail >> miserably. That requires responding to a transmission with an ACK >> (or NAK) within a very short time. Z-modem will probably work. > > Very short? I remember the timeouts being quite large (considerable > fractions of a second to several seconds as I recall). Maybe my > memory is faulty?
I'm probably misremembering the problems I had with Xmodem between a micro and a mainframe. As I remember it the micro would respond with an ACK as soon as it had checked the checksum. Meanwhile the mainframe was turning the line around and listening for that ACK, which had already gone by, so it eventually assumed a NAK, and resent. To beat it I had to insert delays for the micro sending the NAK. Those delays were about the time to receive a complete record, at higher speeds, and really fouled things up. Things got worse if the mainframe was busy. It was all happening back about 30 or more years :-) -- [mail]: Chuck F (cbfalconer at maineline dot net) [page]: <http://cbfalconer.home.att.net> Try the download section. ** Posted from http://www.teranews.com **
In article <485330F9.490DA74D@yahoo.com>, CBFalconer says...
> Robert Adsett wrote: > > CBFalconer says... > > > ... snip ... > > > >> For example I believe that the original X-modem protocol will fail > >> miserably. That requires responding to a transmission with an ACK > >> (or NAK) within a very short time. Z-modem will probably work. > > > > Very short? I remember the timeouts being quite large (considerable > > fractions of a second to several seconds as I recall). Maybe my > > memory is faulty? > > I'm probably misremembering the problems I had with Xmodem between > a micro and a mainframe. As I remember it the micro would respond > with an ACK as soon as it had checked the checksum. Meanwhile the > mainframe was turning the line around and listening for that ACK, > which had already gone by, so it eventually assumed a NAK, and > resent. To beat it I had to insert delays for the micro sending > the NAK.
Ah, different problem. Not the micro expecting short times but rather expecting an effectively duplex communications line. That's part of the reason Kermit was developed. I had a similar problem with a shared line fixed at even parity and a Mini effectively fixed at none when dealing with Kermit. I did up a software patch and submitted it to the maintainers. Their archives kept complaining my solution was inefficient and I should just use no parity. Somehow there replies never got through to me so I couldn't explain that I was in no position to change the line communication protocols for every user on all the other mainframes and micros on the communications lines :)
> Those delays were about the time to receive a complete > record, at higher speeds, and really fouled things up. Things got > worse if the mainframe was busy. > > It was all happening back about 30 or more years :-)
I think we are both dealing with archeological memory time scales :) Robert ** Posted from http://www.teranews.com **
ebay can be a great source for that kind of stuff for under $10.00.

"Don McKenzie" <5V@2.5A> wrote in message 
news:6bfm95F3c7u4uU1@mid.individual.net...
> Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe wrote: >> I need an RS232 port for the following two reasons: >> * For use with the GT ROM program for re-flashing firmware >> * For programming PIC chips >> >> The device that Don suggested looks very attractive but I'd just like >> ask one more question: >> My laptop has an "express card" slot. Would I be better off >> getting an RS232 adapter that goes into the express card slot, or >> should I go with the EasySync USB adapter? > > > I just did a google, as I wasn't sure if they were readily available, but > found plenty, pricey however. $90USD for this one: > http://www.usbgear.com/computer_cable_details.cfm?sku=SS-AS1RS&cats=496&catid=1302%2C496%2C585%2C538%2C464%2C468 > > And I wouldn't know what sort of chip set these or others use. Some people > may be aware. > > Now have a look at mine: > http://www.dontronics-shop.com/easysync-premium-gold-usb-rs232-adapter-cable-10cm-cable.html > > Price includes world wide postage. It won't be the cheapest, but it works > when most of the others fail. That is why I handle them. You can speak to > the guys that designed the chipset, if you need in depth support. > > Re-read the guarantee of the ability to return the goods if it doesn't > work for your application. Our loss on postage, all you pay is return > postage. > > And re-read the customers feed back. > I think there are 18 responses from Feb 2002, to Dec 2006. I simply > stopped adding them. Applications that range from Garmin GPS's to Pfaff > sewing machines. I doubt if anywhere else on the web, you will find a > report such as this in the way of genuine feed back, on a USB to RS-232 > converter. Please correct me if I am wrong. > > Cheers Don... > > > > -- > Don McKenzie > > Site Map: http://www.dontronics.com/sitemap > E-Mail Contact Page: http://www.dontronics.com/email > > Intelligent 2.83" AMOLED with touch screen for micros: > http://www.dontronics-shop.com/product.php?productid=16699
We've had good luck with the edge port line. Expensive but works.

Were can I find the USB<->async protocol?

Our measurements show 1~2ms to get from pyserial to tx out the edgeport,
and 2~3ms to get from edgeport rx to pyserial. I just wanted to know what
the standard says it should be...

Jon


Robert Davidson wrote:

> ebay can be a great source for that kind of stuff for under $10.00.
or even a lot less, but then there is no guarantee: http://www.dealextreme.com/products.dx/category.312~r.58384759 Cheers Don... -- Don McKenzie Site Map: http://www.dontronics.com/sitemap E-Mail Contact Page: http://www.dontronics.com/email Xbee Wireless Modules, and low cost Interface Boards. http://www.dontronics-shop.com/xbee-boards.html
>Meindert Sprang wrote: >> "CBFalconer" <cbfalconer@yahoo.com> wrote in message >> news:4852277C.2049C6BA@yahoo.com... >>> I'm hearing some objections to my statement above. My point is >>> that USB is a shared system, and that it queues up traffic for >>> transmission at intervals. You can't use the adaptor to respond to >>> an input event in microseconds, as you can with the original port. >>> What you can do is asynchronous transmission and reception, which >>> is most people's objective. >>> >>> For example I believe that the original X-modem protocol will fail >>> miserably. That requires responding to a transmission with an ACK >>> (or NAK) within a very short time. Z-modem will probably work. >> >> I use X-modem regularly over an FTDI chip and it has never failed. >> > >It will depend on the level of sharing. If you have an FTDI device >plugged directly into a root port on your PC, then it will get the full >12 Mbs for full speed USB. Latency will then normally be of the order >of a millisecond or two, since that's the polling rate of USB (at least,
>for 12 Mbs USB - I don't know if it is faster for 480 Mbs USB). > >If you share the same root port via a USB hub which is also used for a >USB memory stick and transfer large files at the same time, you'll see >far more latency and throughput issues as the bandwidth is shared. How >much that may affect the serial protocol used depends entirely on its >timing requirements. > >Even at best, with a direct connection to a root port, USB works with >timing in the range of a few milliseconds. For most uses, it works fine
>- but as Chuck says it is not going to be 100% identical to a direct >serial link. >
USB is packet based, I have used RTS as a sub-microsecond precise pin on many occasions, this cannot be accomplished by USB. You will have a jitter. The best solution I can suggest is to buy a PCI - RS-232 card. They work really well. :)

Memfault Beyond the Launch