Hi,
I think I didn't get that you're doing a new port. I was assuming that
general kernel initialization, task switching etc. was working (e.g.,
the applications in test/ do what they're supposed to do.
On 02/09/15 19:33, Murat CAKMAK wrote:
According to your explanations (Interrupting with ISR or higher
priority), RIOT works like as a single thread application.
This is a design philosophy of RIOT.
The main idea is that in an embedded OS, dividing the CPU into time
slices poses an addidional task switching (and thus power consumption)
overhead that is not needed if there's no user that needs the impression
of things happening at the same time.
I would expect a context switch mechanism for a quantum value even if
threads have same priority.
... as it is being done on standard time-slicing schedulers like on most
preemptive operating systems.
But most applications spend most of their time waiting for either IO, a
timer, user input, ... Those apps will be preempted during their waiting
periods, yielding for other threads.
Your simple example (delaing, toggling an LED) will work as expected if
the delay function is changed into something that yields, as soon as the
scheduler is running correctly.
Only if you're busy-waiting, which is inefficient on any system, equally
or lower prioritized threads might starve.
That said, it is fairly easy to implement time-slice based task
switching for a given priority if it really should be needed for a
specific application.
Kaspar
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
