Experimental IO (including usb LPT ports) on the modern PC

[Tor]

Moosfet wrote:

Also, the auto-logout time-out in this forum needs to be greatly extended. Every time I hit submit it's like "you need to log in again" [..]

Look for a tickbox which says something like 'keep me logged in'. I don't remember it exactly, because I haven't logged in again in months.. I'm always logged in.

-Tor

[BigEd]

(I think the issue here is that the form submission times out if you take too long to compose a reply. It's always worth a quick ^A ^C to get the text into your paster buffer before submitting.)

[GARTHWILSON]

Tor wrote:

Moosfet wrote:

Also, the auto-logout time-out in this forum needs to be greatly extended. Every time I hit submit it's like "you need to log in again" [..]

Look for a tickbox which says something like 'keep me logged in'. I don't remember it exactly, because I haven't logged in again in months.. I'm always logged in.

IIRC, it's "Log me in automatically every time I visit," and then when I take too long to post, it logs me in again but says, "Your submission was invalid. Please try again," and everything I typed is still there, and merely clicking "Submit" again does the job.

Moosfet wrote:

Anyway, there are a few things that make serial ports ****. First of all, the +/- voltages are a PIT* to work with

Many line drivers have the voltage converters internal, but then require external capacitors for their charge pumps. The capacitors and the pins to connect to them take extra board space which is not at a premium for most builders here, but I always have higher plus and minus voltages on the board for other things anyway, so I use mostly the MC145406 16-pin IC which has three line drivers and three receivers, and have used the old 1488 and 1489 14-pin pair which have four line drivers and four line receivers, respectively. The higher plus and minus voltages can usually be anything from 7V to 15V, not critical, and usually not even requiring regulation.

Quote:

, but to make things worse, the voltages aren't even well-defined. I think the "official" specs are that the voltages are anywhere from 3 to 15 volts. So you end up with devices that are looking for at least +/- 10 volts since the person who designed them had a serial port that output +/- 12 volts, but the device you have only puts out +/- 3, and so the connection doesn't work. It's also just terrible in that you now need -12, +5 and +12 volts for your project, all to support some idiotic signal voltages.

The RS-232 spec says line drivers must put out at least ±5V but not more than ±15V, while line receivers must "understand" down to ±3V and work with up to ±25V without damage. Fortunately there's a wide range, so it's easy to stay within spec.

I have never had any problem with RS-232 reliability. In the decades I've been using it, I don't think it has ever misinterpreted a bit or given any errors as long as the transmitting and receiving speed and numbers of bits matched. (I've never used parity.) An advantage RS-232 has over USB is that it can go long distances, at least hundreds of feet. (The old 50-foot claimed limitation certainly does not apply to any line drivers made in the last 30 years.) If you don't need the fastest speeds (as you probably won't be using RS-232 to download pictures or videos), you probably won't have any problem at one or two thousand feet. This is one of the reasons it is still used a lot in industrial environments, on huge factory floors. Forum member BigDumbDinosaur writes,

• • The longest hard-wired TIA-232 [the newest name for RS-232] run was 272 feet, which drove a terminal at 38.4Kbps without any problem. [...] At no time did we ever experience any TIA-232 anomalies due to cable length. [...] Toward the tail end of the era where we regularly installed serial hardware (up to about 2001), runs of several hundred feet using CAT5 UTP cable were routine. I know from application experience that 115.2Kbps is readily achievable on CAT5 UTP cable over a distance of 325 feet.

If these specs aren't enough, you can go to RS-422 or -485 which are differential (balanced), and the output can come from 5V or 3V drivers since the inputs can tolerate up to 6V and you only need 200mV difference between the two wires to get a valid logic level. Here's the idea, showing transmitting $D3:



RS-422 and -485 can go both much farther and much faster. RS-422 can do 10Mbps at 40 feet, and RS-485 can do 35Mbps at 33 feet. Both can go at least 90kbps at 3/4 mile. A rule of thumb for RS-485 max speed versus cable length is that the speed in bit/s multiplied by the length in meters should not exceed 10^8. Thus a 50-meter cable should not signal faster than 2 Mbit/s.

Quote:

The other nasty thing about serial is that it is serial. This means that you either need a UART and a microcontroller to read the data, or you can use a bunch of 74LS123 to time bits and bytes to control shift and latch registers

I wasn't familiar with the '123, so I had to look it up. Thanks for the head-up! I've done that function before with other parts, but this might have been easier.

[cbscpe]

jds wrote:

I work on a Mac, ...

So do I and I also run everything in a virtual Machine and I have both the cheap Chinese USB-RS-232 5V cables (although they were USD 2 when I bought them) but later decided to go for the not so cheap original FTDI cables part-no. TTL-232R-5V. There are pros and cons

The MAC driver for the cheap cables (prolific) is horrible and can cause crashes on the MAC and you never now the name of the device as the name is built from the USB enumerating tree which may change when you re-arrange devices, the only stable names are the built-in USB ports and the USB ports on the monitor and the keyboard (but on the keyboard they don't work as they announce them selves as requiring 500mA). However in the virtual machines (Linux and Windows) they work like a charm although you must always check which device or COM port you are using.

The FTDI driver for genuine FTDI cables however is very nice on the MAC. The device name is created using the serial-number, so regardless of the USB port you plug that cable in the same cable always gets the same device name, this is very handy and so I just put labels on my cables and always now which cable is which device.

However under Windows I have a lot of programmers and USB programmer cables and some of them use FTDI chips and some of those cables use non-genuine FTDI chips, and as you mentioned, once you install the FTDI drivers the non-genuine chips stop working. But it doesn't stop here, the FTDI driver for the USB cables conflicts with the driver for the USB->ISP interface from Atmel.

At the end I use the FTDI cables under MacOSX and the cheap cables in the VMs. And as they are so easy to use all my current projects have a 5V RS-232 interface to talk to the Mac or the VMs.

Another solution I was once using are the "IO Warriors" from Code Mercenaires http://www.codemercs.com/de/io they also provide SDKs and drivers for their devices for MacOSX, Linux and Windows and it was very easy to use them and write your own program that talks to the chips via USB. At least it was at that time I used them, even I as a complete noob regarding MacOSX programming was able to write a small programm with GUI that was able to receive IR commands via a IO Warrior that had a IR receiver attached to it and also was able to send text to a LCD display attached to the IO Warrior. Depending on the model their chips include direct support for RC5, I2C, SPI, etc. and they have starter kits.

[Moosfet]

Quote:

I know from application experience that 115.2Kbps is readily achievable on CAT5 UTP cable over a distance of 325 feet.

I wouldn't expect it to be a problem at any distance on a cable with a controlled impedance, assuming the voltage drop over the length of the cable isn't an issue and it is properly terminated with the same impedance at the end. I have no idea how it ever got the "it can only go 50 feet" reputation.

USB, on the other hand, suffers from its designers choosing to require a response to a certain command to come so soon after the command is sent that the speed of light prevents the cable from being longer than about 25 feet or so as the response simply won't be able to get back in time. So using a high-quality cable with proper signal termination won't help with USB. When you see a 100 foot USB cable, it works by converting the USB protocol to something else over the length of the cable, then converting it back to USB at the other end, which is why such cables are so expensive. It's really quite annoying. I thought I'd use USB cameras as cheap security cameras, and bought a bunch of 10-ft USB extension cables. One extension cable works fine, but if I use two, the connection degrades to USB-1.1 speeds, and if I use three it stops working entirely. I even tried putting a hub at each step as a sort of repeater, but it just doesn't work.

In any event, what problems I had with both serial and parallel were certainly caused by something, and if that something were corrected then those problems wouldn't exist, but the main point I was trying to make was that, as a hobbyist trying to use this stuff for I/O with my projects, the parallel port was most difficult to use reliably despite its deceptively simple design, the serial port was OK outside of my two $5 UARTs (they both had the same problem), but the FT245R was incredibly easy as it just does what it's supposed to do with clean logic levels, high speed and high reliability, so it's the one that I have to recommend.

...though now that I think about it, it too wasn't always that easy. Initially I had a lot of problems with it. The first seemed to be caused by a flaky USB hub I was using, though I didn't discover that for the longest time. Instead I merely discovered that if I limited each write to 15 bytes or less the problem went away. After discarding that hub, I discovered I could go up to 4096, but that seemed to hit another problem, probably because Linux's USB drivers use a buffer of that size. Just now I tried disabling the limit entirely on my EEPROM programmer, and it still worked without issues. So I guess the driver problems are solved these days, but back in 2005 they were a constant bother.

Quote:

The device name is created using the serial-number, so regardless of the USB port you plug that cable in the same cable always gets the same device name, this is very handy and so I just put labels on my cables and always now which cable is which device.

That's actually the reason for the small number taped to the top of the USB connector in my photos.

In Linux the serial number similarly shows up in the names of the devices in /dev/serial/by-id/, but that wasn't always the case. Initially they were only shown in the system log, so I had some scripts that would sort through it and figure out the correct /dev/ttyUSB device. ...but that was a pain as every kernel upgrade seemed to bring a new format to the messages the scripts looked for. Eventually I learned about udev, and so I created a udev rule to name the device according to the serial number.

Just create a file named /etc/udev/rules.d/FTDI.rules and put this in it:

Code: Select all

ATTRS{idVendor}=="0403", SYMLINK+="FTDI/$attr{serial}"

This becomes very useful if you use FTDI's tool to reprogram the serial number. For the little break-out boards I put on solderless breadboard, I just name them like "Pj-104" which then shows up as /dev/FTDI/Pj-104, but for devices I put on a PCB, I name them like "c6XbT0/BlvERf" where I choose the letter/number code randomly, but the first half is a "device type" code and the second half is a "serial number" of sorts. So if I make more than one of that device, I keep the same code for the first half, but assign it a different code for the second half. So, for example, if I run the script that programs AT89S52 devices, it looks in "/dev/FTDI/c6XbT0/" to see what programming devices are attached; if there is only one, it just uses it, but if there are two, it asks me to tell it which to use.

I'd forgotten all about this, but it's really so useful that it's a reason all in itself to use an FT240X rather than a serial or parallel port.

Quote:

once you install the FTDI drivers the non-genuine chips stop working

Did they finally decide to *just* make it not work with the non-genuine chips? Last I heard they'd twice decided to make the driver brick the non-genuine chips, which of course made everyone hate them, whereas if they'd merely just made the driver refuse to work with the non-genuine chips but otherwise left them alone that would have been OK.

Quote:

But it doesn't stop here, the FTDI driver for the USB cables conflicts with the driver for the USB->ISP interface from Atmel

I assume they're using the bit-banging mode of the FTDI chips. All of the FTDI chips (the serial and the parallel ones) support a mode where you can just tell the chip via USB commands to raise or lower individual pins. It sounds quite useful as it would work much the same way that people like to use a parallel port, but the driver that implements it is incompatible with the driver that implements the virtual COM ports. So you can have serial ports, or you can have bit-banging devices, but you can't have both, which really ***** since there are enough FTDI devices around that you have to have the virtual COM driver installed, so you have no choice. If that bit-banging mode were actually usable then the FT240X would be everyone's ideal parallel port replacement, but the way things are, it's just a feature that the datasheet mentions which you can't actually use.

Quote:

"Log me in automatically every time I visit,"

Well, that seems to have worked this time, but then for all I know I just didn't spend enough time writing this post. It is kind of a strange way to say "don't automatically log me out," which probably had something to do with me not noticing it as I tend to take things literally.

[Moosfet]

Quote:

I wouldn't expect it to be a problem at any distance on a cable with a controlled impedance, assuming the voltage drop over the length of the cable isn't an issue and it is properly terminated with the same impedance at the end. I have no idea how it ever got the "it can only go 50 feet" reputation.

I just realized that this kind of sounds like I have some experience with this, so I wanted to clear up that I don't.

Where I'm coming from is that there's nothing about serial that should have a distance limit. It's like any other long-distance transmission over wire: You have to have a transmission line with a consistent impedance over the length of the cable and you have to terminate it with a resistance equal to that impedance. The only distance limit it should have is due to the quality of the cable (any changes in impedance will cause signal reflections) and the power loss over the cable, and so "serial data can only go 50 feet" is just silly.

For anyone who might not know about transmission line impedance, I'll link to this page which finally made me understand it years ago. It's probably worth reading from the beginning of the chapter, but that was the page I landed on. I had no idea what I was reading since I was looking for something else, but it seemed like an interesting thought experiment and so I kept reading and by the end was like "ooh, mind = blown!" It's one of my favorite web pages of all time just because of how excited I was to finally know why all of those coaxial T.V. cables said "75 ohms" on the side.

[BigDumbDinosaur]

BigEd wrote:

(I think the issue here is that the form submission times out if you take too long to compose a reply. It's always worth a quick ^A ^C to get the text into your paster buffer before submitting.)

I preview about every ten minutes when writing a long-winded post, which refreshes the auto-logout timer.

[BigDumbDinosaur]

Moosfet wrote:

Quote:

I know from application experience that 115.2Kbps is readily achievable on CAT5 UTP cable over a distance of 325 feet.

I wouldn't expect it to be a problem at any distance on a cable with a controlled impedance, assuming the voltage drop over the length of the cable isn't an issue and it is properly terminated with the same impedance at the end.

The highest signaling rate supported by "industrial" UARTs, such as the NXP 26C and 28L lines, is 960 Kbps, which is well below the signaling rate of 10Base-T. Line impedance is not that critical on such circuits, and in most cases, the line drivers used in TIA-422/485 work tend to push a much stronger signal than the line drivers used with Ethernet adapters.

Quote:

I have no idea how it ever got the "it can only go 50 feet" reputation.

That came from the early days when drivers were weak and everyone thought that shielded cable was necessary.

[Tor]

BigDumbDinosaur wrote:

Quote:

I have no idea how it ever got the "it can only go 50 feet" reputation.

That came from the early days when drivers were weak and everyone thought that shielded cable was necessary.

Ah yes, I remember someone connecting a very long, shielded RS232 cable from the server room of one building to another building, at the place where I first started working. He connected the shielding to ground in both ends, not a good idea at the best of times, but in this case the AC system used ground as common return, and the other building had some issues so there was a 100V AC difference between the two buildings. Nice pyrotechnics followed.

[BigDumbDinosaur]

Tor wrote:

Ah yes, I remember someone connecting a very long, shielded RS232 cable from the server room of one building to another building, at the place where I first started working. He connected the shielding to ground in both ends, not a good idea at the best of times, but in this case the AC system used ground as common return, and the other building had some issues so there was a 100V AC difference between the two buildings. Nice pyrotechnics followed.

Bet he got a real bang out of it.

[GARTHWILSON]

Quote:

but in this case the AC system used ground as common return, and the other building had some issues so there was a 100V AC difference between the two buildings.

From what little I know about the National Electrical Code here in the U.S. (from having to learn a bit a bit from our expert son when installing our solar), I'd have to say that that would definitely not meet it!

[BigDumbDinosaur]

GARTHWILSON wrote:

Quote:

but in this case the AC system used ground as common return, and the other building had some issues so there was a 100V AC difference between the two buildings.

From what little I know about the National Electrical Code here in the U.S. (from having to learn a bit a bit from our expert son when installing our solar), I'd have to say that that would definitely not meet it!

Even in properly wired buildings, ground plane potential imbalance (GPPI) may occur due to slight differences in the transformers that are supplying power, as well as fractional differences in connection resistance where neutral is bonded to ground in the breaker panel. I ran into GPPI quite often back when I did a lot of serial work that involved linking terminals and printers in one building to a host machine in another building. Oftentimes, the problem was worked around by using short-haul modems operating over CAT3 cable, or in one case, over a pair leased from the phone company..

[GARTHWILSON]

It sounds like time for optoisolators.

[Tor]

Traditional RS232 actually uses optoisolators, but when someone adds shielding then the problems start - if both ends are connected.

[Dr Jefyll]

In a post elsewhere, Ed summarizes the distinctly intriguing FT4232H. (emphasis added)

BigEd wrote:

I checked the datasheet. It's a device with a USB side and a serial interface side. The USB side acts as a peripheral so it connects to a USB host. The serial interface side includes i2c and SPI modes which are driven by the chip, so the chip is the host. Also includes UART which can be bidirectional or unidirectional. Typically you might use UART mode and connect it to the UART on your own project. Either side can then send bytes to the other, and it's up to you what protocol you build on top of that. The chip also includes some GPIOs, so the host side can control those to bit-bang some other protocol, although I would guess only slowly.

-- Jeff
Edited to add: the data sheet for the chip, and an image and datasheet for the FT4232H-56Q Mini Module.

FT4232H (USB multi-io chip).pdf

(2.08 MiB) Downloaded 46 times

FT4232H-56Q_Mini_Module.pdf

(1.04 MiB) Downloaded 60 times