libftdi Archives

Subject: Could anyone spare a clue?

From: John Oyler <john.oyler@xxxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Fri, 20 Aug 2010 10:20:47 -0500
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.

John O.
libftdi - see for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx

Current Thread