i2c-api.html

来自「ecos3.0 beta 的官方文档,html格式」· HTML 代码 · 共 756 行 · 第 1/2 页

<CODE
CLASS="FUNCTION"
>cyg_i2c_transaction_stop</CODE
>. Code should ensure that
a stop condition has been generated by the end of a transaction.
    </P
><P
>Once the transaction is complete
<CODE
CLASS="FUNCTION"
>cyg_i2c_transaction_end</CODE
> should be called. This
unlocks the bus, allowing other threads to perform I2C I/O to devices
on the same bus.
    </P
><P
>As an example consider reading the registers in an FS6377 programmable
clock generator. The first step is to write a byte 0 to the device,
setting the current register to 0. Then a repeated start condition
should be generated and it is possible to read the 16 byte-wide
registers, starting with the current one. Typical code for this might
look like:
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    cyg_uint8  tx_data[1];
    cyg_uint8  rx_data[16];

    cyg_i2c_transaction_begin(&amp;hal_alaia_i2c_fs6377);
    tx_data[0] = 0x00;
    cyg_i2c_transaction_tx(&amp;hal_alaia_i2c_fs6377,
                           true, tx_data, 1, false);
    cyg_i2c_transaction_rx(&amp;hal_alaia_i2c_fs6377,
                           true, rx_data, 16, true, true);
    cyg_i2c_transaction_end(&amp;hal_alaia_i2c_fs6377);
    </PRE
></TD
></TR
></TABLE
><P
>Here <CODE
CLASS="VARNAME"
>hal_alaia_i2c_fs6377</CODE
> is a
<CODE
CLASS="STRUCTNAME"
>cyg_i2c_device</CODE
> structure provided by the
platform HAL. A transaction is begun, locking the bus. Then there is a
transmit for a single byte. This transmit involves generating a start
condition and sending the address and direction bit, but not a stop
condition. Next there is a receive for 16 bytes. This also involves a
start condition, which the device will interpret as a repeated start
because it has not yet seen a stop. The start condition will be
followed by the address and direction bit, and then the device will
start transmitting the register contents. Once all 16 bytes have been
received the rx routine will send a nack rather than an ack, halting
the transfer, and then a stop condition is generated. Finally the
transaction is ended, unlocking the bus.
    </P
><P
>The arguments to <CODE
CLASS="FUNCTION"
>cyg_i2c_transaction_tx</CODE
> are as
follows:
    </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="TYPE"
>const cyg_i2c_device*</SPAN
> <CODE
CLASS="VARNAME"
>device</CODE
></DT
><DD
><P
>This identifies the I2C device that should be used.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_bool</SPAN
> <CODE
CLASS="VARNAME"
>send_start</CODE
></DT
><DD
><P
>If true, generate a start condition and send the address and direction
bit. If false, skip those steps and go straight to transmitting the
actual data. The latter can be useful if the data to be transmitted is
spread over several buffers. The first tx call will involve generating
the start condition but subsequent tx calls can skip this and just
continue from the previous one.
        </P
><P
><CODE
CLASS="VARNAME"
>send_start</CODE
> must be true if the tx call is the first
operation in a transaction, or if the previous call was an rx or stop.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>const cyg_uint8*</SPAN
> <CODE
CLASS="VARNAME"
>tx_data</CODE
>, <SPAN
CLASS="TYPE"
>cyg_uint32</SPAN
> <CODE
CLASS="VARNAME"
>count</CODE
></DT
><DD
><P
>These arguments specify the data to be transmitted to the device.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_bool</SPAN
> <CODE
CLASS="VARNAME"
>send_stop</CODE
></DT
><DD
><P
>If true, generate a stop condition at the end of the transmit. Usually
this is done only if the transmit is the last operation in a
transaction.
        </P
></DD
></DL
></DIV
><P
>The arguments to <CODE
CLASS="FUNCTION"
>cyg_i2c_transaction_rx</CODE
> are as
follows:
    </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="TYPE"
>const cyg_i2c_device*</SPAN
> <CODE
CLASS="VARNAME"
>device</CODE
></DT
><DD
><P
>This identifies the I2C device that should be used.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_bool</SPAN
> <CODE
CLASS="VARNAME"
>send_start</CODE
></DT
><DD
><P
>If true, generate a start condition and send the address and direction
bit. If false, skip those steps and go straight to receiving the
actual data. The latter can be useful if the incoming data should be
spread over several buffers. The first rx call will involve generating
the start condition but subsequent rx calls can skip this and just
continue from the previous one. Another use is for devices which can
send variable length data, consisting of an initial length and then
the actual data. The first rx will involve generating the start
condition and reading the length, a subsequent rx will then just read
the data.
        </P
><P
><CODE
CLASS="VARNAME"
>send_start</CODE
> must be true if the rx call is the first
operation in a transaction, if the previous call was a tx or stop, or
if the previous call was an an rx and the <CODE
CLASS="VARNAME"
>send_nack</CODE
>
flag was set.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_uint8*</SPAN
> <CODE
CLASS="VARNAME"
>rx_data</CODE
>, <SPAN
CLASS="TYPE"
>cyg_uint32</SPAN
> <CODE
CLASS="VARNAME"
>count</CODE
></DT
><DD
><P
>These arguments specify how much data should be received and where it
should be placed.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_bool</SPAN
> <CODE
CLASS="VARNAME"
>send_nack</CODE
></DT
><DD
><P
>If true generate a nack instead of an ack for the last byte received.
This causes the slave to end its transmit. The next operation should
either involve a repeated start or a stop.
<CODE
CLASS="VARNAME"
>send_nack</CODE
> should be set to false only if
<CODE
CLASS="VARNAME"
>send_stop</CODE
> is also false, the next operation will be
another rx, and that rx does not specify <CODE
CLASS="VARNAME"
>send_start</CODE
>.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_bool</SPAN
> <CODE
CLASS="VARNAME"
>send_stop</CODE
></DT
><DD
><P
>If true, generate a stop condition at the end of the transmit. Usually
this is done only if the transmit is the last operation in a
transaction.
        </P
></DD
></DL
></DIV
><P
>The final transaction-oriented function is
<CODE
CLASS="FUNCTION"
>cyg_i2c_transaction_stop</CODE
>. This just generates a
stop condition. It should be used if the previous operation was a tx
or rx that, for some reason, did not set the
<CODE
CLASS="VARNAME"
>send_stop</CODE
> flag. A stop condition must be generated
before the transaction is ended.
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="I2C-API-INITIALIZATION"
></A
><H2
>Initialization</H2
><P
>The generic package <CODE
CLASS="VARNAME"
>CYGPKG_IO_I2C</CODE
> arranges for all
I2C bus devices to be initialized via a single prioritized C++ static
constructor. This constructor will run early on during system startup,
before any application code, with priority
<TT
CLASS="LITERAL"
>CYG_INIT_BUS_I2C</TT
>. Other code should not try to
access any of the I2C devices until after the buses have been
initialized.
    </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="i2c.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="i2c-porting.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Overview</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="io-i2c.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Porting to New Hardware</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>