COMMUNICATIONS WITH THE MULTI- CHANNEL HOST P RT INTERFACE

Multiple Channels COMMUNICATIONS WITH THE MULTI- CHANNEL HOST P RT INTERFACE With the HPI and McHPI, applications can create a single physical channel and multiple virtual channels to provide communications among applications running on different processors By Stanford Hudson In some embedded systems, the need frequently arises for communication among applications executing on different processors. Designers typically resort to using a single-channel message distributor for that capability. However, because the message distributor must have knowledge of the applications, as well as of some of the information within the message, a new application can t be added; that is, the communications system lacks scalability a decided disadvantage. A more generic and scalable approach is to allow each application to create its own virtual communications channel or channels. The application then becomes both the distributor and the handler of messages. When a new application is installed on a processor, it may choose to add a channel so that other applications on other processors can communicate Figure 1: The scalable channel model enables applications to use their own virtual communications channels between the host processor and a DSP. The single physical channel provides a generic communications medium for the virtual channels. with it. This technique, known as multichannel communications, gives the communications system scalability (see Figure 1). A scalable channel model promotes data hiding and object orientation, since each channel is private within the system. The Multichannel Host Port Interface Model In multiprocessor systems using (at least) one member of the TMS320 DSP family, the Host Port Interface (HPI) peripheral is employed as a single physical communications channel between the host and the DSP processor. If used correctly, the HPI port can provide a generic way for applications residing on the host or the DSP to communicate with each other. Using the HPI port as a single physical channel for multiple virtual channels is made possible in turn by the Multi-Channel Host Port Interface (McHPI) channel model (see Figure 2). Various types of data transfers can be realized with this model, since each application can create multiple channels at run time. This capability can be useful in systems that require one channel for streaming data and another for command and status information. All HPI transmit and receive buffering is stored on the DSP, and each application owns its buffers. A device driver model is used for the application programming interface (API), which enables applications to manage channels at run time, as follows: extern void McHPI_Init(void); extern Uns McHPI_Open(MCHPI_CONFIG_T *cfg, Uns *channel); extern Uns McHPI_Close(Uns channel); extern Uns McHPI_Ioctl(Uns channel, Uns cmd, void *arg); extern Uns McHPI_Read(Uns channel, Uns *data, Uns *size); extern Uns McHPI_Write(Uns channel, Uns *data, Uns size); The McHPI_Init() call is issued once, at start-up, to initialize the internal structures of the McHPI subsystem. The McHPI_Open() call is issued for every virtual channel that the application requires. Each channel is assigned a unique integer that can be referenced in future calls to McHPI. A corresponding call to McHPI_Close() may be issued to close a channel. The McHPI_Ioctl() function is an optional implementation and can be used to reconfigure or to inquire about the status of the channel. The McHPI_Read() and McHPI_Write() functions enable an application to read from and write to the receive and transmit pipes. The message distributor, or application software interrupt (SWI), usually issues the McHPI_Read() call, and the main application thread issues calls to McHPI_Write() to send messages, thus: status = McHPI_Read(my_channel, (Uns *)&msg, &size); status = McHPI_Write(my_channel, (Uns *)msg, length); For a practical implementation of the McHPI model on a TMS320 DSP, you should use the DSP/BIOS realtime kernel as the operating system, since DSP/BIOS provides the necessary pipe and tasking structures to implement the model. To create a channel, each application must set up HPI transmit and receive buffers, memory flow control flags, and transmit and receive pipes. The configuration information that McHPI_Open() supplies to McHPI allows the application to specify all necessary information to open a virtual communications channel, thus: typedef struct { SWI_Obj swi; /* Application message distributor SWI */ PIP_Obj *txpipe; /* transmit pipe to host application */ 8 October 2002 Embedded Edge Embedded Edge October 2002 9

Multiple Channels Figure 2: The Multi-Channel Host Port Interface (McHPI) model enables an application to create multiple virtual channels. A device driver API is provided by the McHPI that enables the application to manage its channels at run time. DSP s transmit and receive HPI buffer and flag register are fixed at link time and are known to the corresponding host processor applications. Therefore, a similar implementation of McHPI can be achieved on the host, but with HPI flag and buffering contained on the DSP. If the host is a DSP with HPI capability, the local DSP transmit flag and buffers can be located on the host. Similarly, the host s transmit flag and buffers can be located on the local DSP. The primary thread of the McHPI implementation is the DSP/BIOS HPI hardware interrupt (HWI) handler (see the listing, page 14). The HWI is triggered by an HPI interrupt from both the host and the DSP in the case of a transmission when the transmit pipe is empty. It handles all channel pipe transfers between HPI transmit and receive buffers. One application well-suited to McHPI is a DSP-based image-processing system. Application Examples One application that s well suited to the use of McHPI is a DSP-based video image-processing system that combines both high-speed digital video data transmissions and command and status messaging to and from a host processor. The system employs two processors: a DSP that handles the math-intensive image-processing algorithms and a general-purpose processor (GPP) that manages the capture and display of digital video data as well as user input. The GPP can be an HPIenabled DSP, simplifying the architecture. In this example application, a streaming transmit and receive channel is used to transfer raw digital video data between the GPP and the DSP. Another channel is used to communicate control and status information. Control information includes image dimension configuration data, the types of image-pro- PIP_Obj *rxpipe; /* receive pipe from host application */ Ptr *txlen; /* DSP-to-host message length */ Ptr *txfr; /* DSP-to-host message available */ Ptr *rxlen; /* host-to-dsp message length */ Ptr *rxfr; /* host-to-dsp message available */ Ptr *rxbuf; /* host-to-dsp message storage buffer */ Ptr *txbuf; /* DSP-to-host message storage buffer */ Uns inuse; /* internal use only */ } MCHPI_CONFIG_T; The transmit and receive pipes must be unique for each channel that an application opens, as must be the storage areas for transmit and receive buffers and control flags. Their uniqueness is what gives the McHPI model its privacy feature and its scalability. Transmit and receive pipes allow data to move between McHPI and the application and its message distributor. They provide a queuing mechanism for the application, thus enabling multiple messages to be queued up for servicing by the single-channel physical implementation of the HPI. The physical layer of McHPI communicates via the transmit and receive buffers and uses flag registers to indicate when data is available. The host sets the RXLEN register to the number of words to be read from the receive buffer (RXBUF). A value of 1 in the receive flag register (RXFR) indicates that the host has placed data in the RXBUF. The setting of the RXFR is performed in conjunction with an HPI interrupt to the DSP from the host. When the DSP has read the data and placed it in the receive pipe, the RXFR is set to 0 and an interrupt is sent back to the host. The HPI physical layer enables both the host and DSP to read the same areas of memory. Consequently, the host may either poll the RXFR or wait for an interrupt from the DSP to determine if more data can be sent. A similar flow control process occurs for DSP-tohost transmission. The TXLEN register is set to the number of words stored in the transmit buffer (TXBUF), and the transmit flag register (TXFR) is set The transmit and receive pipes must be unique for each channel that opens. to 1 by the DSP when data is available in the TXBUF. An interrupt accompanies the setting of this flag and is followed by a host read of the TXBUF. The host is then responsible for clearing the TXFR and interrupting the DSP. As with the receive case, the DSP and host can operate in either poll or interrupt mode to transmit data. For each application channel, the addresses of the 0.5-5.0 V Faster load time through QuickLOAD technology Programmable JTAG clock High Performance USB Emulator...from the leaders in TI DSP Development Tools We also offer: ARM 28x 54x 55x 62x 64x 67x OMAP... PCI emulators with optional onboard EVM s FleXDS FleXDS 560+ TIGER DSP Development boards VIPER DSP Resource boards Design Services DSP Research, Inc. www.dspr.com information@dspr.com Phone: (408)773-1042 12 October 2002 Embedded Edge Embedded Edge October 2002 13

