I/O device driver programming technology in DSP/BIOS

    Abstract: This article introduces the writing of I/O device driver in DSP/BIOS, and gives an example of developing a voice processing program on TMS320C5402 DSK.

    Keywords: digital signal processor (DSP) real-time operating system I/O device driver application program interface (API)

In recent years, with the rapid development of information technology, DSP has been widely used in aviation, aerospace, radar, communications, consumer electronics equipment, etc.; at the same time, the computing power of DSP has become larger and more powerful. TI's newly launched TMS320C6400 The computing power of the series can reach 8800MIPS. These require the development of DSP applications to shorten the development time and increase the compilability and reusability of the software. Applications in speech compression, speech recognition, image processing, etc. require the development of DSP to be as simple as possible, and also require high code execution efficiency.

DSP/BIOS is a real-time operating system launched by TI. DSP/BIOS is integrated with TI's CCS (Code Composer Studio). The latest version is DSP/BIOS II in CCS 1.2. Using DSP/BIOS can greatly simplify the development and debugging of DSP applications. The I/O interface with external devices is an indispensable and important part in DSP application development. The I/O device driver based on DSP/BIOS separates software from hardware, improves software reusability, and minimizes mutual impact when software or hardware is modified.

1 Introduction to DSP/BISO operating system

DSP/BIOS is actually a collection of system module APIs that can be called repeatedly. It only takes up very few resources of the DSP and can meet the debugging performance analysis of the DSP during real-time operation and write efficient programs. For example, running the printf() function on TMS320C6211 takes 4000 cycles, while running LOG_printf() only takes 36 cycles. However, printf() takes more than 100 times more time than LOG_pfrintf(). The following only briefly introduces the modules related to I/O device drivers.

1.1 Task scheduling module (HWI/SWI/TSK)

In DSP/BIOS, task scheduling is implemented through three modules: HWI, SWI and TSK. HWI (Hardware Interrupt Management Module) manages hardware interrupts and is mainly responsible for the interaction between DSP and peripherals, and reading and writing data from peripherals. Since hardware interrupts deal directly with the hardware, the corresponding interrupt service routine ISR should be as short and precise as possible. HWI does not cause task scheduling. It calls SWI_post() after processing the input and output of data to schedule the corresponding software interrupt SWI to complete the data processing work.

DSP/BIOS provides two types of priority threads: SWI (software interrupt management module) and TSK (task management module). SWI is the core of DSP/BIOS task scheduling. SWI tasks are preemptive, that is, high-priority tasks can preempt low-priority tasks. However, SWI tasks are non-blockable. All SWI tasks share a stack. SWI tasks can only be predefined during programming. The dynamic generation of tasks and support for blocking states in DSP/BIOS are implemented through the TSK module. TSK can also be intercepted, but each TSK task uses an independent stack.

1.2 Communication module (PIP/SIO)

PIP (buffered pipe management module) and SIO (stream input and output management module) are two interface objects provided by DSP/BIOS to support data exchange between DSP and peripherals. The PIP object has a buffer queue that can perform buffered read tasks and write tasks. SIO does not have a buffer queue. The SIO operations get() and put() exchange buffer pointers between the application and the driver instead of copying the data, so the execution efficiency is higher than PIP.

PIP and SIO objects support the implementation of frame-based signal processing systems. In multi-rate systems, priority threads are needed to unify port communications. In other systems that need to process frames of different sizes and rates, priority threads are also necessary. PIP objects can be used by SWI or TSK threads, while SIO objects can only be used by TSK.

2 Low-level device driver (LIO)

LIO (Low Level I/O) is a set of API functions designed based on DSP/BIOS. It consists of control functions, I/O buffer management functions, and signaling functions, as shown in Table 1. Applications can control one or more peripheral channels through LIO functions.

Table 1 LIO API functions

LIO functions do not consider the direction of data transfer, which means that only output devices, only input devices, and devices that can perform input and output execute the same function. The main difference between input and output is the meaning of the parameters passed to the buffer queue function. Since all other operations are equal, most control code can be shared by all channels in a single driver.

2.1 Overall design, vision and naming convention

All driver functions cannot be set as global interrupts. The driver should not affect the status of the global interrupt enable flag, but only the status of the enable flag corresponding to the interrupt that can be triggered by the peripheral device it controls. This prevents one driver from competing with other drivers or applications for CPU resources.

To avoid namespace conflicts caused by different drivers using the same function name, and to change the driver without recompiling the application code, driver functions can be accessed through the function table. This way, only one external symbol needs to be defined per driver. This symbol has its naming convention. This naming convention distinguishes by terminal blocks, on-chip peripherals, LIO interfaces, etc. For example, the source code containing application notes is that the AD50 audio codec of TI TMS320VC5402 DSK implements a DMA-based driver, and the driver function table name is DSK5402_DMA_AD50_TI_ILIO.

Each half-duplex (input or output) channel supported by the device driver. Each function corresponds to a channel variable. A physical device capable of performing input and output, such as a DSP serial port connected to an audio codec, accessible through two half-duplex channels (one input, one output). How many physical devices and channels a driver supports is implementation-specific. Generally, a driver should be able to control a physical device, which may have multiple channels. The mapping of channel numbers to physical device channels is determined at execution time. The channel number should be agreed to start from 0. For I/O devices, it is generally agreed that even numbers are inputs and odd numbers are outputs.

