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
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
Hi All,
I am trying to porting RIOT to PsoC 5LP device.
For a single thread everything looks like good but when I create a different
thread, I could not see any context switching.
I created two threads which change led states. Threads are;
static void *led3Thread(void *arg)
{
Hi again,
On 09.02.2015 14:33, Kaspar Schleiser wrote:
Hi Joakim,
On 02/09/15 14:20, Joakim Gebart wrote:
Has anyone measured the cost of the thread context switching on the
different platforms? I'm mainly interested in Cortex-M4 (Kinetis). This
would be a good indication of how "slow" an I/O
Hi,
we do indeed have a number of places in the driver code, where busy
waiting is used. The reason for this is mostly missing man power to
implement better versions of the same driver. The most important fact
here is, that you can re-implement a driver in a more efficient way
completely tran
Hi Joakim,
On 02/09/15 14:20, Joakim Gebart wrote:
Has anyone measured the cost of the thread context switching on the
different platforms? I'm mainly interested in Cortex-M4 (Kinetis). This
would be a good indication of how "slow" an I/O device has to be before
it is worth it to manually yield
I was actually writing on a post for this list along the same theme when I
saw your message. The main reason I see for removing the busy waits is that
you can lower the power consumption if you can let the CPU core sleep while
the peripheral is working, either using interrupts or DMA for the transf
