io-can-runtime-cfg.html

ecos3.0 beta 的官方文档,html格式

><TD
><PRE
CLASS="PROGRAMLISTING"
>    
typedef struct cyg_can_msgbox_info_st
{
    cyg_uint8 count; // number of message buffers available for this device
    cyg_uint8 free;  // number of free message buffers
} cyg_can_msgbuf_info;</PRE
></TD
></TR
></TABLE
><P
><CODE
CLASS="VARNAME"
>CYG_IO_GET_CONFIG_CAN_MSGBUF_INFO</CODE
> - If the CAN hardware supports 
more than one message buffer for reception of CAN messages (flag 
<CODE
CLASS="VARNAME"
>CYGNUM_CAN_HDI_FULLCAN</CODE
> is set while reading hardware description 
interface with <CODE
CLASS="VARNAME"
>CYG_IO_GET_CONFIG_CAN_HDI</CODE
>) then this function 
reads the number of message buffers the CAN hardware supports and the number of 
free message buffers.   </P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="TYPE"
>cyg_uint8</SPAN
> <CODE
CLASS="VARNAME"
>count</CODE
></DT
><DD
><P
>Counts the number of message buffers supported by the device.
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_uint8</SPAN
> <CODE
CLASS="VARNAME"
>free</CODE
></DT
><DD
><P
>Contains the number of free message buffers. The free message buffers are 
available for setting up remote buffers (<CODE
CLASS="VARNAME"
>CYG_IO_SET_CONFIG_CAN_REMOTE_BUF</CODE
>) 
and message filters (<CODE
CLASS="VARNAME"
>CYG_IO_SET_CONFIG_CAN_FILTER_MSG</CODE
>).
          </P
></DD
></DL
></DIV
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN9373"
>Reading state of CAN hardware</A
></H2
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    
typedef enum
{
  CYGNUM_CAN_STATE_ACTIVE,      // CAN controller active, no errors
  CYGNUM_CAN_STATE_STOPPED,     // CAN controller in stopped mode
  CYGNUM_CAN_STATE_STANDBY,     // CAN controller in Sleep mode
  CYGNUM_CAN_STATE_BUS_WARN,    // CAN controller active, warning level is reached
  CYGNUM_CAN_STATE_ERR_PASSIVE, // CAN controller went into error passive mode
  CYGNUM_CAN_STATE_BUS_OFF,     // CAN controller went into bus off mode
  CYGNUM_CAN_STATE_PHY_FAULT,   // General failure of physical layer 
  CYGNUM_CAN_STATE_PHY_H,       // Fault on CAN-H detected (Low Speed CAN)
  CYGNUM_CAN_STATE_PHY_L,       // Fault on CAN-L detected (Low Speed CAN)
} cyg_can_state;</PRE
></TD
></TR
></TABLE
><P
><CODE
CLASS="VARNAME"
>CYG_IO_GET_CONFIG_CAN_STATE</CODE
> - This function retrieves the 
present state of the CAN controller. Possible values are defined in the 
<SPAN
CLASS="TYPE"
>cyg_can_state</SPAN
> enumeration.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN9379"
>Changing mode of CAN hardware</A
></H2
><P
><CODE
CLASS="VARNAME"
>CYG_IO_SET_CONFIG_CAN_MODE</CODE
> - This function changes 
the operating mode of the CAN controller. The identifiers for the different 
operating modes are defined in the <SPAN
CLASS="TYPE"
>cyg_can_mode</SPAN
> enumeration.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
> 
typedef enum
{
  CYGNUM_CAN_MODE_STOP,   // set controller into stop mode
  CYGNUM_CAN_MODE_START,  // set controller into operational mode
  CYGNUM_CAN_MODE_STANDBY // set controller into standby / sleep mode
} cyg_can_mode;</PRE
></TD
></TR
></TABLE
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="TYPE"
>CYGNUM_CAN_MODE_STOP</SPAN
></DT
><DD
><P
>Set controller into stop mode
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>CYGNUM_CAN_MODE_START</SPAN
></DT
><DD
><P
>Set controller into operational mode
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>CYGNUM_CAN_MODE_STANDBY</SPAN
></DT
><DD
><P
>Set controller into standby / sleep mode.
          </P
