We are facing a similar issue to the one that was fixed in #69 - just when using the SpiBus instead of SpiDevice.

Running this code:

pub mod error;
use error::Result;

use ftdi_embedded_hal::eh1::digital::OutputPin;
use ftdi_embedded_hal::eh1::spi::{SpiBus, SpiDevice};
use ftdi_embedded_hal::libftd2xx::FtdiCommon;
use ftdi_embedded_hal::{self as hal};

fn main() -> Result<()> {
    let mut ftdi = ftdi_embedded_hal::libftd2xx::Ft4232h::with_description("Quad RS232-HS B")?;
    println!("found ftdi with device info: {:?}", ftdi.device_info());

    let hal = hal::FtHal::init_default(ftdi)?;
    let mut device = hal.spi()?;
    let mut cs = hal.ad3()?;

    cs.set_high()?;
    device.set_clock_polarity(hal::eh0::spi::Polarity::IdleHigh);
    device.write(&[0; 1])?;
    cs.set_low()?;

    let command = [1, 0xff, 0x80];

    device.write(&command)?;

    cs.set_high()?;

    Ok(())
}

What we get is this:

Where you can see too short clocks at the start of the communication and between bytes. If we use the SpiDevice this does not happen.
I currently don't see a way to work around this since there is no public API with which I could "fix" the polarity of the clock, similar to what was done in #69. A possible fix would be to preset the clock bit in FtInner::lower in the set_clock_polarity call - we'll be testing that.

Or did we mess up here / overlook some function?

To preempt the question: we are not using SpiDevice since we are communicating with a device where we need to poll for a non-zero byte, without releasing the CS pin. I don't see a way to do this with the features of the SpiDevice trait.