Common software structure and related concepts based on TI's algorithm standards

Jacktang

Common software structure and related concepts based on TI's algorithm standards [Copy link]

      TI has given a general software programming idea for how to apply algorithm standards in practice. A DSP-based software is divided into several modules, each of which has a strict definition, so that there are clear boundaries between modules. Figure 1 is a software structure diagram based on the host-target machine (the host side is not drawn in the figure). It can be clearly seen from it that the general DSP program is divided into four parts: FrameWork, ALG, Core run time Support, CMD and Status. FRAMEWORK is an application framework, which is a platform or operating system that supports DSP operation, such as pSos, vxworks, UC-OS-II, etc.; ALG is a DSP algorithm independent of the processor; Core run time support is a running support kernel, such as rts54.lib, etc.; ALG is a DSP algorithm independent of the processor; Core run time support is a running support kernel, such as rts54.lib, etc.; CMD is the command sent by the host to the target machine, and Status is the status information returned by the target machine to the host. The host and target modes are only used in development or in certain control situations. Most DSP software runs independently of the host. Therefore, we only discuss the working mode independent of the host. The following will discuss the functions and interrelationships of the above aspects in detail. (1) Application Framework The application framework is usually an I/O subsystem that is relatively independent of the device. That is, it provides a general I/O interface and specifies how algorithms and applications use this interface. All possible peripherals exist in the form of interfaces, and algorithms access peripherals through the interfaces provided by the framework. A typical application framework is an operating system. For example, in the Windows operating system, applications cannot directly access peripherals such as serial ports and parallel ports, but can only interact with peripherals through the API (application programming interface) provided by the Windows operating system. Any peripheral can be connected to the operating system as long as it provides an interface (driver). In the field of DSP and microprocessors, the most famous application frameworks are the pSos and VxWorks operating systems of Wind River. Some application frameworks only provide some basic I/O functions due to different application fields or simple application solutions, and it is difficult to be called an operating system. For example, the DSP/BIOS (Basic Input Output System) real-time kernel embedded in CCS (Code Compose Standard). The basic function of the framework is to provide an interface for data input and output. In addition, the framework also defines the level of internal application modules, that is, the priority of tasks in the operating system. Through the priority, the framework can control the modules, such as interrupting the operation of modules or restoring modules, or deciding which module to run first, which is the so-called task scheduling in the operating system. The application framework is responsible for the scheduling of I/O interfaces and tasks, and is essentially a software platform based on the hardware platform. (2) Algorithm (ALG) The algorithm is a pure data converter that simply receives and processes the input data. There are usually two ways for the algorithm to obtain data, both of which are inseparable from the support of the application framework. One is the interrupt input mode, where the algorithm obtains data through the interrupt service function of the application framework; the other is the query mode, where the application framework provides a periodic function through which data is periodically obtained at a certain port. In all cases, the algorithm is designed to be independent of the I/O device in the system. That is, the algorithm cannot directly access the address of the peripheral register, that is, the physical address of the peripheral cannot appear in the algorithm, and the address can only be passed to the function through a pointer parameter or a module interface pointer. This implementation usually relies on an I/O interface module. This method can reduce the dependence on the framework and improve the versatility of the algorithm. An algorithm can have multiple implementations, and different implementation methods mean different performance. Excellent algorithm implementation codes are short and efficient. However, these two are usually not available at the same time. The improvement of execution efficiency is usually at the expense of increasing code length, which means that more storage space is required. On the contrary, if the algorithm implementation code is small, the execution performance will usually be reduced. At the same time, the prices of different algorithm implementations are also different. This gives algorithm integrators or developers more room for choice. Of course, this compromise between performance and algorithm must be based on the premise of following the algorithm standard. Otherwise, the algorithms cannot be "replaced" with each other, and multiple implementations of the algorithm will lose their meaning. (3) Runtime support kernel In order for the algorithm to meet the minimum requirements of reentrancy, independence from I/O peripherals, and debuggability, the algorithm needs a series of kernel services that are always stable. For example, the C language runtime support kernel. This kernel provides basic printing functions such as printf(), memory management functions such as memcpy(), string functions, and time functions, which are the basic runtime environment of the standard C language. The relevant functions of the kernel are encapsulated to form a support library rtsxx.lib. xx represents the type of processor. Since most algorithms are still generated in assembly language, many services provided by the kernel must also be suitable for assembly language and can be accessed using it. This is also the basis for mixed programming of standard C language and assembly language. The TIDSP runtime support kernel also contains a subset of DSP/BIOS, which provides basic input and output functions, which are faster than the basic input and output functions of standard C. In addition, it also comes with a subset of minor operations on control and status registers, such as setting overflow mode, etc. The codes of the algorithm, application framework, and runtime support kernel are relatively independent, interact with each other, and work together to form an effective application software. There are their own boundaries between them, and their respective functional scopes are defined in the standard. Only when the algorithm is relatively independent of the application framework and runtime support kernel can it support "plug and play" and replace one algorithm with another without extensive modification of the source code.