cessing algorithms to perform on the data, and any text to be imposed on the video image. Status information might include the number of frames processed, the coordinates that define a region of interest (movement detected), or other analytical data. Changing the Channels One channel is established for the streaming video data. Sufficient space for the HPI transmit and receive buffers is allocated so that they can store an entire video frame of data. A second channel, with small receive and transmit buffers, is established for the control and status messages. Two software interrupts (SWIs) are created on the DSP processor, one for receiving raw image data from the host and another for receiving and processing control messages. Messages and data are received via a call to McHPI_Read(). A main application task on the Various voice channels reside within the TDM frame, and each frame contains one sample of the voice signal. DSP is used to process the raw image information and calls McHPI_Write() to send the data back to the host for display. Communications processing systems also are well suited to the McHPI model. An example system involves the detection of DTMF signals in a time-division multiplexing (TDM) voice data stream that the host sends to the DSP. Various voice channels reside within the TDM frame, and each frame contains one sample of the voice signal for each channel. One McHPI virtual communications channel is set up for the streaming TDM voice data, and another channel for messages indicating what DTMF tone has been detected on each voice channel. Stanford Hudson (shudson@tekgenix.com) is a member of the technical staff at Tekgenix Corporation, a consulting and design firm located in Richardson,Texas, that specializes in DSP-based hardware and software design, analysis, and rapid prototyping. He has more than 11 years experience in real-time embedded systems architectures. (Note: Hudson is now with Paragon Innovations.) 14 October 2002 Embedded Edge

IMPORTANT NOTICE Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, modifications, enhancements, improvements, and other changes to its products and services at any time and to discontinue any product or service without notice. Customers should obtain the latest relevant information before placing orders and should verify that such information is current and complete. All products are sold subject to TI s terms and conditions of sale supplied at the time of order acknowledgment. TI warrants performance of its hardware products to the specifications applicable at the time of sale in accordance with TI s standard warranty. Testing and other quality control techniques are used to the extent TI deems necessary to support this warranty. Except where mandated by government requirements, testing of all parameters of each product is not necessarily performed. TI assumes no liability for applications assistance or customer product design. Customers are responsible for their products and applications using TI components. To minimize the risks associated with customer products and applications, customers should provide adequate design and operating safeguards. TI does not warrant or represent that any license, either express or implied, is granted under any TI patent right, copyright, mask work right, or other TI intellectual property right relating to any combination, machine, or process in which TI products or services are used. Information published by TI regarding third party products or services does not constitute a license from TI to use such products or services or a warranty or endorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of the third party, or a license from TI under the patents or other intellectual property of TI. Reproduction of information in TI data books or data sheets is permissible only if reproduction is without alteration and is accompanied by all associated warranties, conditions, limitations, and notices. Reproduction of this information with alteration is an unfair and deceptive business practice. TI is not responsible or liable for such altered documentation. Resale of TI products or services with statements different from or beyond the parameters stated by TI for that product or service voids all express and any implied warranties for the associated TI product or service and is an unfair and deceptive business practice. TI is not responsible or liable for any such statements. Mailing Address: Texas Instruments Post Office Box 655303 Dallas, Texas 75265 Copyright 2002, Texas Instruments Incorporated