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.
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.
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
... snip ...
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]:
Try the download section.
** Posted from http://www.teranews.com **
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 :)
I think we are both dealing with archeological memory time scales :)
Robert
** Posted from
We've had good luck with the edge port line. Expensive but works.
Were can I find the USBasync 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 wha the standard says it should be...
Jon
or even a lot less, but then there is no guarantee:
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
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. :)
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.