Emphasis on multithreading-reference method for selecting thread types when using DSP/BIOS

Understanding the following makes it easy to design multi-threaded applications on DSP/BIOS.
DSPs/BIOS support multiple types of threads. Each type of thread has different execution and preemptive points. The table (click to see the larger picture) lists some features of these threads.

Principles of thread Selection
The thread selection is based on the answer to the following question: in the application, is this thread real-time (the thread must end in a strict period of time, and cannot be preemptible )? Is the execution time of this thread much less than that of other parts?
1. Strict real-time performance
If the thread execution requires strict real-time performance, and the thread execution requires little time, you can use hardware interruption or clock functions to complete the process. CLK clock functions are also executed during hardware interruption.
Generally, a DSP chip has one or more on-chip timer peripherals, which can generate periodic hardware interruptions at intervals. The DSP/BIOS kernel usually uses one of the timers as its own system clock. In most TMS320 series DSPs, the CLK module of the DSP/BIOS kernel can provide a clock close to a machine cycle. The CLK function is triggered by an on-chip timer interrupt and is called and executed in the interrupt service subroutine (ISR.
The hardware interrupt thread is triggered by an external synchronization event (or an AD converter interrupt signal. The Hwi function or interrupt service subroutine (ISR) will be executed after the interruption occurs. Hwi functions have strict real-time performance because hardware interruptions have the highest priority. In DSP/BIOS applications, the HWI interrupt function can handle interruptions at a frequency of kHz (which may vary depending on the operating frequency or ISR complexity ). Therefore, when the processing interval is between 2 and 5 us, the hardware interrupt thread can be used. Another reason is that the hardware interrupt thread has a very small interrupt latency. The period of interruption refers to the period from the interruption trigger to the execution of the first instruction of the interrupt service subprogram. Of course, the longer the interrupt latency, the less timely the interrupt response, which is very important for real-time processing. The hardware interrupt thread can only use the combination of assembly language or C language and assembly language, but I usually recommend using assembly language.
In the hardware interrupt handler, you can place SWI software interrupt objects or tsk task objects in the execution queue, but they must wait until all hardware interrupt threads are finished. Therefore, the HWI hardware interrupt function should be minimized so that the interrupted service order can end as soon as possible. In addition, the DSP automatically blocks all interrupts in response to hardware interruptions. Therefore, you can enable some interruptions by setting the hwi_enter parameter, allowing these interruptions to be executed first. This method is very effective when the system has multiple hardware interrupt threads and one of the interrupt service programs takes a long time.
When the hardware interrupt function calls the API functions of some pip pipeline modules, such as pip_alloc, pip_free, pip_get, and pip_put, the read/write notification function will also call and execute in the interrupt response.
2. Partial Timeliness
Sometimes this problem occurs. Only some threads have strict real-time execution requirements, while others have a long execution time and do not have many requirements on the processing time. Obviously, it is not ideal to only use hardware to interrupt the thread.
In general, strict real-time processing is triggered by hardware interruptions, so we will obviously use the hardware interrupt service program to respond to this interruption, so as to meet the real-time requirements. A more practical approach is to increase SWI software interruptions or tsk task threads to complete some non-real-time processing tasks. This reduces the interrupt latency and improves the ability to respond to real-time requests.
Therefore, the code is divided into multiple threads, as long as there is a strict real-time task to be completed in the HWI hardware interrupt, and the rest of the processing is completed in the lower-priority SWI or Tsk. These SWI or tsk threads have the following two features:
* Real-time processing tasks can be completed, but the processing time is relatively long;
* Other threads are allowed to take the lead.
So should these processing functions use the SWI software to interrupt the thread or the tsk task thread? Take a look at the following situations:
* The processing function needs to wait for some resources (such as data and host computer signals) to continue running.
* There are complex connections or data sharing requirements between processing functions and other threads.
* You want the processing function to have its own stack space instead of the stack space shared by the system.
* LCK, mbx, or SEM kernel modules are used in processing functions.
* You want to call the hook function when the thread is created, deleted, exited, ready, or switched.
When either of the preceding conditions exists, we recommend that you use the tsk task thread. On the contrary, we recommend that you use the SWI software for interruption when none of the preceding conditions occur. The job thread differs from the software interrupt thread in the following ways:
* A task can be paused only when the required conditions (such as data preparation and signal synchronization) are met. When a task is suspended, that is, the task is in the paused or blocked State. Other tasks or threads can be executed, but software interruption cannot.
* The DSP/BIOS Kernel provides a set of data structures for task communication and synchronization, including the flag, mailbox, and lock. These data structures cannot be used for communication and synchronization between software interruptions.
* Each task has its own stack zone, and the software is interrupted using the shared system stack.
* Special Functions (Hook Functions) can be called when a task is created, deleted, exited, or switched ). These hook functions can be used to save the environment surface of a task, not just the registers of the CPU.
* The priority of the task thread is lower than that of the software interrupt thread, but higher than that of the background IDL thread. The task thread is divided into 16 priority levels. The priority of a user task can be from 1 to 15, and the lowest level 0 kernel is reserved for loop usage.
Software interruption threads are often accompanied by hardware interruption. Whenever a hardware interruption occurs, Hwi hardware interruption service functions are triggered, and the software interruption is triggered by SWI software interruption API function calls. For example, you can call the swi_post function in the hardware interrupt service function to trigger a SWI software interrupt.
Software interrupt threads are suitable for processing tasks with low rate or less demanding real-time requirements. SWI software interruption can help hardware interrupt functions put some non-strict real-time processing into low-priority threads to reduce the hardware interrupt response time. This is very important, because the hardware interrupt response is often in the disconnected state.
Like the hardware interrupt thread, the software interrupt thread always runs until it ends. When the program puts the software interrupt into the execution queue of the CPU and waits in a queue, all the data required by the software interrupt function should be ready. The mailbox in the SWI software interrupt object provides a method to determine the resource preparation. When other threads are running, a software interrupt thread cannot wait for the resource to become valid.
The priority of software interruption is higher than that of task threads, but lower than that of hardware interruption. Software interrupt threads use less memory than task threads because all software interrupt threads use the system stack space. The task thread provides additional capabilities, such as pausing (blocking) and switching, which are not supported by the software interrupt thread.
3. Periodic services
Although sometimes the thread execution has real-time restrictions, the processing task has been executed for a long enough time and can allow other threads to take the lead, that is, other threads are interrupted to process more urgent tasks. In this case, you can refer to the preceding principles for processing some real-time threads. However, there is a special application that needs to process tasks cyclically or at a fixed interval. In general, the time interval is much longer than the time required to process the task. For this requirement, we recommend that you use the PRD periodic function provided by the DSP/BIOS kernel.
The cyclic function is based on the system clock. By default, the system clock is driven by the on-chip timer, and can be configured as other events to drive, such as IO events. A periodic function is a prd_swi object in Swi software interruption. Generally, this object has a lower priority. You can use the DSP/BIOS Configuration tool to increase its priority.
All PRD cyclic functions have the same SWI software interrupt priority, so one cyclic function cannot be the first to use other cyclic functions. When some other SWI or tsk threads have a long processing time, in order to ensure the normal execution of all PRD cyclic functions, in addition to minimizing the processing time of cyclic functions, it is also necessary to increase the priority of the entire PRD cyclic function to ensure that the cyclic function is allowed to take the lead of low-priority threads when the system clock is triggered.
If multiple cyclic functions are triggered by the same system clock, they are executed in the order of creation. In addition, if the cyclic function needs to be suspended or paused, tsk threads should be used to complete the same service.
4. No real-time requirement
Sometimes the thread only needs to perform some irrelevant processing in the background, such as collecting statistical data and exchanging detection data with itself. We recommend that you use the IDL thread.
The IDL wait loop is the lowest priority thread in the DSP/BIOS kernel. When the main function of the application returns, the DSP/BIOS kernel calls the initialization startup code of the DSP/BIOS module used by the application. After the startup code is complete, it enters the IDL wait loop. This loop is an infinite loop that constantly calls all functions in the IDL background object. Each function runs sequentially after the previous function is completed. These IDL functions are continuously run until they are preemptive by threads with higher priorities. Because IDL functions have the lowest priority and the running time is not guaranteed, IDL functions are not suitable for any processing tasks with real-time requirements. It is usually used in non-real-time device queries that do not require interruptions (and certainly do not require interruptions), or for monitoring system status, or other background activities.
The communication between the DSP target system and the DSP/BIOS analysis tool of the host is completed in the background IDL loop. This ensures that DSP/BIOS analysis tools do not interfere with the running of applications. If the DSP on the target board is too busy to run the background IDL thread, the DSP/BIOS analysis tool stops receiving the target board information. Therefore, we often see that when the processing tasks of the target board DSP are too heavy or errors fall into an endless loop, all operations of CCS will become slow.