This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: typo in i2c example in reference manual?


>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    Grant> On 2007-02-19, Bart Veer <bartv@ecoscentric.com> wrote:
    Grant> 1) The "delay" that's specified appears to be just added on
    Grant> to the intrinsic overhead of a bit-banged driver. Is this
    Grant> the Specifying a delay of 10,000ns on my platform results
    Grant> in an actual clock period of about 59,000ns. The
    Grant> description of the delay parameter in the reference manual
    Grant> appears to assume that there is zero overhead involved in
    Grant> the driver. Is this the expected behavior?
    >> 
    >> It is assumed that the bitbang function just needs to manipulate a
    >> couple of registers related to GPIO pins, which should be near enough
    >> instantaneous.

    Grant> Changing a pin state requires a single instruction on my
    Grant> platform. Still, setting the delay parameter to 0 results
    Grant> in a SCK period of 50,000ns. Setting the delay parameter to
    Grant> a non-zero value adds to that 50,000ns. [I'm running on a
    Grant> NIOS2 CPU at 44MHz.]

So apparently it takes 25us to change a pin state. Sounds like there
is a big problem somewhere.

    Grant> Right, but the reference manual implies that it does when
    Grant> it states that the delay value will be the SCK period. That
    Grant> could only be true if the overhead is either zero or is
    Grant> measured and compensated for.

On processors which have dedicated I2C bus master support (as opposed
to bitbanging GPIO lines) the delay is likely to be exact since it
will be used to set a clock register within the I2C hardware. For a
bit-banged bus the delay should be accurate to within a few percent,
which should be good enough for all practical purposes. It will not be
any more accurate than that because HAL_DELAY_US() is not expected to
be any more accurate than that. There is a reasonable assumption here
that the low-level bitbang operations are sufficiently cheap as to be
negligible.

    Grant> 2) There doesn't seem to be any way to determine when
    Grant> writing zero bytes of data with cyg_i2c_tx() whether the
    Grant> operation was successful or not, since it returns 0 for
    Grant> both cases. I presume one should use the lower-level
    Grant> "transaction" routines for this case?
    >> 
    >> Under what circumstances does it make sense to write zero bytes
    >> of data?

    Grant> The datasheet for the EEPROM I'm using states that in order
    Grant> to determine if a write cycle has completed, one should
    Grant> should send an address/control byte with the r/*w bit
    Grant> cleared. If that byte is acked, then the write cycle is
    Grant> finished. If it isn't then the write cycle is still in
    Grant> progress. I've determined that sending an extra byte after
    Grant> the control byte doesn't seem to hurt anything, but I'd
    Grant> prefer to do things according to the datasheet.

So the EEPROM will not acknowledge the address byte immediately after
the start condition. cyg_i2c_bitbang_tx() should detect this and
return immediately after the address byte, with no attempt to send the
data byte. As long as the data byte is effectively a no-op when the
write cycle has completed and the EEPROM does accept the data byte,
no harm will be done. There is a marginal inefficiency in that your
polling code ends up transmitting one unnecessary byte, and arguably
the I2C API should have allowed for this case, but I do not think it
is worth changing the API at this stage.

Bart

-- 
Bart Veer                                 eCos Configuration Architect
http://www.ecoscentric.com/               The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]