📄 i2c-porting.html

📁 ecos3.0 beta 的官方文档,html格式
💻 HTML
📖 第 1 页 / 共 2 页
字号:
12 下一页
<!-- Copyright (C) 2009 Free Software Foundation, Inc.                                -->
<!-- This material may be distributed only subject to the terms      -->
<!-- and conditions set forth in the Open Publication License, v1.0  -->
<!-- or later (the latest version is presently available at          -->
<!-- http://www.opencontent.org/openpub/).                           -->
<!-- Distribution of the work or derivative of the work in any       -->
<!-- standard (paper) book form is prohibited unless prior           -->
<!-- permission is obtained from the copyright holder.               -->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Porting to New Hardware</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REL="HOME"
TITLE="eCos Reference Manual"
HREF="ecos-ref.html"><LINK
REL="UP"
TITLE="I2C Support"
HREF="io-i2c.html"><LINK
REL="PREVIOUS"
TITLE="I2C Interface"
HREF="i2c-api.html"><LINK
REL="NEXT"
TITLE="CAN Support"
HREF="io-can.html"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>eCos Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="i2c-api.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="io-can.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
><A
NAME="I2C-PORTING"
></A
>Porting to New Hardware</H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN8830"
></A
><H2
>Name</H2
>Porting&nbsp;--&nbsp;Adding I2C support to new hardware</DIV
><DIV
CLASS="REFSECT1"
><A
NAME="I2C-PORTING-DESCRIPTION"
></A
><H2
>Description</H2
><P
>Adding I2C support to an eCos port involves a number of steps. The
generic I2C package <CODE
CLASS="VARNAME"
>CYGPKG_IO_I2C</CODE
> should be
included in the appropriate <SPAN
CLASS="DATABASE"
>ecos.db</SPAN
> target entry
or entries. Next <CODE
CLASS="STRUCTNAME"
>cyg_i2c_device</CODE
> structures
should be provided for every device on the bus. Usually this is the
responsibility of the platform HAL. In the case of development boards
where the I2C SDA and SCL lines are accessible via an expansion
connector, more devices may have been added and it will be the
application's responsibility to provide the structures. Finally
there is a need for one or more <CODE
CLASS="STRUCTNAME"
>cyg_i2c_bus</CODE
>
structures. Amongst other things these structures provide functions
for actually driving the bus. If the processor has dedicated I2C
hardware then this structure will usually be provided by a device
driver package. If the bus is implemented by bit-banging then the bus
structure will usually be provided by the platform HAL.
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="I2C-PORTING-DEVICES"
></A
><H2
>Adding a Device</H2
><P
>The eCos I2C API works in terms of
<CODE
CLASS="STRUCTNAME"
>cyg_i2c_device</CODE
> structures, and these provide
the information needed to access the hardware. A
<CODE
CLASS="STRUCTNAME"
>cyg_i2c_device</CODE
> structure contains the
following fields:
    </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="TYPE"
>cyg_i2c_bus*</SPAN
> <CODE
CLASS="VARNAME"
>i2c_bus</CODE
></DT
><DD
><P
>This specifies the bus which the slave device is connected to. Most
boards will only have a single I2C bus, but multiple buses are possible.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_uint16</SPAN
> <CODE
CLASS="VARNAME"
>i2c_address</CODE
></DT
><DD
><P
>For most devices this will be the 7-bit I2C address the device will
respond to. There is room for future expansion, for example to support
10-bit addresses.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_uint16</SPAN
> <CODE
CLASS="VARNAME"
>i2c_flags</CODE
></DT
><DD
><P
>This field is not used at present. It exists for future expansion, for
example to allow for fast mode or high-speed mode, and incidentally
pads the structure to a 32-bit boundary.
        </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_uint32</SPAN
> <CODE
CLASS="VARNAME"
>i2c_delay</CODE
></DT
><DD
><P
>This holds the clock period which should be used when interacting with
the device, in nanoseconds. Usually this will be 10000 ns,
corresponding to a 100KHz clock, and the header <TT
CLASS="FILENAME"
>cyg/io/i2c.h</TT
> provides a
<TT
CLASS="LITERAL"
>#define</TT
> <CODE
CLASS="VARNAME"
>CYG_I2C_DEFAULT_DELAY</CODE
>
for this. Sometimes it may be desirable to use a slower clock, for
example to reduce noise problems.
        </P
></DD
></DL
></DIV
><P
>The normal way to instantiate a <CODE
CLASS="VARNAME"
>cyg_i2c_device</CODE
>
structure uses the <CODE
CLASS="FUNCTION"
>CYG_I2C_DEVICE</CODE
> macro, also
provided by <TT
CLASS="FILENAME"
>cyg/io/i2c.h</TT
>:
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>#include &lt;cyg/io/i2c.h&gt;

CYG_I2C_DEVICE(cyg_i2c_wallclock_ds1307,
               &amp;hal_alaia_i2c_bus,
               0x68,
               0x00,
               CYG_I2C_DEFAULT_DELAY);

CYG_I2C_DEVICE(hal_alaia_i2c_fs6377,
               &amp;hal_alaia_i2c_bus,
               0x58,
               0x00,
               CYG_I2C_DEFAULT_DELAY);
    </PRE
></TD
></TR
></TABLE
><P
>The arguments to the macro are the variable name, an I2C bus pointer,
the device address, the flags field, and the delay field. The above
code fragment defines two I2C device variables,
<CODE
CLASS="VARNAME"
>cyg_i2c_wallclock_ds1307</CODE
> and
<CODE
CLASS="VARNAME"
>hal_alaia_i2c_fs6377</CODE
>, which can be used for the
first argument to the <TT
CLASS="LITERAL"
>cyg_i2c_</TT
> functions. Both
devices are on the same bus. The device addresses are 0x68 and 0x58
respectively, and the devices do not have any special requirements.
    </P
><P
>When the platform HAL provides these structures it should also export
them for use by the application and other packages. Usually this
involves an entry in <TT
CLASS="FILENAME"
>cyg/hal/plf_io.h</TT
>, which gets included
automatically via one of the main exported HAL header files <TT
CLASS="FILENAME"
>cyg/hal/hal_io.h</TT
>. Unfortunately
exporting the structures directly can be problematical because of
circular dependencies between the I2C header and the HAL headers.
Instead the platform HAL should define a macro
<CODE
CLASS="VARNAME"
>HAL_I2C_EXPORTED_DEVICES</CODE
>: 
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
># define HAL_I2C_EXPORTED_DEVICES                                   \
    extern cyg_i2c_bus                  hal_alaia_i2c_bus;          \
    extern cyg_i2c_device               cyg_i2c_wallclock_ds1307;   \
    extern cyg_i2c_device               hal_alaia_i2c_fs6377;
    </PRE
></TD
></TR
></TABLE
><P
>This macro gets expanded automatically by <TT
CLASS="FILENAME"
>cyg/io/i2c.h</TT
> once the data structures
themselves have been defined, so application code can just include
that header and all the buses and devices will be properly exported
and usable.
    </P
><P
>There is no single convention for naming the I2C devices. If the
device will be used by some other package then typically that
specifies the name that should be used. For example the DS1307
wallclock driver expects the I2C device to be called
<CODE
CLASS="VARNAME"
>cyg_i2c_wallclock_ds1307</CODE
>, so failing to observe
that convention will lead to compile-time and link-time errors. If the
device will not be used by any other package then it is up to the
platform HAL to select the name, and as long as reasonable care is
taken to avoid name space pollution the exact name does not matter.
    </P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="I2C-PORTING-BITBANG"
></A
><H2
>Bit-banged Bus</H2
><P
>Some processors come with dedicated I2C hardware. On other hardware
the I2C bus involves simply connecting some GPIO pins to the SCL and
SDA lines and then using software to implement the I2C protocol. This
is usually referred to as bit-banging the bus. The generic I2C package
<CODE
CLASS="VARNAME"
>CYGPKG_IO_I2C</CODE
> provides the main code for a
bit-banged implementation, requiring one platform-specific function
that does the actual GPIO pin manipulation. This function is usually
hardware-specific because different boards will use different pins for
the I2C bus, so typically it is left to the platform HAL to provide
this function and instantiate the I2C bus object. There is no point in
creating a separate package for this because the code cannot be
re-used for other platforms.
    </P
><P
>Instantiating a bit-banged I2C bus requires the following:
    </P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>#include &lt;cyg/io/i2c.h&gt;

static cyg_bool
hal_alaia_i2c_bitbang(cyg_i2c_bus* bus, cyg_i2c_bitbang_op op)
{
    cyg_bool result    = 0;
    switch(op) {
        &#8230;
    }
12 下一页
⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -