ft232 vs prolific

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here i am experiencing a strange problem. I am designing a programmer where mass data transfer takes place. For testing i used a commercial usb to serial convertor (810) which uses prolific.

When i tried FT232 at my final board, the speed is very very low compared to prolific.

I am using 115200, 8,N, 1 setting.

I again checked my final board using prolific which works in a good speed, which exists in my testing board.

Does anybody experienced this type of problem?

or FT232 does not support this speed?

Nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure what you are asking, but are you saying that you are using the FTDI in the VCP mode as a bit-bang ISP programmer? If so, it only sends out one bit per 10ms IIRC and will be extremely slow. The way to use the FTDI chip for an ISP programmer is to use the real bit-bang mode for the device. Pascal Stang does this with his ftisp program but last time I looked I couldn't find any public source code. Maybe you are asking something else?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for your reply.

iam sorry for not being clear. (sorry for my english)

I am using atmega8 micro as programmer and using ftdi FT232 for communication of atmega8 with pc.

Nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Problem is with the USB interrupt rate (interval at which the USB buffer is transmitted; depending on buffer size, this determines USB link throughput). FTDI devices use interrupt transfers on the USB link, and they are factory set at 20ms. So while the throughput stays pretty much the same, LATENCY is greatly reduced. Fortunately the FTDI devices I have come across all have the option to change the USB latency all the way down to 1ms in the driver config. If you do not see this option, I recommend you download the FTDI configuration app, and possibly even replace the existing driver.

The Prolific one must have it's latency configured properly, or is using a custom driver (non-HID)...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hai Unixwhore

Yes, i already tried setting latency to 1. Still iam unable to get the speed.

The driver i have loaded is the latest one from FTDI

Nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It sounds like you are using the FTDI as a virtual serial port at 115200 solely to pass a hex file from a PC to something on an ATmega8 that is then doing the programming of the actual device. In this case, the FTDI is nothing be a black box and it should be blazing fast. Either something is wrong on the PC side or the ATmega8 side, but I don't see how the FTDI chip is doing anything other than being a big pipe between them. Are you sure that your ATmega code that takes the hex file and outputs it to the device being programmed is working properly? What code are you using on the ATMega8? Is it something that takes the hex file and then converts it into an SPI stream for the ISP of the device being programmed?

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hai Smiley

The other sections atmega8 and the target chip 25L080 is working properly. To confirm this, i had bypassed FT232 section with my old prolific based converter connecting directly to M8. It works at good speed as before.

Actually i am sending 256 bytes as a packet to the M8. The speed is ~100 packets per second with prolific converter. While FT232 can only send 1 packet per second that is very slow.

Nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use FTDI parts at 115,200 in virtual COM port mode, and I have not seen any speed problems.
Not much help, I know...

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see how the FTDI chip could be the problem. It should just be working as a black-box sending data at 115200 baud. If you are sure it is not on the ATmega8 side, then what about on the PC side, what is sending the data? How can you be sure it is sending it in 256 byte packets? What do packets have to do with serial ports anyway since for it a 'packet' would be the number of bits in a data value, usually 9 bits per transimission depending on how you have set up the modem paramenters. Virtual Serial Ports don't use the concept of multi-byte packets. You que up the bytes of data and then the VCP adds the modem bit and them.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm sure I read somewhere that FTDI USB VCPs can be very slow if you are sending single bytes(this is probably the latency isuue already mentioned) but if you're sending 256 byte packets ther should be no problem.

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The killer slowness comes when folks take an old serial port bit-bang program and try to use that as an ISP programmer over a Virtual Serial Port using the FTDI. It works okay for a real serial port which can change the modem bits at the full baud rate, but the VCP only changes modem bit states once each 10 ms (or there abouts) so it can take 10s of minutes to do an ISP prgram that would take seconds for a regular bit twiddled serial port. I assume that since the modem bits are normally setup before the data transmission, FTDI saw no need to make that process fast. However, if you use the FTDI in its native bitbang mode (not as a VCP) to emulate SPI for ISP programming, as does Pascal Stang with ftisp, you can get a very fast ISP programmer. It is all kind of complex and I've got a few articles on my website that might help anyone who is really interested to get started using these things in either the VCP or bit-bang modes.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The pc side is a vb program using mscomm object. The vb program reads on byte from the file and sends it to the comport. I am sure that both the M8 and vb are working fine because i had checked them numerous times with the prolific usb to serial converter module.

After searching and reading i came to understand that the problem is latency which is set to 1ms (the least possible). If there any way to avoid this? or any other setting possible for this?

nandhu

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The way to avoid it is to write more than one byte at a time... you want to fill the buffer as much as possible. Look into using the read and write functions that act on blocks of data rather than the putc and getc primitives that work only a single byte at a time. The Prolific driver may be faster because the driver cues up things into blocks, whereas the FTDI driver may not be doing this.

smileymicros wrote:
I assume that since the modem bits are normally setup before the data transmission, FTDI saw no need to make that process fast.

It's not really a FTDI issue... but rather a USB/Windows issue. Windows limits how often the system can access a USB device, in order to prevent the USB device from consuming too much of the CPU, making the rest of the system unresponsive.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks to everyone...

Glitch is right, that is the reason for my problem.

It is well explained in an232b-04_datalatencyflow.pdf

I will try what glitch advised.

Nandhu