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

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: <abbo...@mev.co.uk> )=-
-=(                          Web: http://www.mev.co.uk/  )=-

barebox mailing list

Reply via email to