davedoors wrote on Monday, September 27, 2010:
> Currently I am using a tick rate of 10000, but I have experimented with several
> different numbers.
The demos use 1KHz by default, and that is too fast. 10KHz is extremely fast. I doubt the kernel is doing much other than executing itself.
> Also, I notice that the scheduler ISR xPortPendSVHandler
> is in fact executed is called every tick
If configUSE_PREEMPTION is set to 1 then that is correct behavior.
> (and presumably whenever i call
No, it will never be called when portEND_SWITCHING_ISR is called, but portEND_SWITCHING_ISR will cause it to execute. This is described in post 2 of this thread. Also, if you look at the implementation of these functions and macros you will see that this assumption is not right.
> so I am lead to think that the problem is related to
> the semaphore/queue and/or how the scheduler decides that the task that was
> waiting for the semaphore is ready to run.
It works for everybody else, so either you have discovered a latent bug or the problem is in your own code. If you are using 10KHz and don’t understand how the macros work I think it is the later but am ok with you proving me wrong.
> Initially I measured the delay with a timer on the MCU, but I also checked using
> GPIO’s. I intended to measure on them using a logical analyzer, but in fact
> the delay on such a magnitude that it is easy to see without the analyzer, as
> the GPIO’s have LED’s attached to them.
I think the delay is likely to be because of the 10KHz tick. Do you have stack overflow trapping turned on?