FTDI where are you?

>
>> I think that they should have just put the EEPROM right on
>> the chip. Or even have volatile configuration registers on
>> the chip that you can configure via their driver command set.
>> It's expensive to inventory and control new components.
>
> On embedded world 2007 the people at the FTDI booth told my that they plan
> to redo the FT2232 with embedded EEPROM, unique hardware ID and two MPSSE
> channels. I hope they keep promise.
>
> And let's hope they get mode setting right.
>

I'm curious as to why the datasheet for the evaluation board DLP2232M 
states: "There are also several new modes which can be enabled in the 
external EEPROM, or by using DLL driver commands."  Would this not imply 
that you can change modes by commands only and therefore do not require a 
EEPROM?

Thomas

Uwe Bonnes wrote:

> Thomas Magma <somewhere@overtherainbow.com> wrote:
> 
> 
>>>Yes, unfortunately serial EEPROM and 3 x resistors. If you want 
>>>2 x serial  no EEPROM required, I personally wished that two pins
>>>had been used for selecting each port as serial/parallel.
>>>
>>>I'll add a note on my web page.
>>>
> 
> 
>>I think that they should have just put the EEPROM right on 
>>the chip. Or even have volatile configuration registers on
>>the chip that you can configure via their driver command set. 
>>It's expensive to inventory and control new components.
> 
> 
> On embedded world 2007 the people at the FTDI booth told my that they plan
> to redo the FT2232 with embedded EEPROM, unique hardware ID and two MPSSE
> channels. I hope they keep promise.

The Silabs CP21xx series have on board EEPROM. It also has
a PLL on board, so saves a Xtal.

Not sure about how the other finer points compare.

-jg

On Monday, in article <r09pi.253$fJ5.50@pd7urf1no>
     somewhere@overtherainbow.com "Thomas Magma" wrote:

>>
>>> I think that they should have just put the EEPROM right on
>>> the chip. Or even have volatile configuration registers on
>>> the chip that you can configure via their driver command set.
>>> It's expensive to inventory and control new components.
>>
>> On embedded world 2007 the people at the FTDI booth told my that they plan
>> to redo the FT2232 with embedded EEPROM, unique hardware ID and two MPSSE
>> channels. I hope they keep promise.
>>
>> And let's hope they get mode setting right.
>>
>
>I'm curious as to why the datasheet for the evaluation board DLP2232M 
>states: "There are also several new modes which can be enabled in the 
>external EEPROM, or by using DLL driver commands."  Would this not imply 
>that you can change modes by commands only and therefore do not require a 
>EEPROM?

NO, if either of the ports needs to be in FIFO mode (245 mode) it must have
an external EEPROM.

The extra modes are how many different ways the Port A serial port can be
configured for standard serial/JTAG/SPI/I2C....

I still think they should have pins for basic serial/parallel for less
inventory and manufacturing steps of programming several devices on board.

If they could get the driver and device to tell you what chip was at the
other end of the link, let alone have driver config and version numbers
reported in a better way would help.

-- 
Paul Carpenter          | paul@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/>    PC Services
<http://www.gnuh8.org.uk/>              GNU H8 & mailing list info
<http://www.badweb.org.uk/>             For those web sites you hate

>>I'm curious as to why the datasheet for the evaluation board DLP2232M
>>states: "There are also several new modes which can be enabled in the
>>external EEPROM, or by using DLL driver commands."  Would this not imply
>>that you can change modes by commands only and therefore do not require a
>>EEPROM?
>
> NO, if either of the ports needs to be in FIFO mode (245 mode) it must 
> have
> an external EEPROM.
>
> The extra modes are how many different ways the Port A serial port can be
> configured for standard serial/JTAG/SPI/I2C....
>

Hi Paul,

The documentation for the DLP2232M says:
"There are also several new modes which can be enabled in the external 
EEPROM, or by using DLL driver commands. These include Synchronous Bit-Bang 
Mode, a CPU-Style FIFO Interface Mode, a Multi-Protocol Synchronous Serial 
Engine Interface Mode, MCU Host Bus Emulation Mode, and Fast Opto-Isolated 
Serial Interface Mode."

I have the eval board on the way and will soon find out for myself. I have 
also asked the question to tech support at FTDI.

Thomas 

Thomas Magma <somewhere@overtherainbow.com> wrote:
...
> The documentation for the DLP2232M says:
> "There are also several new modes which can be enabled in the external 
> EEPROM, or by using DLL driver commands. These include Synchronous Bit-Bang 
> Mode, a CPU-Style FIFO Interface Mode, a Multi-Protocol Synchronous Serial 
> Engine Interface Mode, MCU Host Bus Emulation Mode, and Fast Opto-Isolated 
> Serial Interface Mode."

> I have the eval board on the way and will soon find out for myself. I have 
> also asked the question to tech support at FTDI.

There is no way to activate FIFO mode without the EEPROM
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Paul Burke wrote:
> Thomas Magma wrote:
>> While I wait... does anyone have any experience with their FT2232D 
>> chip? We are looking to use it to do some FIFO dumps and some bit 
>> banging. How are the API's to deal with?
> 
> 
> The 2232 is good in as far as it goes, which is SPI, I2C and JTAG. 
> Anything other than that, beware. Although the data sheet includes the 
> sentence, "The MPSSE interface is designed to be flexible so that it can 
> be configured to allow any synchronous serial protocol (industry 
> standard or proprietary) to be interfaced ...", in point of fact it is 
> not flexible enough to accommodate many of the protocols used for serial 
> devices like ADCs. In particular, any protocol that requires the clock 
> to be high in the idle state, with data changing on the falling edge, 
> has to be manually bit- banged, which is very slow indeed given the 1ms 
> USB time frame.
> 
> Paul Burke

You can queue up the pin change commands and send them over the USB as a 
bunch - it's not as fast as using the accelerated SPI modes, but at 
least you don't have a separate USB transaction for each change of the 
pin state.

David Brown wrote:
> 
> You can queue up the pin change commands and send them over the USB as a 
> bunch - it's not as fast as using the accelerated SPI modes, but at 
> least you don't have a separate USB transaction for each change of the 
> pin state.
> 

It's on the reads, where you have to sequence the bit input with the 
clock edge outputs, that it gets very slow. There may be ways of 
optimising this, but I haven't found any that make much of a difference.

Paul Burke