libftdi Archives

Subject: Re: Could anyone spare a clue?

From: John Oyler <john.oyler@xxxxxxxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Sun, 22 Aug 2010 17:13:08 -0500
On Aug 21, 2010, at 2:49 PM, Michael Plante wrote:

> 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.

Yes, it is the FT2232D.

>>> 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.

The device in question in question is a radio that will be 
transmitting/receiving on 908Mhz (though, this can be configured for other 
frequencies). You set it into any of several transmit and receive modes via 
various SPI commands (really, just setting registers inside the chip to various 
values). Obviously, it can't do both simultaneously, it's a one or the other 
sort of thing.

Even if I figure out how to set the registers via SPI, and read off (or send 
off) data via SPI... from a linux perspective I have no idea how the software 
should work in general. 

I'm thinking that the first libftdi-based executable should really daemonize, 
and open up a fifo with mkfifo. The daemon then continually reads (or interrupt 
based? I don't understand the device completely yet.) incoming radio data, and 
puts it in the fifo for some other process to do something with. Then, I'd have 
another executable (command line) that you could use to transmit a single 
packet... it does the SPI thing, sends data to the proper place on the device, 
then issues the SPI "transmit data" command, cleaning up after itself before 

But I'm not sure I understand whether two different libftdi programs can access 
the same device simultaneously. They're just sending userland USB packets, 
essentially, right? So it's not like one program locks the other out of the 
device, is it?

>>> 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)?

Then the above scheme isn't going to work. Reading the schematics and data 
sheets as best I can, it seems like the B interface is used to blink a pair of 
LEDs, but that the A interface is the one talking to the radio chip.

You've helped me clarify some things, I appreciate that.

To anyone that's curious, the schematic for the device in question is located 
at , 
and the data sheet for the radio chip is located at (The SPI relevant portion 
begins on page 36). I'm currently perusing flashrom's code, that Carl 
suggested. He's helped me at least init SPI mode, but I'm not having much luck 
past that. I think I'm writing to registers, but whenever I attempt to read 
back from them, all I get is 0x00 (despite attempting to write a different 

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

Current Thread