Hi Petersen,
We have one question regarding when we switched from
cpu_switch_context_exit--> main_trampoline---->sched_task_exit
-->cpu_switch_context_exit-->idle_thread-->sched_task_exit (this never
execute) Is this understanding is correct?
my question is what will happen next and what need tobe done???
Thanks
Shishir Tiwari
On Thu, Jan 15, 2015 at 9:00 PM, Hauke Petersen
<hauke.peter...@fu-berlin.de> wrote:
> Hi Shishir,
>
> the scheduler is deciding which task is run next. During normal operation,
> the behavior is intended as this:
>
> - save the current context (register contents to the current stacks thread)
> - run scheduler to determine the thread with the highest priority
> - point a global variable (sched_active_thread) to the chosen thread's
> control block
> - restore the context using the stack pointer from the active thread
> (pointed to by sched_active_thread)
>
> During system start-up (or after a thread terminates), this behavior is
> slightly different, as the context save is omitted.
>
> Now finding the task_func is a question of initializing the stack correctly.
> If you know your context-restore sequence, you have to put initial register
> values onto your threads stack (done in thread_arch_stack_init()). The value
> of the task_func pointer is pointing the the first instruction the thread
> should execute. For this you have to load the value of the task_func pointer
> into the MCUs program counter on context restore. How this is done heavily
> depends on your MCU architecture - maybe this becomes clearer if you look a
> the ARM Cortex implementations?!
>
> Does this answer your question?
>
> Cheers,
> Hauke
>
>
> On 15.01.2015 16:03, shishir tiwari wrote:
>>
>> Hi Petersen,
>>
>> we are still facing issue for thread not working . we want to know how
>> the task get schedule and how it find the task_func entry point and
>> also how is switching happen.
>>
>> please help on this.
>>
>> Thanks
>> Shishir
>>
>>
>> On Wed, Jan 14, 2015 at 3:44 PM, Joakim Gebart <joakim.geb...@eistec.se>
>> wrote:
>>>
>>> You can look at the startup files for other CPUs for a proper way of
>>> doing
>>> initialization e.g. cpu/stm32f1/startup.c
>>> Note that you must also make sure that your linker script provides the
>>> correct symbols at the beginning and end of .data and .bss.
>>>
>>> Best regards,
>>>
>>> Joakim Gebart
>>> Eistec AB
>>> www.eistec.se
>>>
>>> On 01/13/2015 10:45 PM, Ryan Kurte wrote:
>>>
>>> Hi Shishir,
>>>
>>> I seem to recall having the same issue when starting the EFM32 port.
>>> The issue in my case was that without the startup files, the .bss section
>>> was not getting cleared.
>>> When the threads came to launch, the value in one of the kernel functions
>>> was not correct. Which is pretty easy to check with a debugger.
>>>
>>> The fix was to clear the .bss section in the _init routine, my
>>> implementation (using symbols from the linker) is:
>>>
>>> //Clear bss
>>> for (uint32_t i = (uint32_t)&__bss_start__; i <
>>> (uint32_t)&__bss_end__;
>>> i++) {
>>> addr = (int*)i;
>>> *addr = (int)NULL;
>>> }
>>>
>>> I am not sure this is the /correct/ way to do it, but the .bss definitely
>>> needs to be initialised to zeros.
>>>
>>> Hope that helps,
>>>
>>> Ryan
>>>
>>> On 14 January 2015 at 07:56, Hauke Petersen <hauke.peter...@fu-berlin.de>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 13.01.2015 19:04, shishir tiwari wrote:
>>>>>
>>>>> Hi petersen,
>>>>>
>>>>> Thanks for your information.
>>>>>
>>>>> we are trying to put your method but still is it not working. we are
>>>>> studying and doing some experiments.
>>>>>
>>>>> one more question : In hwtimer_init()--> hwtimer_arch_init() this need
>>>>> to be implemented in harsware is compulsory?? for scheduling to work?
>>>>
>>>> nope, the timer is generally not needed for scheduling.
>>>>
>>>> Cheers,
>>>> Hauke
>>>>
>>>>
>>>>
>>>>>
>>>>> thanks
>>>>> shishir tiwari
>>>>>
>>>>> On Mon, Jan 12, 2015 at 10:01 PM, Hauke Petersen
>>>>> <hauke.peter...@fu-berlin.de> wrote:
>>>>>>
>>>>>> Hi Shishir,
>>>>>>
>>>>>> when RIOT initially starts up, the CPU is normally running in
>>>>>> interrupt
>>>>>> mode
>>>>>> (using the interrupt mode stack). After creating the stacks for the
>>>>>> main
>>>>>> and
>>>>>> the idle threads, the CPU must be put into thread-mode. This means the
>>>>>> main
>>>>>> threads initial context needs to put into the CPUs registers and the
>>>>>> stack
>>>>>> pointer must put to the main-threads stack. After this is done the CPU
>>>>>> can
>>>>>> just do 'normal' task switching for switching between threads.
>>>>>>
>>>>>> So to put it short: in cpu_switch_context_exit() you simply must load
>>>>>> the
>>>>>> main threads context into the CPUs register and point the stack
>>>>>> pointer
>>>>>> to
>>>>>> the main threads stack.
>>>>>>
>>>>>> Let me know if you need further information!
>>>>>>
>>>>>> Cheers,
>>>>>> Hauke
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 12.01.2015 15:35, shishir tiwari wrote:
>>>>>>>
>>>>>>> Hey Everyone,
>>>>>>>
>>>>>>> I have been porting RIOT OS to new processor(ARC) and i had compilied
>>>>>>> hello world program successfully.
>>>>>>> When i debug the helloworld.elf in kernel_init function the
>>>>>>> thread_create() function has execute successfully.But the thread
>>>>>>> "idle_thread" "and main_trampoline" function is not been called. why?
>>>>>>>
>>>>>>> What is thing need to be done on this cpu_switch_context_exit()
>>>>>>> function. please explain me.
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Shishir Tiwari
>>>>>>> _______________________________________________
>>>>>>> devel mailing list
>>>>>>> devel@riot-os.org
>>>>>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> devel mailing list
>>>>>> devel@riot-os.org
>>>>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>>>
>>>>> _______________________________________________
>>>>> devel mailing list
>>>>> devel@riot-os.org
>>>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>>
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel@riot-os.org
>>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel@riot-os.org
>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel@riot-os.org
>>> http://lists.riot-os.org/mailman/listinfo/devel
>>>
>> _______________________________________________
>> devel mailing list
>> devel@riot-os.org
>> http://lists.riot-os.org/mailman/listinfo/devel
>
>
> _______________________________________________
> devel mailing list
> devel@riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
