On the Cortex-M3 from the MSP and PSP Linux can use the Sleep In interrupts

1, Cortex-M3 PSP and MSP

     Have been used in the STM32 through RT thread and uC / OS, for task switching code has been a little knowledge, without their own manual written before, for ORR LR after task switching, LR, # 0x04; Ensure exception return uses process stack is not very understand, by chance, I met online asked this question before going deeper look. Cortex-M3 has two stack pointers, but they are Either the BANKED, so at any one time can only use one of them:

     Main Stack Pointer (MSP): After the reset stack pointer used by default for the operating system kernel routines and exception handling (including interrupt service routines).

     Process stack pointer (PSP): used by the user application code. Minimum two stack pointer is always 0, which means that the stack is always 4 byte aligned.

    It can be seen, there are two parts in one system, one operating system and interrupts, one user user program, they use resources is not the same, when in task scheduling, interrupt (interrupt task scheduling) so to return to the user program using the PSP.

2, Linux systems can use the Sleep interrupt

      This is one of my students face questions, he said to me when I first reaction is, use the Sleep interrupt interrupt pending will not make use of Sleep will suspend the current task in the task, Sleep principle is Sleep parameters according to suspend the current task N, N cycles (and possibly MS) after the task is set to ready state, in other words, Sleep is actually a task scheduler, why can not I further explained that in uC / OS in the end will call OS_INT_EXIT interrupt () function to schedule tasks, Sleep and OS_INT_EXIT just a different function names are ultimately calls the scheduler.

      Haha, I think the right answer for everyone guessed, it is not a matter of course, but my interpretation seemingly seamless Oh, it was because I was using uC / OS to explain, Linux system, and of course, uC / OS different, Looking back, there are MSP and PSP in the Cortex-M3 hardware, then what he originally designed, it is the operating system (including interrupt) and the user program divided (separated) from, or to protect the operating system, was to prevent to destroy, in this thought, Linux system, for something related to the core of the system using protection, not all places are visible, uC / OS is compiled with the systems and applications, as long as all global variables can see, different Linux, interrupt and down to the, current macro is invalid, it is not possible at this time task scheduling.

     These are my combination of Cortex-M3 core hardware, isolation and protection from ideological to explain why Linux, the interrupt can not be used Sleep. I was given access to information official explained below, mainly on the content of "kernel design and implementation linux".

     1, process context

      Executable code is an important part of the process, the code loaded from an executable file to execute the process's address space. General program execution in user space, when a program is executed or system call triggered an exception, it is caught in kernel space, this time, we call on behalf of the kernel execution process and in the context of the process. In this context current macro is effective. (System call and exception handlers are well-defined interface to the kernel, the process only through these interfaces into the kernel execution order - all access to the kernel must go through these interfaces.

     2, interrupt context

      When executing an interrupt handler in the kernel interrupt context, and process interrupt context does not have any connection. The current macro is irrelevant (although it points to the interrupted process). Because there is no back-up process, so the interrupt context can not sleep, otherwise how can it again reschedule it? Thus, certain functions can not be called from the interrupt context (that is, the interrupt handler function restriction, Sleep is one).

     In fact, in addition to the MSP and PSP, a lot of processor registers are banked, the user program and interrupt register used by the program is different, so the process context and interrupt context is different, if the task scheduling in interrupt context there is no way to save process context information, so if this is the time scheduling problem, the software prevents the scheduling - the current macro at this time is not visible, which can not be scheduled.

Guess you like

Origin www.cnblogs.com/Ph-one/p/11112897.html