> What I don't understand and contradicts my scope measurements is the
> "baud rate * 16": In my application it works pretty well with baud rate
> * 8! At least if I use a baud rate of 65536 I get pretty good results
> for the pulse/pause length I need (220 to 3000 µs).
> Keep us up-to-date with your findings about the FT2232H so maybe next
> time I can really only use one of these chips instead of an extra timer.
I have also had the best success with setting the baud rate to 65536 when
writing (thanks to Albert Huitsing's site, http://www.huitsing.nl/irftdi/).
I am getting baud rates x16 when I write, unlike the baud rate of x8 like
you indicate. Could be because of the missed ticks do to the error below.
Also, the baud rate will be different if you set it before you put the chip
into BitBang mode vs. after you put it into BitBang mode... make sure you
set the baud rate after. Myself... I got different read buffer rates from
different chips. For the FT232R I got x32 the baud rate and from FT2232D
I got x16 the baud rate. I was using version 0.17 of libftdi. Not sure
why, but those were my results.
Spindler, Tyler L schrieb:
>
> I've been working with a couple of the engineers at FTDI trying to
> isolate the issue of inconsistent clocking in BitBang mode when
> writing data. After a couple of months of back and forth I finally
> received a response that there is a known hardware bug in the chips.
> The information was located in the FTDI internal knowledge base. Here
> is the KB snippet from the engineer:
>
> "Many users complain that using the devices in BitBang mode does not
> produce consistent pulse widths. This is true in 'BM, 'R and FT2232
> devices. The reason is related to how the clock is generated when it
> is divided down. It is not correctly synced to the USB clock and
> therefore the pulse width can vary. A workaround to ensure a
> consistent pulse width is to set the baud rate for 3,000,000 (divisor
> = 1). With this rate a consistent pulse width is produced. By padding
> the data stream you can then create wider pulses, albeit at the
> expense of extra data traffic. It is anticipated this feature will be
> resolved in future devices starting with FT2232H / FT4232H."
>
> The work around will not work because it would require a USB speed of
> 384 Mbits/sec to keep up with the BitBang write tick (baud rate * 16)
> and all of the identified chips only support 12 Mbits/sec. I was told
> it was fixed in the FT2232H, which I am going to try in the coming
> weeks. If this can keep someone from beating their head against the
> wall when getting inconsistent clocking while writing out in BitBang
> mode, then I have accomplished my goal.
>
> Tyler
>
>
> ------------------------------------------------------------------------
>
> *libftdi* - see http://www.intra2net.com/en/developer/libftdi for details.
> To unsubscribe send a mail to
> libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
> <mailto:libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx>
>
>
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
