One too many clock edges are output whe using SPI modes 1 and 3 about libmpsse HOT 5 CLOSED

Hi. I'm no expert, but I just happen to be reading about the FTDI chips this 
week, and I ran across your question shortly after looking at this app note: 
http://www.ftdichip.com/Support/Documents/AppNotes/AN_114_FTDI_Hi_Speed_USB_To_S
PI_Example.pdf - and I remembered running across this quote while I was reading 
about their SPI support: "It is recommended that designers review the SPI Slave 
data sheet to determine the SPI mode implementation. FTDI device can only 
support mode 0 and mode 2 due to the limitation of MPSSE engine." Sorry to be 
the bearer of bad news, but it sounds like this might not be fixable, at least 
until they make some change to the MPSSE engine to address the problem. (or, I 
guess, you might be able to do something in bit-bang mode, for a lot more work 
and at a slower speed.) Good luck!

Hi.
I see... Thank you for pointing this out.
Maybe a note should be added to this library stating that only modes 0 and 2 
are working properly...

Yes, the MPSSE engine only supports modes 0 and 2.

This library makes an attempt to support modes 1 and 3 in software, though as 
you've seen in the comments/code/scope, it's a hack since the MPSSE engine 
doesn't want to work properly in these modes. I've tested modes 1 and 3 against 
the DS1305 real time clock chip successfully, and I've used mode 3 successfully 
with various SPI EEPROMs and SPI flash chips, though YMMV. You can always use 
the bitbang mode if necessary, but this will obviously be much slower.

I will add a statement to this effect in the documentation.

Hi,
It seems modes 1 and 3 will work correctly only with devices that support 
instruction decoding "on the fly": that is, the instruction is executed -if 
valid- as soon as it's loaded into the shift register, without waiting for CS 
to go high.

Unfortunately, when you are communicating with SPI slaves that support 
daisy-chaining, the execution of commands can only take place after CS is 
removed. This ensures that the correct codes have been loaded throughout the 
whole chain.
In this case an additional clock cycle is completely disruptive...

Devices that perform clock counting are also affected by this and will void the 
transferred data every time.

Thanks pietro, I've updated the SPI README file as well as the summary on the 
main project page to reflect the state of SPI 1/3 support.