On 2013-02-01 11:04, Uwe Bonnes wrote:
>>>>> "Karl" == Karl Cunningham <karlc@xxxxxxxxxx> writes:
Karl> We have been using an FT245R for several years, programming
them
Karl> with libftdi v0.16 with an older Ubuntu system. After
programming
Karl> one with libftdi1 v1.0, we can't communicate with it.
Karl> I traced the problem to a difference in what is programmed
into
Karl> the first byte of the eeprom. v1.0 is programming that byte
as
Karl> 0x00. Version 0.16 originally did that too, but I had
modified it
Karl> to program with 0x09 to match what MProg was doing. This
made the
Karl> chip work for us.
I think bit 3 of Eeprom byte 0 is not yet documented in libftdi. If
you have
access to mprog, experiment a little to find out it's meaning and
document
and in lin libftdi.
Bit 3 might be DRIVER_VCP, although libftdi does not touch it for
TYPE_R.
When experimenting with an FT245R I found that bit 0 is the culprit -
when cleared, an FT245R is turned into an FT232R (or so it seems).
If you turn the bit back on, the functionality of the FT245R is
restored.
Unfortunately, there is no way (that I know of) to detect if a chip is
really an FT232R or an FT245R other than checking bit 0 of byte 0.
Cheers
Anders
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|