Abstract: This paper discusses and compares various communication methods in the DSP/BIOS environment, and gives an example of data communication using PIP pipe objects. Finally, the paper gives some issues to note and corresponding solutions for data communication using pipe objects. Keywords : DSP/BIOS, pipe, stream I/O, host. For digital signal processing applications, data communication is crucial. In TI's DSP/BIOS environment, there are three communication methods: pipe-based communication (PIP, pipe), stream I/O-based communication (SIO, stream I/O), and host-based communication (HST, host). Each communication method is accomplished by scheduling its corresponding kernel object. DSP/BIOS provides modules and corresponding API calls to manage each communication method. Through these modules and calls, input/output (I/O) in the DSP environment can be completed. This paper briefly introduces various communication methods, compares various communication methods, and gives an example of data communication using PIP objects. 1 Introduction to Communication Methods (1) Host Communication In the host communication method, the HST object completes the communication between the host and the target machine. HST objects are statically configured as input/output, and each HST object is implemented using a data pipe object. When developing DSP applications, HST objects can be used to simulate data flow and test the processing of data by the program algorithm. In the early stages of program development, especially when testing signal processing algorithms, the program uses input channel objects to access data from the host file and output channel objects to feed back the results processed by the algorithm to the host side for verification or comparison. In the later stages of program development, when the algorithm is completed, HST objects can be changed back to PIP objects, and communication between the peripheral real data and the target application can be completed by using PIP objects. (2) Pipe Communication Pipe (PIP) objects are used to manage block I/O (also known as stream-based I/O or asynchronous I/O). Each PIP object maintains a buffer (called a frame) with a fixed number and fixed size. All I/O operations process only one frame at a time. Although the length of each frame is fixed, the application can put a variable amount of data in each frame (but cannot exceed the maximum value). The pipe has two ends, one for writing and one for reading. One end of the write thread is used to add data to the pipe, and the other end of the read thread is used to read data from the pipe. The pipe can be used to transfer data between any two threads in the program. Often, one end of the pipe is controlled by the ISR and the other end is controlled by the software interrupt function. Data notification functions (also known as callback functions) are used to synchronize data transmission, including notification read functions and notification write functions. These functions are triggered when reading or writing a frame of data to notify the program that there is a free frame or data available. (3) Stream communication A stream is a channel through which data is transferred between the application and the I/O device. The stream channel can be read-only (for input) or write-only (for output). It provides a simple and universal interface to all I/O devices, allowing the application to completely ignore the details of each device operation. An important aspect of stream I/O is its asynchronous nature. While the application is processing the current buffer, a new input buffer is being filled and the previous buffer is being output. Streams exchange pointers instead of data, which greatly reduces overhead and makes the program more responsive to real-time constraints. The Stream Module (SIO) interacts with different types of devices through drivers. The driver is managed by the DEV (Device) module. A device driver is a software module that manages a class of devices. These modules conform to a common interface (provided by DEV), so the stream function can issue ordinary requests. Figure 1 shows a schematic diagram of the interaction between the stream and the device. [IMG=Schematic diagram of the interaction between the stream and the device]/uploadpic/THESIS/2007/12/2007121214385658884C.jpg[/IMG] (4) Comparison of various communication methods DSP/BIOS supports two different data transmission models: one is the pipe model, used by the PIP and HST modules; the other is the stream model, used by the SIO and DEV modules. Both models require a pipe or stream to have one read thread and one write thread. Both models copy data by copying pointers instead of data. Generally speaking, the pipe model supports low-level communication, while the stream model supports high-level, device-independent I/O. Comparison of Communication Methods in DSP/BIOS Environment: Pipe Objects (PIP vs. HST) Stream Objects (SIO vs. DEV) Programmers must create their own drivers. Provides a more structured approach to creating device drivers. Read/write threads can be of any thread type or the host PC. One end must be handled by a task (TSK) using SIO calls, and the other end by an HWI using Dxx calls. PIP functions are non-blocking; the program must check between writing to and reading from the pipe to ensure the buffer is available. SIO_put, SIO_get, and SIO_reclaim are blocking functions (SIO_issue is non-blocking). Uses less memory, generally faster. More flexible, simpler to use. Each pipe has its own buffer. Buffers can transfer data from one stream to another without copying. Pipes must be statically configured using configuration tools. Streams can be created at runtime or statically configured using configuration tools. No built-in support for stacking devices. Provides support for stacking devices. Uses HST (implemented internally with PIP), facilitating communication between the host and target machines. DSP/BIO provides a large number of device drivers . 2. An Example of Pipe-Based Communication Based on the above analysis, an example of communication using pipes is given. This example is an example of audio processing. Data is input from the data source to the encoder, quantized, and then input to the target machine through the serial port. After the target machine processes the data, it is sent to the encoder through the serial port, and then output by the encoder through the speaker. Figure 2 shows the data flowchart. (1) Pipe design In this example, two pipes, DSS_rxPipe and DSS_txPipe, are designed. DSS_rxPipe is used for data reception, and DSS_txPipe is used for data transmission. (2) Thread design Since each pipe corresponds to one read/write thread, a total of 4 read/write threads are needed for the sending and receiving pipes. In this example, only 2 threads are designed to simplify the design. Among them, the audio processing function (designed as a software interrupt SWI) serves as both the read thread of the receiving pipe and the write thread of the sending pipe; the serial port receive interrupt service routine ISR serves as both the write thread of the receiving pipe and the read thread of the sending pipe. Each time an interrupt occurs, the serial port interrupt service routine (ISR) copies a 32-bit data word from the data receive register (DRR) to an idle frame in the data receive pipe. When a frame is full, the ISR writes the full frame to the data receive pipe (by calling PIP_put) for the pipe's read thread (i.e., the audio processing function) to read. When the audio processing function executes, it reads a full frame from the receive pipe, processes it, and then writes it to an idle frame in the transmit pipe for the pipe's read thread (i.e., the ISR) to send. Each time the ISR triggers, it reads a full frame (if any) from the transmit pipe and sends it in 32-bit words to the serial port transmit register (DXR) until all data in a frame has been sent. Then, the idle frame is returned to the transmit pipe for the audio processing function (i.e., the pipe's write thread) to use. It is important to note that since the transmit rate is the same as the receive rate in this example, the interrupt handler is responsible for both receiving and sending data, and only sends one 32-bit word each time an interrupt is executed. [IMG=Interrupt Handling Function]/uploadpic/THESIS/2007/12/20071212143904286886.jpg[/IMG] (3) Issues to Note: PIP_alloc and PIP_put are called by the write thread of the PIP object, while PIP_get and PIP_free are called by the read thread of the PIP object. This calling order is very important. Disrupting this calling order will have unpredictable consequences. Therefore, each call to PIP_alloc must be followed by a call to PIP_put before PIP_alloc can be called again; the same applies to PIP_get. In addition, to avoid recursion during PIP calls, PIP API functions should be avoided as part of the notification read/write function. If it is necessary to do so for efficiency, such calls should be protected to prevent re-entry of the same pipe object and incorrect PIP API call order. For example, at the beginning of the notification read function for the sending pipe and the notification write function for the receiving pipe, we added the following statement to avoid recursive calls: `static Int nested = 0; ... if (nested) { /* Prevent recursive calls due to calls to the PIP_get function */ return; } nested = 1.` 3. Summary Among the three communication methods provided by DSP/BIOS, PIP objects are widely used in the input/output of DSP-based application systems due to their high efficiency. However, while utilizing their convenience, we must carefully handle the writing of notification read/write functions to avoid recursive calls and disastrous consequences.