Thanks Kaspar,
According to your explanations (Interrupting with ISR or higher priority),
RIOT works like as a single thread application.
I would expect a context switch mechanism for a quantum value even if
threads have same priority.
I have tried vtimer_usleep() method instead of my delay() function in two
thread.
static void *led3Thread(void *arg)
{
while (1)
{
LED3_Write(!LED3_Read());
vtimer_usleep(n); // Tried with 500000, 1000000
}
}
static void *led4Thread(void *arg)
{
while (1)
{
LED4_Write(!LED4_Read());
vtimer_usleep(n); // Tried with 500000, 1000000
}
}
After first call of vtimer_usleep(), execution is blocking (no changes on
leds) in vtimer_usleep() function.
For a single thread vtimer_usleep() function is working well.
FYI.
Murat.
-----Original Message-----
From: devel [mailto:[email protected]] On Behalf Of Kaspar Schleiser
Sent: Monday, February 9, 2015 8:02 PM
To: [email protected]
Subject: Re: [riot-devel] Context Switching
Hi Murat,
On 02/09/15 18:46, Murat CAKMAK wrote:
> Threads looks like working as blocking. In general, led3Thread is
> started before and only led3Thread is working. Never switch to
> Led4Thread (I could not see changes on Led4).
>
> If I dont create thread3, I can see changes on Led4.
>
> So, Why am I not able to observe context switching? Is it normal
> behaviour or not?
RIOT will only interrupt a running thread if an ISR occurs or a higher
priority thread becomes runnable. So what you see is expected behaviour.
Using vtimer_usleep should put the calling thread to sleep (if the delay is
high enough to not cause spin-locking). Could you try that with a fairly
high sleep time (e.g., a second)?
Kaspar
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
