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 exiting. 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 http://www.semtech.com/images/datasheet/sx1211mesh-868-915-semesh-um.pdf , and the data sheet for the radio chip is located at http://www.semtech.com/images/datasheet/sx1211.pdf (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 value). Thanks everyone, John O. -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
