Hi.
I have problems after my scheduler switches the task.
Using the task_switch(), the control is passed to the task01() function, the problem is that after the task01() ends, the control is not returned back(I expect the control to return to the pit_handler())
But this is not the main problem, the main oddity is that interrupts stop working when the task01() function is called, even though the interrupt flag is set. I have no guesses as to why task switching suspends interrupts.
What's going wrong?
Switching tasks suspends interrupts
-
- Member
- Posts: 5885
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Switching tasks suspends interrupts
You switch tasks before sending the EOI, so the PIC thinks you're still handling IRQ0, and won't allow another IRQ0 or any lower-priority IRQs to occur.
Since IRQ0 is the highest priority, there are no other IRQs that can occur.
Since IRQ0 is the highest priority, there are no other IRQs that can occur.
Re: Switching tasks suspends interrupts
I agree. The OP is missing a proper EOI.Octocontrabass wrote:You switch tasks before sending the EOI, so the PIC thinks you're still handling IRQ0, and won't allow another IRQ0 or any lower-priority IRQs to occur.
Since IRQ0 is the highest priority, there are no other IRQs that can occur.
Cheers,
bzt
Re: Switching tasks suspends interrupts
Exactly, you're right.
But, how can I get the return statement in task01() to return control back to pit_handler()?
But, how can I get the return statement in task01() to return control back to pit_handler()?
-
- Member
- Posts: 5885
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Switching tasks suspends interrupts
Set up the stack so the function will return to a function that performs the "end task" system call. The "end task" system call will remove the task from the queue, clean up (or enqueue deferred cleanup), and switch to another task in the queue.
One of the tasks in the queue is the one that switched tasks in the middle of pit_handler(). When you switch to that task, you'll return control to pit_handler().
You cannot return control to pit_handler() without another task switch.
One of the tasks in the queue is the one that switched tasks in the middle of pit_handler(). When you switch to that task, you'll return control to pit_handler().
You cannot return control to pit_handler() without another task switch.
Re: Switching tasks suspends interrupts
I realized that I think using system calls will be even more convenient.Octocontrabass wrote:Set up the stack so the function will return to a function that performs the "end task" system call. The "end task" system call will remove the task from the queue, clean up (or enqueue deferred cleanup), and switch to another task in the queue.
One of the tasks in the queue is the one that switched tasks in the middle of pit_handler(). When you switch to that task, you'll return control to pit_handler().
You cannot return control to pit_handler() without another task switch.
The main difficulty will be that OS will need to monitor the presence of the system call "end_task ()" instead of return () in user programs, because if it is not there, the program will hang in the queue.
Re: Switching tasks suspends interrupts
When you compile programs for your OS you should include startup code that calls "main()" and, on return calls your end_task() (more usually called _exit()) system call. It would be poor design to require the programmer to insert the system call at the end of every program. Always let the compiler do any standard work rather than relying on the programmer.
Re: Switching tasks suspends interrupts
I think I can get the compiler to insert "_exit()" instead of "return" in the required places so that the program ends correctly.iansjack wrote:When you compile programs for your OS you should include startup code that calls "main()" and, on return calls your end_task() (more usually called _exit()) system call. It would be poor design to require the programmer to insert the system call at the end of every program. Always let the compiler do any standard work rather than relying on the programmer.
Last edited by mrjbom on Fri Jul 10, 2020 7:12 am, edited 1 time in total.
Re: Switching tasks suspends interrupts
What happens is main() is called by the runtime. The runtime is the first code executed in an app, and it is a part libc. It calls global constructors, creates a heap, and calls main. main returns when execution is over and returns a value. It actually returns to the runtime. The runtime destroys its heap, calls global destructors, and lastly calls _exit() to exit the app/