I've been working with the simple.c file found in the examples. After doing the ftdi_usb_open(), 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? 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.
Also, I have a more general architecture question... the device itself both sends and receives data, and short of designing proper kernel drivers (which means I wouldn't bother using libftdi) I don't know how to do this. 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, I could shell script more complicated behavior around that. But I'd also need a daemon running in the background, taking received data and putting it in a fifo or maybe unix socket. But if this daemon is using libftdi to do that, can a second libftdi executable safely interact with the same device? Are there design considerations here with a strategy like that? Is it just flat-out impossible, or stupid? I mean, this is all userland code, so it seems like it should work, as long as both executables are well-behaved. Thanks, John O. -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
