might be some windows driver issue then. Could always try from a live linux distro, just remember most require you to add your user to the dialout or similar group.

Well, I've been using these devices for a few years with the 65C51. Depending on whether you pick the Male or Female version, the lines basically reverse for interfacing. In short, the FTDI device is a UART that attaches to a (modern) PC, i.e., one without a traditional serial port, by USB (so it gives you a serial port on the PC). So interfacing them to another UART is the same as connecting any two UARTs via a null-modem configuration. The Male version does this internally, the Female version requires you to swap the lines (RxD to TxD, etc.).

I prefer these as the interface (to the UART) on my 65C02 systems, as I can directly plug it into the USB port of any computer and use a terminal program configured for (the USB) serial port and access it.

_________________
Regards, KM
https://github.com/floobydust

Is there another device I should be looking at?

Dang, this thing seems perfect to. There has to be something obvious and dumb that I'm getting wrong here!

Maybe I'll post a YouTube video later so you can see what I'm up to. Maybe I'm doing something so fundamentally stupid you guys wouldn't even think of it!

I'll see what I can do.

Does anything happen on other pins when you type something in terminal window?

Good question. I'll have to get back to you guys, as I'm talking my family out for a bite. That does seem like an obvious test now that you mention it.

Ok, I'm still at the restaurant, but I got to thinking about what Arlet said. So I dug up the diagram.

TxD is exactly centered in the pinout. So if I have misread the diagram, it wouldn't change.

So then I looked at the small print. It says "View from top THROUGH the device". If I understand that correctly, I've been using a mirror image as my pinout!

Doh!!!!

Can't test until I get home, but I guarantee that's it. It was surely the ambidextrous position if the TxD pin that kept me fooled.

I'll let you know what I find it. Either way, dumb on me for not checking other pins.

This hobby can be awfully humbling sometimes. Here you think that, because you're doing this kinda stuff, you are smarter than the average bear, and then it just shows you you are a just dumbass like everyone else!

That was the issue. I read the pinout from the wrong perspective. Nevermind that every component in every data sheet is described from the top down.

It works now! Thanks for helping me out so much!

DTE means Data Terminal Equipment. DCE means Data Communications Equipment.

A DTE is any device that is the termination of a serial interface link. Examples of a DTE include a character terminal, a printer (serial printers are quite common in warehousing applications), a magnetic stripe reader (aka credit card reader), bar code reader, industrial machine controller, etc. The commonality among these items is they either transmit data out a serial port, receive data from a serial port, or do both. My POC units are DTEs.

When a DTE is connected directly to another DTE the cable that is used to make the connection must be cross-connected: TxD on device number 1 connects to RxD on device number 2, CTS on device number 1 is connected to RTS on device number 2, etc. Device 2's TxD would go to device 1's RxD, etc.

A DCE is any device that is capable of interconnecting one DTE to another DTE. The DCE's distinguishing characteristic is that it can accept the serial interface signals from a DTE, which swing roughly from -12 volts to + 12 volts, and convert them to a different format for transmission over a distance that is not practical with a hard-wired link. The most common type of DCE is a modem, which converts the serial interface signals to a train of audio pulses and vice versa. The cable I described above is a "null modem," which is technically a DCE, although it is passive.

The reason for the voltage swings of the serial interface is to make it reasonably robust in the face of locally generated electrical noise. This is an especially needed characteristic in a factory setting, where all kinds of electrical garbage gets into data lines from big motors, HID lighting, power factor issues, etc. TIA-232 is unbalanced to ground, so the effects of ground plane potential imbalance (GPPI) can corrupt the signal if the imbalance is sufficiently severe. I occasionally run into that problem when two machines that are interconnected via TIA-232 are powered from physically separate breaker panels and one of the panels supports a substantially greater load than the other.

The problem of GPPI led to the development of TIA-422 and TIA-485, both of which are balanced-to-ground serial interfaces and are able to operate over long hard-wired links at high data rates. The AppleTalk network used with the older Macs was a version of TIA-422 and served Apple well until Ethernet took over in the latter 1990s (incidentally, one can implement TCP/IP on a TIA-422 or TIA-485 link if so inclined).

All of my clients with machine tools have serial hardware in the machines' control systems, almost always TIA-485. I'm talking about CNC machining centers, centerless grinders, gear hobbers, etc. USB is useless in such applications because it's too complicated and can't be run over any useful distance. The outer limit with USB 2.0 is about 5 meters, which would barely make it from one end of my office to the other. Hard-wired TIA-232 can run 150 to 200 feet using unshielded twisted-pair (UTP) cable, and TIA-485 can be reliably operated at distances up to 4000 feet (~1.2 kilometers) on UTP, 12 times the maximum practical distance of 100Base-T Ethernet. TIA-232 can be run even farther with short-haul modems, over dozens of miles if repeated dry telephone lines are used.

One of the problems I frequently run into with people who work with computers today is they know little to nothing about serial interfaces and non-consumer computer hardware. That is the result of not being exposed to that sort of hardware, especially since the PC industry (specifically, Microsoft) decided things such as Centronics ports and serial interfaces were "too old and obsolete." That thinking, of course, is very myopic, and reflects the fallacy of thinking only in terms of short-term consumer needs. I always have PCI parallel and serial interface cards in my inventory at all times to connect all that "old and obsolete" hardware that continues to used. They don't collect any dust on the shelf.

Speaking of short-haul modems, I had a client in Chicago whose warehouse was two city blocks from the factory itself. They wanted a printer installed in the warehouse on which shipping orders would be printed. We had them lease a dry line from the telephone company, to which we connected a pair of short-haul modems running at 9600 bps. The modem at the warehouse was directly connected to the printer's serial port and the other modem in the factory was connected to their UNIX server's serial interface multiplexer (32 TIA-232 ports). From the server's perspective, the printer appeared to hard-wired, even though the as-the-crow-flies distance was approximately an eighth mile and the linear distance of the dry line was about 6 miles (the central office was slightly less than 3 miles away). This application was practical only because the server had TIA-232 hardware, as did the printer (an Okidata ML395).

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

at least you got it

But be warned: there are (sometimes) bottom views in datasheets

And some even use mixed views on the same page. And it's not always indicated.

Anyway, glad I could help.