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

Realtime capabilities of rtos - atmega128

Posted by Nobody/Anonymous on January 30, 2005
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


double post

Posted by Nobody/Anonymous on January 30, 2005
sorry for the double post

RE: Realtime capabilities of rtos - atmega128

Posted by Richard on January 31, 2005
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.


[ 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