Go deep into DSP/bios api functions-software interrupt management SWI

The SWI module manages software interruption services. These interrupt service programs are closely related to Hwi hardware interrupt service programs. Generally, most of the daily processing functions are placed in these software interrupt service programs for management and operation.

I. Overview of the SWI Module

In the DSP/BIOS kernel, the threads managed and run by the system are divided into four levels: hardware interrupt service program, software interrupt service program, task, and background idle function. The priority is reduced in turn. Each software interrupt service program corresponds to a function. Of course, each software interrupt night can be set with a separate priority. High-priority software interruptions can preempt low-priority software interruptions being executed (therefore, DSP/BIOS is a priority-based Real-time preemptible kernel) software interruptions are initiated by calling the DSP/BIOS kernel API. Once a SWI object is started, the system creates a running schedule for the functions in the SWI object. Therefore, when a software interruption is started, the object function may not be executed immediately, but will wait in the execution queue for running according to the priority according to the schedule. DSP/BIOS determines whether to suspend the current running thread Based on the software interruption priority.
To facilitate control, the system sets a 16-bit mailbox (Mailbox) for each SWI object. You can use the mailbox value to initiate the software interruption. The system kernel automatically maintains mailbox management. The DSP/BIOS Kernel provides swi_disable and swi_enable operations to prohibit or allow software interruption. At the same time, there are also 15 priority settings for software interruption, the highest priority is swi_maxpri (14), the lowest priority is swi_minpri (0), the zero priority is knl_swi object retention, the task of the knl_swi object is to run the task scheduler. This object is automatically created by the kernel. High-priority software interruptions interrupt the running low-priority software interruption. If the two software interruptions started have the same priority, the first software interruption will be executed first.

Interrupt threads (including hardware interruptions and software interruptions) use the same stack for execution. When the interruption occurs, the new thread will be added to the top of the stack, and the system will execute a task switchover (Context
Switch ). Because high-priority software interruptions interrupt the operation of low-priority software, the SWI module automatically saves the content in the register before the high-priority software is interrupted. After a high-priority software interruption is completed, the register restores the original content to continue running the original low-priority software interruption. If other high-priority software interruptions are not started, low-priority software interruptions will run. Although the DSP/BIOS kernel is preemptible, if there is no API function call that leads to task switching, the system will not actively switch to other threads for execution. (Understanding this is very important in practical applications, that is, if you are currently running a function with a low-priority Soft Interrupt, if you are not calling a function such as swi_post () if a higher-priority software interrupt is started or a lower-priority interrupt is started than itself, the current Soft Interrupt will not be interrupted until it is executed ).

Personal experience: Do not start another software interrupt with a higher priority in a soft interrupt function, because it will be interrupted according to the preemption principle, as a result, the CPU is switched to the corresponding function of high-priority Soft Interrupt, and the real-time performance of low-priority instances is not guaranteed. When there is a multi-level priority and the system is complex, it may even cause system paralysis. Do not set many priorities. Of course, this is not absolute. if the system is well planned, taking advantage of the Soft Interrupt priority-based preemptible feature will greatly simplify your design.

Ii. Log Module Configuration

Software interruption can be statically described in the DSP/BIOS configuration file. Open the DSP/BIOS configuration file and expand the "scheduling" option to select the SWI module.
Comment: add an annotation to describe the SWI object.
Function: the name of the function to be called by the software interrupt object.
Priority: displays the SWI object priority.
Mailbox: Set the initial mailbox value.
Arg0, arg1: two pointer-type variables of the software interrupt function. This variable can be passed to the function by the kernel when the software function is started.

Iii. Log Module API Function Description

1. swi_andn: Calculate the parameters and mailbox values provided by this function. If the mailbox is 0, the software is interrupted;
2. swi_dec: the email address value minus 1. If the email address value is 0, the software is interrupted and the mailbox is restored to the initial value;
3. swi_disble: Disable software interruption;
4. swi_enable: allows software interruption;
5. swi_getmbox: return the mailbox value. Note that this function can only be called in the software interrupt function;
6. swi_getpri: return the software interruption priority;
7. swi_inc: Start the software interruption and Add 1 to the mailbox value;
8. swi_or: the software is interrupted, and the mailbox value is calculated with the parameters provided by the function;
9. swi_post: software interruption;
10. swi_raisepri: increases the software interruption priority;
11. swi_restorepri: Priority for restoring software interruptions;
12. swi_self: return the address of the SWI object.