[RFC 0/2] sandbox: add gpio support with libftdi1

[Ian Abbott]

On 16/02/17 07:34, Sascha Hauer wrote:
> Hi Antony,
>
> On Wed, Feb 15, 2017 at 10:12:25AM +0300, Antony Pavlov wrote:
>> This patch series makes it possible to use FT2232H ACBUS[7:0]
>> pins as gpio pins from sandbox barebox.
>>
>> I have tested output gpio functionality by connecting
>> a LED to ACBUS[0] and lightening it with gpio_direction_output
>> and gpio_set_value barebox commands.
>>
>> Also I have performed input test with ACBUS[0] -> ACBUS[1] loopback.
>>
>> The main goal of adding gpio functionality to sandbox barebox
>> is using it for connecting real i2c and spi devices to sandbox barebox
>> (not tested yet).
>
> I just read that the FT2232H can even do native I2C and SPI, so no gpio
> bitbanging would be necessary. Would it be possible to use this mode
> instead?
>
> Otherwise I think there should be a possibility to specify which, if
> any, FT2232H chip barebox uses.

The MPSSE mode of the FT2232H can sort of do native I2C, but not in a 
strictly conforming way.  The I2C SDA needs to be connected to two pins 
on the FT2232H, one for output and one for input, and there is a 
"Drive-Only-Zero" option for the output to ensure it is only driven low, 
and tri-stated high.  However, the I2C SCL is only connected to an 
output pin on the FT2232H, and is always driven in both directions. 
Therefore, it does not support "clock-stretching" by I2C slaves (where a 
slave pulls the SCL line low until it is ready), because it cannot read 
back the state of the SCL line.  Worse, if an I2C slave is doing 
clock-stretching by driving SCL low, this will contend with the FT2232H 
driving SCL high at the same time.

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti at mev.co.uk> )=-
-=(                          Web: http://www.mev.co.uk/  )=-