On Aug 31, 2010, at 3:58 PM, Michael Plante wrote:
>>> Now, it could *possibly* be that there's no data to read... but
>>> on the serial port version of this radio, I'm seeing a packet
>>> coming in about every second here in the office. And since I
>>> keep trying to read one byte at a time, for as long as several
>>> minutes, I should get *something*. All zeros, the whole way.
>
> Which commands (particularly the 0x80 commands) are you sending to get this
> display? It would be nice to have the list of I/O bytes that go with the
> screenshot.
You're seeing me do an 0x80, then an 0x08, and then a 0x1b. I'm not supposed to
write to MOSI, so no 0x11s, but I am attempting to read one byte back. That's
0x20 (and the size). Finally, I do another 0x80, 0x18, 0x1b.
I repeating that for a 1000 loops or whatever, which takes long enough that
it's impossible that the fifo is empty.
The code for the 0x20 is generating 0x00,0x00 for the args... that's 1 byte
read, right?
>>> Another possibility is that the radio's not in receive mode, but
>>> this seems even less likely than that there are no packets in the fifo.
>
> Is there a register you can read that states how many bytes are in the FIFO,
> or at least whether or not it's empty?
>
No. That's what the bit banging on B would give me... there are two interrupts,
and their states tell you if it's empty/full, and a bunch of other things I
don't understand, depending on which or both.
>
>>> The other thing is, in the data sheet it says "To read bytes from the
> FIFO the
>>> timing diagram below should be carefully followed by the uC." So, maybe
> I'm not
>>> doing it as perfect as I should be, my code is still rather sloppy.
>
> They probably mean exactly what I was saying about +ve/-ve edges and that
> sort of thing, and, because there are no transitions on MOSI/MISO, that
> isn't causing the current problem you showed. Minimum times may also
> matter, but are not shown on that diagram. Are you sure that your FTDI SPI
> clock speed is low enough that the radio chip can keep up (i.e., is your
> divisor high enough)?
Not certain. There's a 6Mhz crystal on the device. The flashrom code I borrowed
from is setting that, and I think it was claiming that it did it at 2Mhz. But I
don't understand that well enough other than it works partially now.
>>> And how do I tell this dumb thing to toggle high again more quickly?
>
> I don't see it toggling high again at all. Is that off the right hand side
> of the screen? Even on the zoomed-out part at the top, which is admittedly
> difficult to read, it doesn't seem to be going back high. And if you have a
> question like that, I'd need to see exactly when the bytes are being sent
> from the computer to the 2232, etc. You should certainly try to send the
> bit-bang/MPSSE command to raise the line in the same buffer where you tell
> it to do the SPI stuff.
>
It never toggles high again on the portion of this that I can pan. I'm assuming
it does so eventually, else even stranger things would be happening.
Thanks,
John O.
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
