Hi, I played around with your OS a little bit and I like it – it is a compact neat OS. Anyway I think I have some problems with its performance. I would like to use it for the non time-critical tasks of my application, the time-critical tasks should be handled by interrupts. The problem is that these interrupts should be serviced very quickly. So I spent some time with excessive performance-testing of the OS in the simulator. For that I adapted the demo application so that only the flash tasks and two more self made tasks were running. I found out that a context switch from the system tick needs quite a lot calculation time – in my case about 540 cycles without switching tasks, and 2200 – 3000 cycles when it switches tasks. Also a queueSendFromISR takes about 330 cycles. For me this is a problem because during this time all interrupts are blocked. I can cope with 500 cycles without interrupts, but 2000 cycles are far too much. I learned a lot from reading the source code, but anyway I did not understand the context switch procedure. I just found out that vTaskSwitchContext() takes quite long. What tweaks do you know to reduce the time of blocked interrupts? I do not even need a fast context switch, but I really need my interrupts. greets, Adi Schwarz

sorry for the double post

Hi, <snip> > I found out that a context switch from the system tick needs quite a lot calculation > time – in my case about 540 cycles without switching tasks, and 2200 – 3000 > cycles when it switches tasks. Also a queueSendFromISR takes about 330 cycles. This is very dependent on: + The target architecture + The compiler + Optimisation levels. + The current system state. The architecture and chosen compiler make some ports more efficient than others.  Which port are you using? > For me this is a problem because during this time all interrupts are blocked. > I can cope with 500 cycles without interrupts, but 2000 cycles are far too much. The scheduler locking mechanism is designed to minimise the amount of time that interrupts are left disabled – but both circumstances you mention are referring to actual interrupt service routines.  Again the kernel is designed to minimise the length of the scheduler tick (with respect to comparable systems), but as you say interrupts are, by default, disabled for this period. As downloaded the demo applications and ports do not support interrupt nesting.  This is because in nearly all cases this is not necessary and adds complexity.  However in your case it may be what is required.  How easy this is depends again on the target architecture.  What it involves is keeping a count of the interrupt nesting depth, and then only performing the context restoration when the nesting has completely unwound.  It sounds easy but there are a few gotchas. With respect to the queueSendFromISR – it may be that you can get away without using this.  It depends on your particular requirements. <snip> > What tweaks do you know to reduce the time of blocked interrupts? I do not even > need a fast context switch, but I really need my interrupts. Reducing the tick frequency is a good start.  This does not solve your problem however.  Think about using the cooperative scheduler for background tasks. If you can let me know a little bit more about your system and your architecture/compiler, then maybe I can make some suggestions? Regards.