Hi All!

I am very new to using a RTOS. I am investigating a possibility of using a FreeRTOS for the future projects in our company as it has been recommended to us.

Having almost fully read the "Using Free RTOS..." book I have got a question for you. If in one of our projects we had to process a very fast interrupt (by fast I mean that it could occur very frequently) and we also wanted to still use the RTOS API functions it would have to be defined at a priority lower than the Kernel. This means that jitter will be intoduced to the ISR processing. Can anybody tell me what this jitter is going to be on a PIC32 processor (in clock cycles)?

I am just trying to evaluate how likely it is that we would have to configure that interrupt at higher priority than the Kernel and not use the API.

Thank you in advance,

Konstantin

Hi again.

It has been now three days since I put this post on the forum and nobody has replied.... Could you at least tell me why? Is my question not appropriate and/or not well structured?

I have also seen that there are performance stats available for each port, but for the PIC its only the pic18 that I have managed to find information on. Is there any official data for the FreeRTOS performance on PIC32?

Thanks,

Konstantin

The PIC32 itself disables interrupts when an interrupt is taken, and you have to process a few instructions before you are able to enable interrupts again. If you look at the code you will be able to count the number of instructions between interrupt entry and interrupts being re-enabled and therefore work out the time - but I can tell you that its in the order of a couple of hundred nanoseconds. This time is only for interrupts of higher priority than the currently executing interrupt though. You could decrease the time by removing interrupt nesting support (this fact is one of the reasons why comparative performance stats are normally meaningless as nobody actually measures the same thing).

As to your actual question about how long equal or lower priority interrupts could be masked by critical sections, I'm afraid I don't have those numbers. Such numbers are generated for SafeRTOS ports, but not FreeRTOS.

Regards.

Thank you Very much for the reply. I have now finished reading the book about FreeRTOS and am in the process of experimenting with the functions and trying out the features. I am impressed by the simplicity of use of the API functions and am pretty certain that our company is going to use FreeRTOS on our new projects.

I am also interested if there is any difference between the FreeRTOS and OpenRTOS in terms of the number of API functions available, speed, reliability, etc. Or is it just the licensing?

Kon

Richard, are there any places inside the FreeRTOS kernel where interrupts are disabled for longish periods? I understand why it is sometimes necessary to do this, but if all these sections of code are very short then this will have negligible effect on interrupt latency.

While Richard would need to confirm this, I believe the design policy of FreeRTOS was to minimize the periods of interrupts being disabled, even if it might require a somewhat slower algorithm. For the longer periods when he needs to avoid a reschedule, he uses another method of disabling the scheduler, and checking for issues when the scheduler is restarted.