Can't read bytes sent during write cycle

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Using an SPI MCP4262, Send a read command through either python or c code... 
2. Try to read the value during the write cycle

For example:

from mpsse import *

spi = MPSSE(SPI0, 250000)
spi.Start()
spi.Write('\x5F\xFF')
spi.Stop()
spi.Read(2)

What is the expected output? What do you see instead?

No matter what combination of writes and reads you try, you cannot get the data 
sent
during the write cycle.  In this case, you should see \xFF\xE0 on a default 
chip.

What version of the product are you using? On what operating system?
libmpsse-1.1

Please provide any additional information below.
It is possibly a libftdi problem, since the interface doesn't seem to be 
exposed to access the read fifo from the FTDI chip.  Maybe adding in some 
access in libftdi or some direct USB access to that data.

The biggest problem is that most people are using "fake" SPI devices which 
support Write then Read.
The SPI protocol should support Reading the data while writing as it is part of 
the spec and the FTDI
chip does seem to support it.

Original issue reported on code.google.com by robokni...@gmail.com on 17 May 2012 at 4:00

[GoogleCodeExporter]

The device in question is: 
http://ww1.microchip.com/downloads/en/DeviceDoc/22059b.pdf

Original comment by robokni...@gmail.com on 17 May 2012 at 4:01

[GoogleCodeExporter]

I suppose one way it could work is to allow you to transmit something other 
than 0xFF0xFF on the read... I.E. instead of sending junk, send a command with 
the read... But I don't know if that really fixes the problem since I'm not as 
familiar with the libftdi API.  It didn't seem like it would let you actually 
send anything during a read, but maybe another API command to fix that?  Or 
modify what is there (that would probably break a lot of projects though).

Original comment by robokni...@gmail.com on 17 May 2012 at 4:33

[GoogleCodeExporter]

This is my patch for the problem.  You can take a look at it.  Maybe you can 
even clean it up and make it work a little better.  It doesn't always flush the 
buffer properly.  This is a problem if you use this code with the FT2232D 
because you get two errors right off because the library always sends two 
commands that the FT2232D doesn't support.  I guess if you detected the chip, 
there might be a way to fix this, but as it is, it isn't a showstopper.  It 
just means you need to read before you send your first WriteRead command.

Original comment by robokni...@gmail.com on 18 May 2012 at 12:03

Attachments:

• 0001-Added-support-for-full-duplex-WriteRead-SPI.patch

[GoogleCodeExporter]

Thanks roboknight, I've checked in your changes to the trunk along with a few 
bug fixes. It works as long as there are no large data transfers (several MB, 
for example). For large transfers it sometimes works, sometimes doesn't, so 
I'll need to look into that.

I don't have a 2232D on hand; do you remember off hand which two commands were 
not supported? I suppose I could go look up the supported commands in the data 
sheet... :)

Original comment by heffne...@gmail.com on 8 Jul 2012 at 3:22

• Changed state: Started

[GoogleCodeExporter]

I'd have to look, but basically it is some initialization that is supported 
with the H... I'll run it monday again and see what is going on with it.  

btw, it sounds like you perused those changes.  I wanted to mention (hopefully 
you left *THESE* out) that there might have been some "example" changes in 
there that *SHOULDN'T* make it into the trunk.  That was just me hacking up the 
example to work with my device.

Original comment by robokni...@gmail.com on 8 Jul 2012 at 5:17

[GoogleCodeExporter]

No, I selectively added your changes. :)

Original comment by heffne...@gmail.com on 8 Jul 2012 at 11:24

[GoogleCodeExporter]

You asked which commands failed:
If you open a 2232D using something like --
from mpsse import *
a = MPSSE(SPI0, ONE_MHZ, MSB)

You can immediately do a read like this:
a.Read(4)

and you'll find this:
'\xfa\x8b\xfa\x97'

The \xfa indicates the error, the command follows.  So the commands are
0x8b and 0x97

0x97 -- Disable adaptive clocking (the 2232D doesn't have RTCK)
0x8b -- TCK_D5 (which I also think is out of scope for the 2232D)

At any rate, it basically leaves that in the buffer.

Original comment by robokni...@gmail.com on 10 Jul 2012 at 11:23

[GoogleCodeExporter]

Ah, that'll do it. I just checked in a change that purges the buffers after set 
up, so any errors should be cleared out.

I don't have a 2232D ATM, but I tested by intentionally sending bad commands to 
the chip and verifying that this fix cleared the errors out of the receive 
buffer. Let me know if this fixes things for you.

Original comment by heffne...@gmail.com on 11 Jul 2012 at 2:53

[GoogleCodeExporter]

Tested it with the 2232D.  Works fine now.  Or at least the errors are cleared. 
 Thanks.

Original comment by robokni...@gmail.com on 12 Jul 2012 at 7:34

[GoogleCodeExporter]

Oh, and I forgot to mention your Transfer(...) function works really well.  So 
you can probably close this.

Original comment by robokni...@gmail.com on 12 Jul 2012 at 10:02

[GoogleCodeExporter]

Awesome, thanks for verifying!

Original comment by heffne...@gmail.com on 13 Jul 2012 at 8:08

• Changed state: Verified