Software Drivers

can v3_0

The Xilinx CAN driver. This driver supports the Xilinx CAN Controller.

The CAN Controller supports the following features:

The device driver supports all the features listed above, if applicable.

Driver Description

The device driver enables higher layer software (e.g., an application) to communicate to the CAN. The driver handles transmission and reception of CAN frames, as well as configuration of the controller. The driver is simply a pass-through mechanism between a protocol stack and the CAN. A single device driver can support multiple CANs.

Since the driver is a simple pass-through mechanism between a protocol stack and the CAN, no assembly or disassembly of CAN frames is done at the driver-level. This assumes that the protocol stack passes a correctly formatted CAN frame to the driver for transmission, and that the driver does not validate the contents of an incoming frame

Operation Modes

The CAN controller supports the following modes of operation:

Buffer Alignment

It is important to note that frame buffers passed to the driver must be 32-bit aligned.

Receive Address Filtering

The device can be set to accept frames whose Identifiers match any of up to 4 filters set in the Acceptance Filter Mask/ID registers.

The incoming Identifier is masked with the bits in the Acceptance Filter Mask Register. This value is compared with the result of masking the bits in the Acceptance Filter ID Register with the Acceptance Filter Mask Register. If both these values are equal, the message will be stored in the RX FIFO.

Acceptance Filtering is performed by each of the defined acceptance filters. If the incoming identifier passes through any acceptance filter then the frame is stored in the RX FIFO.

PHY Communication

This driver does not provide any mechanism for directly programming PHY.

Interrupts

The driver has no dependencies on the interrupt controller. The driver provides an interrupt handler. User of this driver needs to provide callback functions. An interrupt handler example is available with the driver.

Virtual Memory

This driver supports Virtual Memory. The RTOS is responsible for calculating the correct device base address in Virtual Memory space and invoking function XCan_VmInitialize(), instead of XCan_Initialize(), to initialize the device at first.

Threads

This driver is not thread safe. Any needs for threads or thread mutual exclusion must be satisfied by the layer above this driver.

Device Reset

Bus Off interrupt that can occur in the device requires a device reset. The user is responsible for resetting the device and re-configuring it based on its needs (the driver does not save the current configuration). When integrating into an RTOS, these reset and re-configure obligations are taken care of by the OS adapter software if it exists for that RTOS.

Device Configuration

The device can be configured in various ways during the FPGA implementation process. Configuration parameters are stored in the xcan_g.c files. A table is defined where each entry contains configuration information for a CAN device. This information includes such things as the base address of the memory-mapped device, and the number of acceptance filters.

Asserts

Asserts are used within all Xilinx drivers to enforce constraints on argument values. Asserts can be turned off on a system-wide basis by defining, at compile time, the NDEBUG identifier. By default, asserts are turned on and it is recommended that users leave asserts on during development.

Building the driver

The XCan driver is composed of several source files. This allows the user to build and link only those parts of the driver that are necessary.

 Temp Change
 MODIFICATION HISTORY:
 Ver   Who  Date     Changes
 ----- ---- -------- -------------------------------------------------------
 1.00a xd   04/12/05 First release
 1.10a mta  05/13/07 Updated to new coding style
 1.11a sdm  08/22/08 Removed support for static interrupt handlers from the MDD
		      file
 2.00a ktn  10/22/09 Updated driver to use the HAL APIs/macros.
		      The macros have been renamed to remove _m from the name in
		      all the driver files.
 3.0   adk  19/12/13 Updated as per the New Tcl API's