Re: FTDI2232D & SPI
- From: ghelbig@xxxxxxxxx
- Date: Fri, 30 May 2008 09:13:43 -0700 (PDT)
On May 30, 3:48 am, "Bill Davy" <B...@xxxxxxxxxxxxxxx> wrote:
"The Real Andy" <thereala...@xxxxxxxxxx> wrote in messagenews:qkgv3491md87qeeeu6hoii3f2k7dm3gn9t@xxxxxxxxxx
On Fri, 30 May 2008 09:40:17 +0100, "Bill Davy" <B...@xxxxxxxxxxxxxxx>
wrote:
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).
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.
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
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.
.
- References:
- FTDI2232D & SPI
- From: Bill Davy
- Re: FTDI2232D & SPI
- From: The Real Andy
- Re: FTDI2232D & SPI
- From: Bill Davy
- FTDI2232D & SPI
- Prev by Date: Re: Driving tri-state LED matrix
- Next by Date: Re: Stack Overflow Detection
- Previous by thread: Re: FTDI2232D & SPI
- Next by thread: Recommend open source graphics library
- Index(es):
Relevant Pages
|
