John Oyler wrote:
>> I then do a ftdi_set_bitmode(&ftdic, 0x00, 0x02); which doesn't return
>> an error. Am I correct in understanding that this puts the chip into
MPSSE mode?
Yes. I generally have a more complicated startup sequence, but I'm not
positive that what I do is necessary, so if that works for you, great. Let
me know if you want me to post the sequence, but it's probably superfluous.
You should consider setting the divisor and similar things, though.
Which FTDI chip? I'll assume it's similar to the FT2232D I used.
>> Can anyone summarize what needs to be done next to talk to an SPI chip
>> on the other side? I need to set its registers (I have a detailed
>> description of how to do this from an SPI standpoint), and read back
others.
>> I'm picking through the documentation as best I can, but nothing is
really jumping out at me as what I need to do next.
You need to look at AN108, "command processor for MPSSE". Everything is a
packet of sorts. Maybe my timing was overly aggressive, but I had to add
functions to resynchronize (done by sending known-bad commands 0xAA and
0xAB, and waiting for *proper* replies, possibly retrying) occasionally.
Not everything about MPSSE is clearly documented, but the SPI aspect should
be straightforward if you're careful to build it up block by block.
>> Also, I have a more general architecture question... the device itself
both
>> sends and receives data,
>> [...]
>> I'm thinking a simple executable that puts it into transmit mode, sends
>> the data off, and then puts it back into receive mode before exiting
would
>> be nice,
It's not clear what you mean by "transmit mode" or "receive mode". You
mentioned understanding SPI. In its most general form (typical, though),
data is sent and received simultaneously in SPI. MPSSE allows you to send,
receive, or do both. But, at the USB level, everything is polled, period.
So if you're not causing the OS to wait for data, there's a FIFO filling up
in the FTDI chip, but it's not coming back to the host. You need to have a
read request going.
>> But if this daemon is using libftdi to do that, can a second libftdi
executable
>> safely interact with the same device?
Maybe on a different interface (A vs B, etc), but I suspect the OS won't let
you otherwise. You can try. What do you *really* want to do (high-level
goal)?
Regards,
Michael
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
