• Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

FTDI USB interface chips

Status
Not open for further replies.

BobW

Active Member
Just wondering if anyone has used the FTDI FT2xxX series USB interface chips to connect between a PIC microcontroller and a personal computer, and what your experiences have been.
 

MrAl

Well-Known Member
Most Helpful Member
Hi,


I used a board with the SMD pattern already on it, and made a sort of breakout board that way. I soldered each pin with a tiny tip soldering iron, but these days i use solder paste and a hot air tool as that works much nicer on SMD packages. I dont do any more FTDI chips though because you can get breakout boards with the chip already on it and just wire up to or jumper to that board instead. I still do other SMD packages though.

I seem to remember i had to download a driver and install that on the computer to get the computer to recognize it as a COM port.
Same with the China version, the CH341 chip, but that's a different driver download.

Once the driver is installed for whatever chip type it acts like a COM port after that with no problems.

I communicate with the FTDI chip with the Windows API function calls made for communication over RS232. So the chip sends the port data, Windows sends it to my program, my program processes the data. You could also send it data too though. The language used for that is C or C++ and a compiler, or you can use an interpreted language and link to the proper DLL(s). The COM port is whatever it installs itself as, COM5, COM6, etc.

Once the driver is installed it works just like a COM port so it works with any software that uses a RS232 communication.

The microcontroller chip port pins connect to the Rx and Tx of the FTDI chip, so it then has RS232 communication with the host computer.
The FTDI chip also needs a male USB-A connector so it can plug into the USB port on the computer, and possibly a USB cable wire to run from the chip USB output to the connector.

I bit banged my microcontroller pins with the RS232 protocol, but you should be able to use any onboard RS232 peripheral functions.

Thinking of communicating your expensive single board true RNG to several slave microcontrollers? Good idea :)
 
Last edited:

BobW

Active Member
Thanks for your reply. I think I'll be okay with the PC end of things. I've already worked with commercial devices that have the FTDI chips built in, so I'm familiar with the virtual com port drivers. So, thanks for your experience at the microcontroller end. In the past I've bit banged the serial comunications, because I was using a very low end PIC that didn't have the UART hardware. So, I could go either way on that. I see that the FTDI line of chips has other interface options such as I2L, and SPI. I'm wondering if SPI might be simpler than UART, or maybe I should just stick with UART since I'm familiar with it.

FTDI makes some very inexpensive breakout boards with all of the tiny parts already attached. So I'll probably go that route initially.
 

MrAl

Well-Known Member
Most Helpful Member
Hi,

Oh ok they have other chips available now that probably were not available back when i was doing this (maybe 10 years back now).
SPI isnt too bad but I2C is especially simple if you already have a library and the speed is acceptable.
I have been experimenting with the Arduino line for a while now and found the I2C is nice to work with because there are only two uC pins required and only two wires to connect (plus power and ground of course), plus you can connect more than one chip to the SAME two I2C microcontroller pins so you can sometimes control eight devices from just two pins on the uC chip.
For example, as i write this i have one microcontroller running with a 20x4 LED display, a RTC real time clock board, and an I2C EEPROM all connected to pins A4 and A5 of the microcontroller. The three devices all have different buss addresses so they only respond to commands sent to their unique addresses.
 

BobW

Active Member
I'll need to check the PIC datasheet, but it seems to me that their advanced serial ports have built-in support for I2C and SPI in addition to regular UART/USART. I'd forgotten that I2C needs to send address data. That may add unnecessary overhead, since I only need to communicate with one device. Maybe plain old UART will be best after all.
 

Nigel Goodwin

Super Moderator
Most Helpful Member
I'll need to check the PIC datasheet, but it seems to me that their advanced serial ports have built-in support for I2C and SPI in addition to regular UART/USART. I'd forgotten that I2C needs to send address data. That may add unnecessary overhead, since I only need to communicate with one device. Maybe plain old UART will be best after all.
It usually is, no point using I2C or SPI unless there's some advantage to it - and serial is far easier than either, using hardware or software.

I'm currently using a number of small FTDI boards for a variety of purposes.
 

DirtyLude

Well-Known Member
It usually is, no point using I2C or SPI unless there's some advantage to it - and serial is far easier than either, using hardware or software.
I disagree with this. SPI send and receive can be bit banged in 10 lines of code and is super simple and isn't timing dependent. For chip to chip communication it would always be my go to if I could spare the extra GPIO lines it needs.

Not sure it matters here, as it doesn't help with talking to the PC. I added FT232RL chips in designs a few years ago. They have been excellent. I haven't done anything with a chip on PCB with them for a long time. I just haven't had anything that needs to talk directly to the PC. A lot of controversy over them bricking counterfeits, lately. I've bought modules for playing with arduino's and testing UARTs and my favorite has been the CP2102 modules. Never used a bare chip in a design, though.

As you mentioned, if you aren't putting it in a final design that you want it all on one board, I would just by a handful of modules to use.
 

MrAl

Well-Known Member
Most Helpful Member
Hi again,

Back in the mid 70's there was little around like this so i had to invent my own protocol. It was just a serial clock technique made for short range wired communication. All it was was serial, clocked data, with no feedback at all. The idea was that if the chip(s) circuit receiving the data was done right then it should always get the data so no feedback was required. It always worked, so i never added feedback. I may have added an acknowledge signal later on but i cant remember all the details that far back. I could get transfer rates like 15 megabits per second maybe higher.

But i think SPI might be able to work like that too? If you make your own bit banged interface.

I like I2C because we can use the SAME two pins on the uC chip for several peripherals. That saves pins for other uses.
 

BobW

Active Member
Bit banging is often a lot easier than having to learn all of the setup parameters of the microcontroller's serial module. Not too long ago I needed to interface a rotary encoder that used SSI (synchronous serial interface) protocol. I looked at using the built-in serial hardware on the PIC, but it turned out to be much simpler to bit-bang it. It had an odd size data word length that made it too much trouble to use the serial module.

For the current project, I think I'm convinced to go with RS-232/UART rather than SPI or I2C. I just remembered that I have an ancient Keyspan USB/serial adapter somewhere in the junk box that I can use for initial testing. I'll probably go with an FTDI UMFT230XB-01 breakout board with the parts already soldered on. Not quite as cheap as the Ebay part that Pommie mentioned, but given the recent USB malware scare, I'm a bit reluctant to plug any USB device into my computer, if it doesn't come from a reputable supplier.
 

Nigel Goodwin

Super Moderator
Most Helpful Member
I like I2C because we can use the SAME two pins on the uC chip for several peripherals. That saves pins for other uses.
Assuming you've got devices that already require I2C, then it's a great idea, as it's a great saving on pins :D

I've recently been using I2C LCD adaptor boards, as I was already using I2C FRAM, so it saved ALL the pins required for an LCD.
 

BobW

Active Member
After Pommie mentioned ready made converter cables, I did a bit more searching, and found that Staples has several listed—some under $5. So, I took a trip to the local store to see if there were any in stock. Unfortunately not. So, I've placed an order with DigiKey for the FTDI breakout board, because I'll have it overnight. I'm too impatient to get it anywhere else.

This USB to serial interface thing seems like it was invented as a stop gap measure to deal with legacy serial devices when USB first arrived on the scene. That's over 15 years ago though, and it appears that these are still nearly as popular as ever. I'm not surprised, because implementing even the simplest USB protocol, the HID device, is an enormous amount of work. If you don't need anything more than what a serial interface can provide, then why complicate things. However, I'm curious whether anyone here has done any projects with the USB module on a PIC.
 

MrAl

Well-Known Member
Most Helpful Member
After Pommie mentioned ready made converter cables, I did a bit more searching, and found that Staples has several listed—some under $5. So, I took a trip to the local store to see if there were any in stock. Unfortunately not. So, I've placed an order with DigiKey for the FTDI breakout board, because I'll have it overnight. I'm too impatient to get it anywhere else.

This USB to serial interface thing seems like it was invented as a stop gap measure to deal with legacy serial devices when USB first arrived on the scene. That's over 15 years ago though, and it appears that these are still nearly as popular as ever. I'm not surprised, because implementing even the simplest USB protocol, the HID device, is an enormous amount of work. If you don't need anything more than what a serial interface can provide, then why complicate things. However, I'm curious whether anyone here has done any projects with the USB module on a PIC.
Hi,

Sorry it took me so long to get back here.

I have read that with the PIC 16F1455 chip (which has USB pins +D and -D right on it) requires HALF the program memory to hold the USB code (driver). That's nuts if you ask me. Also, Microchip might be charging for the license for that code depending on how it is to be used (personal/commercial).
 

NorthGuy

Well-Known Member
I'm not surprised, because implementing even the simplest USB protocol, the HID device, is an enormous amount of work. If you don't need anything more than what a serial interface can provide, then why complicate things. However, I'm curious whether anyone here has done any projects with the USB module on a PIC.
I have built a PIC programmer with PIC16F1454. It can program 1233 different PIC devices and works faster than ICD3. The main goal for this project was to provide hardware debugger for the development system I'm working on (not ready yet). It also can work as USB-to-UART translator with up to 2MBaud speed, but since HID interface has speed limit of 64KB/sec, sustainable transfers are only feasible with 500K baud (or 460800). The chip can be installed on a board and work both as a programmer (to replace bootloader) and USB-to-UART converter (to replace FTDI chip or similar). There was enough program memory on this PIC to accomplish all this, even some left. Cannot post the link as I think it is against forum rules :(

It took me couple weeks to get HID interface working at full speed - only a fraction of time that went into the project.
 

BobW

Active Member
A couple of weeks sounds about right. My problem is that even if I tried to develop an HID interface on the PIC side, I'd still have to develop the interface on the PC side. The IDE that I'm using doesn't natively support any USB interfaces which means that I'd have to write all of that driver code as well or else buy a 3rd party plug-in. However it does support the emulated COM port. So, the FTDI chip is ideal.

BTW, the FTDI parts arrived two days ago, and I've been tinkering with them. The PC end is communicating with it nicely. But so far, I've just got an LED connected to the TxD line on the FTDI chip, so I can see it blink when I send data from the PC. Have to breadboard my PIC now.

Hi,

Sorry it took me so long to get back here.

I have read that with the PIC 16F1455 chip (which has USB pins +D and -D right on it) requires HALF the program memory to hold the USB code (driver). That's nuts if you ask me. Also, Microchip might be charging for the license for that code depending on how it is to be used (personal/commercial).
Considering that Microchip makes a chip similar to the FTDI USB/serial converters (eg., Microchip part # MCP2200), I wonder why they don't integrate this function into some of their PICs.
 

MrAl

Well-Known Member
Most Helpful Member
Hello again,

The MC part sounds interesting, available in SOIC package too. Seems tempting to try. Good price too. Let me know if you try one. Royalty free too.

Maybe they thought the code would be smaller when the designed the 1455 chip. Later they found out i was more complicated than they thought :)
 

NorthGuy

Well-Known Member
Maybe they thought the code would be smaller when the designed the 1455 chip. Later they found out i was more complicated than they thought :)
The USB code certainly doesn't take anywhere near the half of the memory. Whoever told you that is not good at writing code. When written well, the USB code doesn't take much space, especially if USB class is simple, such as HID or CDC (serial). The hardware USB controller on the PIC does most of the work for you.

I worked with MCP2200. It works well, but it uses Microsoft built-in serial driver, which (at least up to Win 10) doesn't handle connections well, so you periodically need to plug it out, close all the software, then re-plug it and re-start the software. FTDI chips use proprietary drivers which admittedly do not have these problems. MCP2200 is just PIC18F with pre-programmed USB. And it also requires 12MHz external crystal.
 

MrAl

Well-Known Member
Most Helpful Member
Hello,

Well i read it took half the flash memory i guess that was for RS232 type COM port operation.

Sounds like i'd stay away from the MCP2200 then. We dont need to "install' problems along with our solutions.
Geeze, even the cheap chinese chips do better than that.
 

NorthGuy

Well-Known Member
We dont need to "install' problems along with our solutions.
FTDI chips also require drivers to be installed, but Windows can do it automatically. Microsoft certainly screwed up by not making CDC drivers standard up until Windows 10. If they did better job with CDC drivers, there would be much less HID devices out there, and much more CDC.

Geeze, even the cheap chinese chips do better than that.
These are just FTDI clones. There was an interesting story that FTDI altered their drivers so that they would kill Chinese FTDI clones. Turned out that lots of their genuine customers were using these clones thinking they were genuine FTDI chips. FTDI had to roll this back and they no longer kill chips with their drivers.
 

BobW

Active Member
I got the the circuit wired up on veroboard last night and the PIC programmed. I tested it on my Mac computer. OSX has the CDC drivers built in, so I didn't bother loading the FTDI driver. Everything seems to work well. Now, I need to implement RTS/CTS flow control. That'll be my project for today.
 
Status
Not open for further replies.

Latest threads

EE World Online Articles

Loading
Top