></DD
></DL
></DIV
><P
>Before the hardware configuration of the device is changed, that means
if baud rate is changed or the message buffer and filter configuration
is changed, the CAN hardware should be set into stop mode and if
configuration is finished, then device should be set back into
operational mode.  Before the device is set into standby mode, the
output buffers should be flushed or drained because transmission of a
CAN message may wake up the CAN hardware. If a received message wakes
up the CAN hardware from standby mode then
a <CODE
CLASS="VARNAME"
>CYGNUM_CAN_EVENT_LEAVING_STANDBY</CODE
> event will be
inserted into receive message buffer or
the <CODE
CLASS="VARNAME"
>CYGNUM_CAN_EVENT_LEAVING_STANDBY</CODE
> flag will be
set for the message that caused wake up of CAN hardware.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN9404"
>Flush or drain buffers</A
></H2
><P
><CODE
CLASS="VARNAME"
>CYG_IO_SET_CONFIG_CAN_OUTPUT_DRAIN</CODE
> - This function
waits for any buffered output to complete. This function only
completes when there is no more data remaining to be sent to the
device.</P
><P
><CODE
CLASS="VARNAME"
>CYG_IO_SET_CONFIG_CAN_OUTPUT_FLUSH</CODE
> - This function
discards any buffered output for the device.</P
><P
><CODE
CLASS="VARNAME"
>CYG_IO_SET_CONFIG_CAN_INPUT_FLUSH</CODE
> - This function
discards any buffered input for the device.</P
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN9412"
>Configuring blocking/non-blocking calls</A
></H2
><P
>By default all calls to <CODE
CLASS="FUNCTION"
>cyg_io_read()</CODE
>
and <CODE
CLASS="FUNCTION"
>cyg_io_write()</CODE
> are blocking calls. The config
keys</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>CYG_IO_SET_CONFIG_READ_BLOCKING
CYG_IO_SET_CONFIG_WRITE_BLOCKING</PRE
></TD
></TR
></TABLE
><P
>enable switching between blocking and nonblocking calls separatly for
read and write calls.  If blocking calls are configured then the
read/write functions return only if a message was stored into TX
buffer or a event was received from RX buffer. If non-blocking calls
are enabled and there is no space in TX buffer or RX buffer is empty
then the function returns immediately
with <CODE
CLASS="VARNAME"
>-EAGAIN</CODE
>.</P
><P
>If non-blocking calls are enabled and additionally timeouts are
supported by driver, then the read/write functions wait until timeout
value is expired and then return with <CODE
CLASS="VARNAME"
>-EINTR</CODE
>.  If
the read/write operation succeeds during the timed wait then the
functions return succesfully with
<CODE
CLASS="VARNAME"
>ENOERR</CODE
>.</P
><P
>To query if <CODE
CLASS="FUNCTION"
>cyg_io_read()</CODE
>
and <CODE
CLASS="FUNCTION"
>cyg_io_write()</CODE
> are blocking or non-blocking
you can use the config keys</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>CYG_IO_GET_CONFIG_READ_BLOCKING
CYG_IO_GET_CONFIG_WRITE_BLOCKING</PRE
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN9427"
>Message buffer management</A
></H2
><P
>Full CAN controllers often support more the one message buffer. These
message buffers are often configurable for transmission or reception
of certain CAN messages or as a remote buffers.  If a CAN hardware
supports more than one message buffer then it is possible to configure
the CAN hardware to receive only CAN messages with certain identifiers
or to configure hardware support for remote buffers. If message
filtering is done by hardware, the number of received CAN messages
decreases and so also the time for processing received CAN messages
and the memory required for buffering received messages
decreases. This saves valuable memory and processing time.</P
><P
>The eCos CAN driver supports a generic way of adding message filters
or remote buffers. By default the CAN driver is configured for
reception of any kind of CAN standard and extended
frames. Configuration of message buffers is done by
calling <CODE
CLASS="FUNCTION"
>cyg_io_set_config()</CODE
> with the config key</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>CYG_IO_SET_CONFIG_CAN_MSGBUF</PRE
></TD
></TR
></TABLE
><P
>and by exchanging <SPAN
CLASS="TYPE"
>cyg_can_msgbuf_cfg</SPAN
> data structures.</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>typedef struct cyg_can_msgbox_cfg_st
{
    cyg_can_msgbuf_cfg_id cfg_id; // configuration id
    cyg_can_msgbuf_handle handle; // handle to message buffer
    cyg_can_message msg;          // CAN message - for configuration of buffer
} cyg_can_msgbuf_cfg;</PRE
></TD
></TR
></TABLE
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="TYPE"
>cyg_can_msgbuf_cfg_id</SPAN
> <CODE
CLASS="VARNAME"
>cfg_id</CODE
></DT
><DD
><P
> The <CODE
CLASS="VARNAME"
>cfg_id</CODE
> field
contains the configuration ID that tells the driver what to do with a
message buffer.
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_can_msgbuf_handle</SPAN
> <CODE
CLASS="VARNAME"
>handle</CODE
></DT
><DD
><P
>Contains a reference to a certain message buffer.
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>cyg_can_message</SPAN
> <CODE
CLASS="VARNAME"
>msg</CODE
></DT
><DD
><P
>Required for configuration of message buffer parameters.
          </P
