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 libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
