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?


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

    Grant> I tried to follow the example in the reference manual shown below:
    Grant>    Instantiating a bit-banged I2C bus requires the following:
    <snip>
    Grant>       CYG_I2C_BITBANG_BUS(&hal_alaia_i2c_bus, &hal_alaia_i2c_bitbang);
   
    Grant>    This gives a structure hal_alaia_i2c_bus which can be used when defining the
    Grant>    cyg_i2c_device structures.

    Grant> I get a syntax error unless I remove the "&" before
    Grant> hal_alaia_i2c_bus. If this macro is declaring and
    Grant> allocating (is that what "gives" means in this context?) a
    Grant> structure named "hal_alaia_i2c_bus", the "&" doesn't really
    Grant> make sense.
   
Yes, that is a typo. I'll fix it in the master docs when I get a
chance, there are a couple of other things in there that need
improving.

    Grant> I'm trying to use the i2c (with a bit-banged driver).  I've run
    Grant> into a couple glitches so far:

    Grant> 1) The "delay" that's specified appears to be just added on to
    Grant>    the intrinsic overhead of a bit-banged driver.  Is this the
    Grant>    Specifying a delay of 10,000ns on my platform results in an
    Grant>    actual clock period of about 59,000ns.  The description of
    Grant>    the delay parameter in the reference manual appears to
    Grant>    assume that there is zero overhead involved in the driver.
    Grant>    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. If for some reason the operation is more expensive,
there would be no easy way to measure that and allow for it. Hence the
specified delay is just used to generate the HAL_DELAY_US() parameter.
Developers still have some control since they fill in the delay field
when instantiating an I2C device.

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

Under what circumstances does it make sense to write zero bytes of
data?

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

    Grant> That doesn't seem to work. i2c_transaction_tx always seems
    Grant> to write an extra byte. If I tell it to send 1 byte, it
    Grant> sends 2.

    Grant> How do I send a single byte on the i2c bus??

I suspect you are setting the start flag. That means the I2C code has
to send the device address and the direction bit before the byte of
data. I2C does not have the concept of sending a raw byte of data onto
the bus. Data must always be addressed to a device on the bus, which
means sending address bytes. The address byte also includes one bit
for the direction, so that the addressed device knows whether it
should accept or transmit data.

    Grant> It will be called from both driver init() routines and from
    Grant> threads. How tell the difference so that the function can
    Grant> call HAL_DELAY_US() in the former case and
    Grant> cyg_thread_delay() in the latter?

cyg_thread_delay() generally operates in terms of many milliseconds.
Typically low-level device drivers do not deal with things on such
long timescales, instead that is left to higher-level code or the
application. Instead typical device drivers need delays of the order
of microseconds, which always requires HAL_DELAY_US() rather than
cyg_thread_delay().

If there is a valid reason for having milliseconds of delay inside
driver code, the best bet is to check whether or not interrupts are
enabled. Typically that does not happen until the scheduler is started
and threads begin to run.

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]