John Oyler wrote:
>> The schematic has two LEDs hooked up to B on BDBUS6 & 7.
>> Would it be difficult to make those blink?
>> BDBUS0 & 1 are apparently IRQs, those are probably more important to me.
Ok, yes, upon seeing the real schematic (other email), it looks like your
best bet will be some sort of bit bang mode.
>> But the value I read back from the register does not seem to be the value
>> put into it. In fact, reading it twice, I get back a different value each
Can you put a scope or digital logic probe on the lines and see if the FTDI
chip is doing what you expect? That will ease things considerably. It
could just be returning you random junk. If you can't, then you should at
least post what you think you're reading and writing. You might also
consider checking whether /CS is automatically asserted, or if you need to
control it manually; when I did this, I did not use /CS, so I don't know
which it is. If it's automatic, you'll need to do a read/write op, instead
of sequentially writing and reading; otherwise, what you're doing is fine.
>> usually 0x00, 0xfa and 0x8a.
Not sure what the 0x00 is, but read the section of AN108 on "bad commands"
for what 0xFA is, and then go back and re-read what I wrote about
re-synchronizing in MPSSE. It sounds like you should not be using CLOCK_5X;
that opcode is for the FT2232H part only, and the FT2232D is telling you it
doesn't recognize the command. You are mistakenly assuming that the
response is to your following command, when, in reality, you've failed to
read the results of the initialization sequence.
Send a 0xAA, wait for 0xFA 0xAA, and maybe do the same with 0xAB. That is
what FTCSPI does (i.e., it assumes 0xAA and 0xAB will always be bad
commands). I do not know the exact logic it uses. You may need to retry a
few times until you sync; I had to fool with this quite a bit to get
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx