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: typo in i2c example in reference manual?


On 2007-02-22, Bart Veer <bartv@ecoscentric.com> wrote:

>    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.

It sure does.  I took a look at the C++ code, and I don't see
how there could be that much overhead anywhere.

> 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.

There's got to be something wrong with my hardware platform --
not that I'd be surprised, the NIOS2 has been a giant headache
from the beginning.

> 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.

I'm also going to take a look at the HAL_DELAY_US() macro.
Altera's NIOS2 eCos port has also been the source of headaches.

>>> 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.

Correct (if it's busy).  If it's not, it will ack the address
byte and the subsequent data byte which is written into a
pointer register.

> 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.

As far as I can tell, it's effectively a noop if you follow it
with another write command to set the register back to the
desired state.  The datasheet seems quite explicit that the
address byte (either acked or not) is followed by another start
condition and then the command you actually want to execute.
But, I can't see any reason why you can't send a data byte
along with the address byte.

> 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.

Proably not.

-- 
Grant Edwards                   grante             Yow!  An Italian is COMBING
                                  at               his hair in suburban DES
                               visi.com            MOINES!


-- 
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]