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