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.
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.
I did not know about the chip before. i only know these crazy expensive 60$+ wireless spi like wlan-“adapters”.
Thanks for pointing this out. lets see how long the delivery takes - wlan dead cheap. lets hope the board works
bettter than it looks hehe
ps. if its relevant for anyone realy low on budged and high trust on anon people i can fwd you one of the couple
adapters i orderd… well if they arrive this month
It's indeed a very cheap chip with wifi which is actually working with wpa2:)
The software on the chip is just garbage, but it's replaceable.
This device needs some more time than I have in my spare time:)
All the interesting components (wifi) are supported with a binary blob, so unless someone is willing to reverse engineer it, the potential RIOT benefit is a new board with a new cpu architecture.
But if you see this board as a external device it can be a cheap wifi board to connect a RIOT board to the internet. (the RIOT network stack is not used in this case).
The software on the chip is just garbage, but it's replaceable.
Definitely.
I like the LuaNodeMCU firmware the most. It's very powerful although
you access all functionality through LUA.
But if you see this board as a external device it can be a cheap wifi
board to connect a RIOT board to the internet. (the RIOT network stack
is not used in this case).
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.
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.
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.
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?!
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???
yapp, you got it right (if you main does just run through end finishes).
What happens next depends on what you program in you application... So if you create some threads those will probably scheduled, switching between the idle thread and your user or the main thread.