2.2 Three types of functions

There are three types of functions in the LIO interface: control functions, buffer and queue management functions, and signaling functions.

2.2.1 Control function

Control functions are used to start, shut down and control the device. Its initial function saves resources (physical peripherals and memory) for the driver. It uses a structure pointer as an optional variable. This structure is a device-specific variable structure.

2.2.2 Queue management

It is assumed that each device has at least one buffer used to transfer data. Many devices (such as McBSP and DMA) come with buffer queues that allow double buffering. Figure 1 is a LIO driver with three storage units. The driver has: the "todevice" (to-device) queue of buffers filled or emptied by the peripheral, and the transferred buffer is returned to the application's buffer management The program's "from device" queue and the buffer in which data is currently being transferred. The ones in the dotted box are considered to be in the driver. The buffer of currently transmitted data is generally controlled by peripheral registers, such as DMA source registers or destination registers, which are drawn in "Peripherals" in Figure 1. Devices that contain hardware queues (such as DMA reload registers) will also contain one or more storage units with storage pointers for subsequent transfers. This queue is the "to device" queue. The third storage location that can contain buffer pointers is the "from device" queue, which is a variable in the driver. When the device prepares to transmit a buffer, the buffer is transferred from the input queue to the peripheral register. These buffers are then moved to the output queue to complete transfers in response to CPU interrupts.

PutBuf() transfers a buffer from the application to the driver's input queue. GetBuf() gets the buffer from the output queue. IsEmpty() and IsFull() return the status of the input queue and output queue. If the input queue is full, calling putBuf() will return an error code because there is no room for a new buffer. If IsFull() returns false, putBuf() can be called next. If IsFull() returns true, the call to putBuf() may also succeed if the transfer is completed between the time IsFull() returns true and the call to putBuf().

2.2.3 Signaling

As shown in Figure 1, when the transfer ends, a CPU interrupt is generally triggered. This interrupt causes the application to transfer the transferred buffer to the output queue and then call calback() to pass it to the driver. Callback() should signal the application that the transfer is complete.

3 LIO driver examples

Audio processing, such as voice compression, call process tone detection, etc., is a general application of DSP. This example uses DMA on the TMS320C5402 DSK to move audio codec data from McBSP to the buffer.

Data structures are used to track the driver's state as the driver responds to application calls and device interrupts. The valid state is the state of the device driver's buffer queue, as shown in Figure 1.

Figure 2 shows the simplest set of transfer states in this mode. The words in the circles represent the status of the device driver's buffer queue. The first word is the "to device" queue, the second word represents the buffer pointer occupied by the peripheral, the third word is the "from device" queue, the second word represents the buffer pointer occupied by the peripheral, and the third word is "from device" "queue. E means empty, F means full, and EEE is the initial state.

Each queue can be empty (E), full (F), or neither empty nor full (N). The application calls PutBuf() to put the buffer in the "to device" queue. The driver immediately places the buffer into the peripheral, transitioning to state "EFE". When the transfer is completed, the peripheral sends an interrupt signal to the driver, and then the driver interrupt handler transfers the buffer from the peripheral register to the "from device" queue, transfers to the state "EEF", and then calls the application's callback function. The callback function calls GetBuf() to retrieve the buffer from the driver's "from device" queue, and the driver returns to the starting state.

If the driver supports hardware queuing, the "to device" queue can control one buffer while another buffer is being transferred by the peripheral. Unlike the state transition in Figure 2, the application may now add another buffer to the "to device" queue. The driver stores this buffer pointer into a queue. At this time, the status is "FFE", the "to device" queue is full, the peripheral is transmitting a buffer, and the "from device" queue is empty. Implement the state vector of this state machine using C data structures.

Use the DMA global reload register to control the "to device" queue, and the status structure is as follows.

Typedef struct drv_state{

Bool enabled;

Ptr currentBuffer;

Uns currentSize;

Ptr fullBuffer;

Uns fullSize;

LIO_TcallBack callback;

Arg calbackArg;

} LIO_Obj;

The first field "enabled" is a Boolean value indicating the start or end of the program. The following two fields "currentBuffer" and "currentSize" control the starting address and size of the current transmission buffer. When the transfer is complete, they are moved to the "from device" queue. The "fullBuffer" and "fullSize" fields implement the "from device" queue with a length of 1. The address and parameters of Callback() are stored in the state structure through setCallback().

The driver receives only one interrupt per buffer, rather than one interrupt per sample. When an interrupt occurs, the driver already knows that the buffer transfer is complete and can be reloaded. The DMA does not need to be reprogrammed. The interrupt handler first moves the currentBuffer contents into fullBuffer. If the buffer is already in the "to device" queue, i.e. a reloaded DMA has been used, the new buffer pointer and length are recorded in the currentBuffer field, and callback() is called. Once the basic state machine is defined, new drivers for similar hardware are easy to write.