Xilinx provides standalone mode drivers for all devices. The Xilinx SDK will add the drivers of the devices used to the created BSP project according to the configuration of the hardware system.
The storage path of the Xilinx device driver is in the sw directory under the installation directory. With Vivado 2013.4, the relative path to the driver is \SDK\2013.4\sw\XilinxProcessorIPLib\drivers\. The src directory stores the driver, and the examples directory stores the use case code.
For a device, the hardware information necessary for the driver has the base address of the device, the clock, the middle segment, and so on. The Xilinx driver also assigns a device number to each device. This information is defined in Xparameters_ps.h, generally using the following names, MOD_DEVICE_ID, MOD _BASEADDR, MOD _CLOCK_HZ, MOD _INTR, MOD _INT_ID. Xparameters_ps.h is automatically generated by the SDK based on hardware engineering.
Xilinx drivers mainly have the following files: mod.c, mod_g.c, mod_hw.c, mod_opTIons.c, mod_selftest.c, mod_sinit.c, mod.h, mod_hw.h; some drivers also have mod_intr.c. The mod represents the specific device name.
The driver mainly uses two data structures, all defined in the file mod.h. mod_Config is mainly used to pass the hardware information he needs to the driver. The hardware information data structure of Zynq's SPI device.
Typedef struct {
U16 DeviceId; /**< Unique ID of device */
U32 BaseAddress; /**< Base address of the device */
U32 InputClockHz; /**< Input clock frequency */
} XSpiPs_Config;
Another data structure is named after the module name, and contains information needed during the running of the driver, such as whether it is ready, busy or not, and even the buffer address for sending and receiving data. Driver data structure for Zynq's SPI device.
Typedef struct {
XSpiPs_Config Config; /**< ConfiguraTIon structure */
U32 IsReady; /**< Device is iniTIalized and ready */
U8 *SendBufferPtr; /**< Buffer to send (state) */
U8 *RecvBufferPtr; /**< Buffer to receive (state) */
Unsigned RequestedBytes; /**< Number of bytes to transfer (state) */
Unsigned RemainingBytes; /**< Number of bytes left to transfer(state) */
U32 IsBusy; /**< A transfer is in progress (state) */
U32 SlaveSelect; /**< The slave select value when
XSPIPS_FORCE_SSELECT_OPTION is set */
XSpiPs_StatusHandler StatusHandler;
Void *StatusRef; /**< Callback reference for status handler */
} XSpiPs;
Mod_g.c mainly defines a global variable that provides the driver with hardware information about the device. For example, the Xspips_g.c file of Zynq's SPI device is mainly defined by the following variables. The macros are all defined in Xparameters_ps.h. This file is automatically generated by the SDK based on hardware engineering.
XSpiPs_Config XSpiPs_ConfigTable[XPAR_XSPIPS_NUM_INSTANCES] = {
{
XPAR_XSPIPS_0_DEVICE_ID, /* Device ID for instance */
XPAR_XSPIPS_0_BASEADDR, /* Device base address */
XPAR_XSPIPS_0_CLOCK_HZ
},
{
XPAR_XSPIPS_1_DEVICE_ID, /* Device ID for instance */
XPAR_XSPIPS_1_BASEADDR, /* Device base address */
XPAR_XSPIPS_1_CLOCK_HZ
}
};
Mod_sinit.c completes the initialization of the device hardware information. It has an XSpiPs_LookupConfig() function that looks up the corresponding hardware information based on the device number. Most of the code for this driver can support multiple devices. Device hardware initialization function for Zynq's SPI device:
XSpiPs_Config *XSpiPs_LookupConfig(u16 DeviceId)
{
XSpiPs_Config *CfgPtr = NULL;
Int Index;
For (Index = 0; Index < XPAR_XSPIPS_NUM_INSTANCES; Index++) {
If (XSpiPs_ConfigTable[Index].DeviceId == DeviceId) {
CfgPtr = &XSpiPs_ConfigTable[Index];
Break;
}
}
Return CfgPtr;
}
Mod_hw.h is mainly used to define hardware register information, such as offset address, the function of each bit of the register. It also comes with an implementation of a macro that handles the main register operations.
Mod_hw.c is mainly used to implement the reset function of the device. Other underlying functions, if they are not related to interrupts, etc., may be placed here, such as the transceiver function of a serial device, in this file. This file is usually small and has few functions.
Mod_selftest.c is used to implement the self-test function.
Mod_intr.c is used to implement interrupt-related functions. See Xuartps_intr.c.
The driver's external interface is implemented in mod.c. Other functions that do not have special files are usually placed in this file. The mod_CfgInitialize( ) used for initialization is also implemented in this function. Other common transceiving functions and the like are generally also placed in this file. Mod.h implements macros that other modules may use and declares functions implemented in mod.c.
The drivers for all devices are used in a similar way. The first step is to call mod_LookupConfig( ) with the device ID to query the device information. The second step is to use the device information to call mod_CfgInitialize( ) to initialize the device, which will usually set the default working state. After this step, the device hardware should be in a ready state. The third step is to call mod_SelfTest() to do a self-test on the device. These three steps generally need to be completed. Next, you can do some device-related settings for the most devices, such as setting the baud rate of the serial port. Then the device enters the working state and can perform normal service.
Some customers use Linux. Standalone mode is a scenario without an operating system. However, if the device's address space is mapped to user space, the standalone mode driver can also be used directly as a Linux user space driver. Specific code, you can refer to the UG873 operating CDMA device code. There is no Xparameters_ps.h file automatically generated by the SDK. Users need to create a header file to provide the base address, clock, mid-range number and other hardware information required by mod_g.c.
Uv Curving Glass,Tempered Glass Screen Protector,Film Cutting Machine,Uv Curing Protector Screen
Shenzhen TUOLI Electronic Technology Co., Ltd. , https://www.szhydrogelprotector.com