Quality RTOS & Embedded Software

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




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) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

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

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

OpenRTOS and SafeRTOS