Fwd: [riot-devel] About scheduling

[DangNhat PhamHuu]

/***********************************************
* Phạm Hữu Đăng Nhật            

* StudentID: 51002279

* Class: MT10KTTN

* Ho Chi Minh University of Technology

* Mobile: 0164.968.2716
***********************************************/

---------- Forwarded message ----------
From: Hauke Petersen <hauke.p...@fu-berlin.de>
Date: 23 April 2014 22:06
Subject: Re: [riot-devel] About scheduling
To: RIOT OS kernel developers <de...@riot-os.org>

Hello DangNhat,

I will try to answer your questions:

On 23.04.2014 16:57, DangNhat PhamHuu wrote:

Hi everybody, 

Could anyone explain some questions I have about the scheduler of RIOT ? (I'm using RIOT on iot-lab_M3 and native platform.)

- First, does the context switch happen periodically or event-driven ? If it happens periodically then how long the time slide is ? If it's event-driven then which events will trigger the scheduler to run (when the running thread is blocked, etc. ) ?

RIOT is build around a tickless scheduler, which means that there is no periodic context switching. RIOTs task switching is completely interrupt driven. The scheduler is called once after each activated interrupt handler.

- Second, (it's about iot-lab_M3 port), TIM2 is supposed to run without interrupt, i.e in hwtimer_arch_init, TIM2 and NVIC_IRQChannel for TIM2 are initialized but hwtimer_arch_enable_interrupt function will not be called ? Beside, what is the function of TIM3, there is TIM3_IRQHandler but I haven't found the place which TIM3 would be used ?

If I am informed correctly, the iot-lab_M3 port is using only TIM2 for the hardware timer. And it is using the TIM2 interrupts - they are just not enabled in the initial state. The hwtimer works in a way, that the interrupt of one of TIM2s capture/compare channels is only activated, once a timeout for that channel is set. Once the inerrupt handler of that channel is called, the interrupt is disabled again.

Hope this information is useful for you! Keep us informed how your RIOT port is coming and let us know if you need more help!

Cheers,
Hauke

I'm trying to port RIOT to my platform, which also based on STM32F10x so I'm curious about every little details.

Thanks in advance. :)

DangNhat.

/***********************************************
* Phạm Hữu Đăng Nhật            

* StudentID: 51002279

* Class: MT10KTTN

* Ho Chi Minh University of Technology

* Mobile: 0164.968.2716
***********************************************/

_______________________________________________
devel mailing list
de...@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

_______________________________________________
devel mailing list
de...@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel

[DangNhat PhamHuu]

/***********************************************
* Phạm Hữu Đăng Nhật            

* StudentID: 51002279

* Class: MT10KTTN

* Ho Chi Minh University of Technology

* Mobile: 0164.968.2716
***********************************************/

---------- Forwarded message ----------
From: Kaspar Schleiser <kas...@schleiser.de>
Date: 24 April 2014 01:31
Subject: Re: [riot-devel] About scheduling
To: RIOT OS kernel developers <de...@riot-os.org>

Hi,

On 04/23/14 17:06, Hauke Petersen wrote:

On 23.04.2014 16:57, DangNhat PhamHuu wrote:

Hi everybody,
Could anyone explain some questions I have about the scheduler of RIOT
? (I'm using RIOT on iot-lab_M3 and native platform.)
- First, does the context switch happen periodically or event-driven ?
If it happens periodically then how long the time slide is ? If it's
event-driven then which events will trigger the scheduler to run (when
the running thread is blocked, etc. ) ?

RIOT is build around a tickless scheduler, which means that there is no
periodic context switching. RIOTs task switching is completely interrupt
driven. The scheduler is called once after each activated interrupt handler.

Not quite. The principle of RIOT's scheduling is that the thread with the highest priority is being run. It can only be interrupted by an ISR or by another thread with a higher priority that was previously sleeping/waiting.

The scheduler is being triggered whenever the active thread or an ISR call a function which might cause a context switch. These include sending/receiving a message, waking up a thread, putting a thread to sleep and waiting for/releasing a mutex.

So it's possible to have a context switch without ISR and also to run an ISR without running the scheduler.

Kaspar