In the same processor core, tasks can switch between each other to share processing time. How to switch tasks manually?
When any event or interrupt occur, task much give it's processing time to another task . How to measure the time required to do switching?
How to program i.e how to decide manually(i.e.programming of events) the occurrence of events? Is it possible only through case statement in select?
I want to measure that context switching time beteween tasks.
Is Interrupt handling not at all possible in startkit programming?
When multiple tasks(>8 tasks) occur in the same processor core, how to set priority for those tasks? And how to handle them?
It's given in XTask Operating System that each hardware thread in a processor core has a separate kernel and we can schedule them. How to access the scheduler and do programming for those tasks? Can we create a hardware thread and multiple tasks inside that thread?
Everywhere, theory of concepts is provided briefly in manuals but programming about those concepts is not given with examples.
I am currently doing work in startkit to measure latency and also searching whether scheduling of tasks is possible in a hardware thread within a processor core. How can i access to harware scheduler in processor core so as to do scheduling?
I am unable to proceed further...
How To Measure CONTEXT SWITCHING TIME?
-
jeevanicherukuri
- Member++
- Posts: 17
- Joined: Fri Dec 26, 2014 4:41 pm
-
Hagrid
- Active Member
- Posts: 44
- Joined: Mon Jul 29, 2013 4:33 am
The XMOS architecture doesn't work the way I think you are thinking.
Presuming you are talking about code writtin in xc...
Between tasks running on different cores, there is no context switching - each core contains the context.
Between tasks running on the same core (i.e. combinable or distributable), the requirements for these cooperative tasks are such that the tasks are combined by the compiler to create a single task.
A select block within a task can be marked as [[ordered]] which allows you to set the priority of events within the select. I don't think there is a method for setting the priority of one combinable task's select events over another tasks in the resulting (underlying) uber-select.
One of the primary selling points of the xcore architecture is the way context switching doesn't happen like a "normal" processor.
Quoting from the XMOS Programming Guide (Section 1.5):
Often when programming other microcontrollers your program will react to external events via interrupts. A function will be registered against an interrupt that occurs when a certain event happens (e.g. a timeout or an external I/O event).
This function provides an interrupt service routine (ISR) that handles the event. Interrupts are not used to handle events in xC, the select construct provides all that is needed. The equivalent of an ISR is a separate task that executes a select.
The advantages of the XMOS approach are:
· Response time to events can be drastically improved (in conjunction with the multi-core xCORE architecture)
· Reasoning about worst case execution time (WCET) is easier since code cannot be interrupted during its execution.
Presuming you are talking about code writtin in xc...
Between tasks running on different cores, there is no context switching - each core contains the context.
Between tasks running on the same core (i.e. combinable or distributable), the requirements for these cooperative tasks are such that the tasks are combined by the compiler to create a single task.
A select block within a task can be marked as [[ordered]] which allows you to set the priority of events within the select. I don't think there is a method for setting the priority of one combinable task's select events over another tasks in the resulting (underlying) uber-select.
One of the primary selling points of the xcore architecture is the way context switching doesn't happen like a "normal" processor.
Quoting from the XMOS Programming Guide (Section 1.5):
Often when programming other microcontrollers your program will react to external events via interrupts. A function will be registered against an interrupt that occurs when a certain event happens (e.g. a timeout or an external I/O event).
This function provides an interrupt service routine (ISR) that handles the event. Interrupts are not used to handle events in xC, the select construct provides all that is needed. The equivalent of an ISR is a separate task that executes a select.
The advantages of the XMOS approach are:
· Response time to events can be drastically improved (in conjunction with the multi-core xCORE architecture)
· Reasoning about worst case execution time (WCET) is easier since code cannot be interrupted during its execution.
-
srinie
- XCore Addict
- Posts: 158
- Joined: Thu Mar 20, 2014 8:04 am
Is Interrupt handling not at all possible in startkit programming?
This thread on interrupts would be really useful to understand more:
http://www.xcore.com/forum/viewtopic.ph ... errupts&st...
Wrt xTASK, this is a nice RTOS feasibility to run kernel each core of the processor; it has a core level scheduler managed by the RTOS kernel.
The project has some benchmarks/tests on its kernel context switching (section 9: http://www.xtask.org/xmos_thesis.pdf)
This thread on interrupts would be really useful to understand more:
http://www.xcore.com/forum/viewtopic.ph ... errupts&st...
Wrt xTASK, this is a nice RTOS feasibility to run kernel each core of the processor; it has a core level scheduler managed by the RTOS kernel.
The project has some benchmarks/tests on its kernel context switching (section 9: http://www.xtask.org/xmos_thesis.pdf)