></DD
></DL
></DIV
><P
>The following configuration identifiers are supported:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>CYGNUM_CAN_MSGBUF_RESET_ALL        // clears alle message buffers
CYGNUM_CAN_MSGBUF_RX_FILTER_ALL    // cfg driver for reception of all can messages
CYGNUM_CAN_MSGBUF_RX_FILTER_ADD    // add single message filter
CYGNUM_CAN_MSGBUF_REMOTE_BUF_ADD   // add new remote response buffer
CYGNUM_CAN_MSGBUF_REMOTE_BUF_WRITE // stores data into existing remote buffer </PRE
></TD
></TR
></TABLE
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><SPAN
CLASS="TYPE"
>CYGNUM_CAN_MSGBUF_RESET_ALL</SPAN
></DT
><DD
><P
>Clears alle message buffers - no message will be received and all remote buffers are deleted.
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>CYGNUM_CAN_MSGBUF_RX_FILTER_ALL</SPAN
></DT
><DD
><P
>Configure driver for reception of all can messages
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>CYGNUM_CAN_MSGBUF_RX_FILTER_ADD</SPAN
></DT
><DD
><P
>Add single message filter.
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>CYGNUM_CAN_MSGBUF_REMOTE_BUF_ADD</SPAN
></DT
><DD
><P
>Add new remote response buffer.
          </P
></DD
><DT
><SPAN
CLASS="TYPE"
>CYGNUM_CAN_MSGBUF_REMOTE_BUF_WRITE</SPAN
></DT
><DD
><P
>Stores data into existing remote buffer (remote buffer handle required).
          </P
></DD
></DL
></DIV
><P
>Example code for resetting all message buffers:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>cyg_can_msgbuf_cfg msgbox_cfg;

msgbox_cfg.cfg_id = CYGNUM_CAN_MSGBUF_RESET_ALL;
len = sizeof(msgbox_cfg);
if (ENOERR != cyg_io_set_config(hDrvFlexCAN,
                                CYG_IO_SET_CONFIG_CAN_MSGBUF,
                                &amp;msgbox_cfg, &amp;len))
{
    // handle configuration error
}</PRE
></TD
></TR
></TABLE
></DIV
><DIV
CLASS="SECTION"
><H2
CLASS="SECTION"
><A
NAME="AEN9486"
>Remote frame response buffer configuration</A
></H2
><P
>The remote frame is a message frame which is transmitted to request a
data frame. Some CAN hardware generates receive interrupts when a
remote transmission request arrives. Other CAN hardware, i.e.  the
Motorola FlexCAN module, does not generate any receive
interrupt. These CAN hardware chips like the FlexCAN module can be
configured to transmit a data frame automatically in response to a
remote frame. In order to support any kind of CAN hardware the eCos CAN
driver provides a generic handling of remote transmission requests.</P
><P
>The transmission of the data frame in response to a remote frame is
completely handled by the CAN driver.  If the hardware driver, like
the driver for the FlexCAN module, supports hardware message buffers,
then the response frame is automatically transmitted if a remote
transmission request with a matching ID arrives.  If a CAN hardware
does not provide hardware support for sending data frames in response
to a remote frame, then this need to be implemented in software by the
hardware device driver.</P
><P
>It is always possible to add remote response buffers. It does not
matter if the driver is configured for reception of all CAN messages
or if message filtering is used. As long as there are free message
buffers available, it is possible to add remote response buffers.</P
><P
>In order to respond to a remote frame, a remote frame response buffer
need to be initialized before a data frame can be sent in response to
a remote frame. This is achieved by by
exchanging <SPAN
CLASS="TYPE"
>cyg_can_remote_buf</SPAN
> data structures with the
driver via the <CODE
CLASS="FUNCTION"
>cyg_io_set_config()</CODE
> function using