From: Ian Abbott <abbotti@mev.co.uk>
To: Sascha Hauer <s.hauer@pengutronix.de>,
Antony Pavlov <antonynpavlov@gmail.com>
Cc: barebox@lists.infradead.org
Subject: Re: [RFC 0/2] sandbox: add gpio support with libftdi1
Date: Thu, 16 Feb 2017 11:11:10 +0000 [thread overview]
Message-ID: <d7f8480d-f190-340b-b881-f59e990cad34@mev.co.uk> (raw)
In-Reply-To: <20170216073430.4hctt6wnbkfiemtk@pengutronix.de>
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@mev.co.uk> )=-
-=( Web: http://www.mev.co.uk/ )=-
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
prev parent reply other threads:[~2017-02-16 11:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 7:12 Antony Pavlov
2017-02-15 7:12 ` [RFC 1/2] sandbox: avoid symbol conflict for {open,read,close}dir Antony Pavlov
2017-02-15 7:12 ` [RFC 2/2] sandbox: add gpio support with libftdi1 Antony Pavlov
2017-02-16 7:34 ` [RFC 0/2] " Sascha Hauer
2017-02-16 8:28 ` Antony Pavlov
2017-02-16 8:25 ` Sascha Hauer
2017-02-16 11:11 ` Ian Abbott [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d7f8480d-f190-340b-b881-f59e990cad34@mev.co.uk \
--to=abbotti@mev.co.uk \
--cc=antonynpavlov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox