thread is not working

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

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

Hi *,

Does anyone has any experience with this cheap WiFi transceiver (ESP8266)?

May be of interest to some of you, too.

http://www.ebay.de/itm/ESP8266-Serial-WIFI-Wireless-TransceiveR-Module-SPI-Send-Receive-LWIP-Arduino-/171530595640?pt=Wissenschaftliche_Geräte&hash=item27f0052d38

Cheers,

CG

Hi Cenk!

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 :slight_smile:

hf

I've tried them. They are pretty cool.

This is what I've done with them so far:

  - http://clixx.io/esp8266-01.html

Hi,

I've got two of those and they appear to be working :wink: I can bring them to the university if you are interested in first hand experience.

Cheers, Ludwig

we orderer 20 or something :slight_smile:

I can bring some of them to the next hack n ack!

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).

Best Christian

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).

Well it probably could be easily interfaced.

Regards

David

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?

thanks shishir tiwari

Hi,

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

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

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

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

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

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

Hi,

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.

Cheers, Hauke

Hi Petersen,

Thanks for your support .

We able to port and threads are working properly. we have tested Posix_semaphore , IPC_pingpong, pthread examples all are working fine

once again thank for your support.

Thanks Shishir Tiwari

Hej,

you're welcome :slight_smile:

Looking forward to you pull requesting your code!

Cheers, Hauke