Software Drivers
mbox v1_00_a
The Xilinx mailbox driver. This driver supports the Xilinx Mailbox device. More detailed description of the driver operation can be found in the xmbox.c file.
- The Xilinx Mailbox is intended to be used as a bi-directional communication core between a pair of processors. The mailbox API shall allow software to send messages in a FIFO fashion, where the receiver is intended to be software on another processor.
- The mailbox implementation provides for a way to "send" and "receive" in an atomic fashion using seperate FIFOs in the mailbox core.
- The API itself does not stop the use case where there is more than one sender on the transmit side and more than one receiver on the receiving side (just like TCP/IP sockets). However, unless there is a protocol implemented in the messages being transferred, it is typically good practice to assign just one transmit processor and one receiver processor to a single mailbox.
- The API provides for both blocking and non-blocking semantics on the send and receive operations.
Initialization & Configuration
The XMbox_Config structure is used by the driver to configure itself. This configuration structure is typically created by the tool-chain based on HW build properties.
- XMbox_LookupConfig(DeviceId) - Use the device identifier to find the static configuration structure defined in XMbox_g.c. This is setup by the tools. For some operating systems the config structure will be initialized by the software and this call is not needed. This function returns the CfgPtr argument used by the CfgInitialize function described below.
- XMbox_CfgInitialize(InstancePtr, CfgPtr, EffectiveAddress) - Uses a configuration structure provided by the caller. If running in a system with address translation, the provided virtual memory base address replaces the physical address present in the configuration structure. The EffectiveAddress argument is required regardless of operating system environment, i.e. in standalone, CfgPtr->BaseAddress is recommended, not the xparameters.h #define.
Interrupts and Asynchronous Callbacks
The driver has no dependencies on the interrupt controller. The hardware has two interrupt outputs, one for each of the attached processors. These interrupt lines cannot be controlled from the software interface so there is no functionality associated with interrupts included with the driver. The user can create a handler to field the interrupts generated by the mailbox IP. The interrupt is generated when there is data available on the processors interface so a call to _Read(...) to read the data and put it into the appropriate buffer is all that is needed.
Using the Blocking version of the Read function is not recommended since the processor will hang until the requested length is received, which might be quite a long time.
- Note:
This driver is intended to be RTOS and processor independent. It works with physical addresses only. Any needs for dynamic memory management, threads or thread mutual exclusion, virtual memory, or cache control must be satisfied by the layer above this driver.
Possible Optimization technique: If the interface for the hardware is only expected to be the memory mapped or the FSL interface for the lifetime of the project, it is reasonable to remove the other, unused, leg through the functions which allow access to the other interface method, i.e. if FSL is the only available interface the memory mapped clause in the if statements can be removed improving the performance some due to the lack of the test and branch.
MODIFICATION HISTORY:
Ver Who Date Changes
----- ---- -------- -----------------------------------------------
1.00a va First release
1.00a ecm 06/01/07 Cleanup, new coding standard, check into XCS
Converted to new XPS hardware.
Copyright © 1995-2008 Xilinx, Inc. All rights reserved.