1. Home
  2. Embedded Programming
  3. FTDI2232D & SPI

FTDI2232D & SPI

I've been trying to get this working so far without success. I'm just wondering if anyone else has. Our particular requirement is for the 2232 to act as a master to a SiLab MCU acting as a slave. All transactions are bytes. I've not got so far as worrying about CLKPOL or CLKPHA - right now, when I ask the 2232 to send data, SCK waggles like a good 'un, with small gaps at byte boundaries, but the bytes I send do not appear on DO (or DI) which may make a transition at byte boundaries (but never during the byte as I'd like).

I am confident we are in MPSSE mode because when I send 0xAA, I do get 0xFA

0xAA back.

I have checked each output bit individually to make sure they can be high and low.

We are not using CS as this is a hard-wired point-to-point connection.

We are actually using the 2232 in a DLP-2232M-G for prototyping.

Programmed in C++, it is pretty simple code and (frankly, but I would say this), I do not think this is where the problem is. I've listed what I am sending and it all looks good. But is there something I may have missed? Is there any set-up I could have missed (I do FT_ResetDevice() and then SetBitMode(2) to get it into MPSSE mode and as I say above, I am confident this has been successful).

TIA,

Bill Davy

PS Ignore

formatting link

Reply to
Bill Davy
Loading thread data ...

I use a dlp2232 to read the CID block from an SD card using SPI. Works a treat. THe only grief I had was getting the right data to the SD card! Everything I sent to the 2322 went out the SPI port as expected.

Are you using the DLL and examples provided by FTDI? Thats what I did. Ended up using c# in the end, but the c++ examples work a treat.

Reply to
The Real Andy

I did struggle a bit deciding which DLL to use.

As I was using SPI I started off looking at FTCSPI Programmer's Guide but it seemed to be obsessed with sending sub-byte data (control fields). As we have a byte only MCU as a slave that seemed to be more trouble than it was worth, and it said the minimum number of control bits was 2, I preferred not to go that way.

I've ended up using a mixture of FT_Stuff() and things from.AN2232C.

In fact, I have struggled with their documentation.

It seems odd to me that there is no place which brings together the process of doing SPI (FT_SetBitMode() is not mentioned in AN2232C-01 Command Processor for MPSSE and MCU Host Bus Emulation Modes). That document mentions a SETUP command, mentioned nowhere else.

D2XX Programmer's Guide has FT_SetBitMode() but SPI is not mentioned (MPSSE is) and SPI does not appear in the index either. And FT_GetBitMode() does not get back the mode but the state of the data bus. And does FT_ResetDevice() just do a FT_SetBitMode with a mode of zero (reset).

And at some point I have to change the descriptors to support full speed mode.

And as for examples in Pascal - how quaint!

I am sure the technology is great, but using it is a bit of a challenge.

Rgds,

Bill

Reply to
Bill Davy

messagenews: snipped-for-privacy@4ax.com...

Hi,

If it makes you feel any better... The software provided would have to improve vastly before it could be called garbage. It's hard to decide which is worse, the incorrect return values, or the undocumented calling parameters. Their tech support could not deal with a 5-line example that showed a function returning "FT_OK" when in fact the returned data was bogus.

I got tired of the attitude I was seeing, gave up (and designed it out). There are way too many other choices out there.

YMMV, G.

Reply to
ghelbig

Eek. I hesitated to use the word garbage but I HAVE to make this work (clients, deadlines, etc). Looking around, I wish we had used the Maxim MAX3421E which acts as a slave to an MCU and so is quicker (up from 2 MBits/sec to 12 MBits/sec). Perhaps a little more effort but worth it, and the documentation looks much more professional.

I've not found anything which is really a simple replacement for the FTDI part. Have I missed something? Perhaps you could email me ( snipped-for-privacy@XchelSys.co.uk) as I am on the client's site this week.

And it's not as if tehre isn't real work to be done.

Rgds, Bill

Reply to
Bill Davy

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.