Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Kernel Processing time on PIC32

Posted by KAMAZ187 on September 23, 2009
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

RE: Kernel Processing time on PIC32

Posted by KAMAZ187 on September 25, 2009
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

RE: Kernel Processing time on PIC32

Posted by Richard on September 25, 2009
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.

RE: Kernel Processing time on PIC32

Posted by KAMAZ187 on September 25, 2009
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

RE: Kernel Processing time on PIC32

Posted by John Smith on September 26, 2009
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.

RE: Kernel Processing time on PIC32

Posted by Richard Damon on September 27, 2009
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.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists