On Aug 23, 2010, at 6:32 PM, Michael Plante wrote:
> 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.
Reading this at the moment...
They make it seem rather simple to blink an LED.
>>> 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.
Yeh, we have a scope and logic analyzer, but I'll need help to use those, and
I'm not really supposed to be working on this. I'll see what I can do.
>>> 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.
Thank you. I just recompiled it with clock_5x set to 0, and it's looking like
it gives me back the correct values now, about half the time. Too often for it
to be randomly correct. The other half, I get 0x00 instead. But I feel like I'm
much closer now. I'm re-reading AN108 again too, some of this is starting to
click for me. Sorry if my questions are dumb, but when I decided to try to do
this, all I saw was a big impenetrable wall of API... it's tough to know where
> 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
> something workable.
I think I understand where you're going with this, but I'm not sure how to make
use of it. If I do some sort of while loop, waiting for it to sync up, there is
some chance that it will barf on me and just hang, right? Is it better to give
up after so many iterations here? That'd leave my software as less than robust.
Or is it something where I'll almost certainly see it sync after a dozen tries,
so I don't have to worry about it?
Anyway, thanks again for the answers. I appreciate the help.
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx