@CHIP-RTOS - SC1x3 RTI Rate Adjustment

    IPC@CHIP® Documentation Index

RTI Rate Adjustment on SC1x3/SC2x

The SC1x3/SC2x Real-Time Interrupt (RTI) rate can be increased above its default rate of 1 kHz up to a maximum rate of 50 kHz.   This configuration is controlled by the CHIP.INI file "[TIMER] RTI" entry.

When to use a higher RTI rate

For applications that require higher resolution scheduling it makes sense to raise the system's clock interrupt rate.   The following additional C-library functions can then be used to take advantage of the resulting increased scheduling resolution.

Task Scheduling

RTX_Sleep_Fine - Sleep a specified number of RTI
RTX_Sleep_Long - Sleep a specified long number of RTI

High Resolution RTX Timers

RTX_Fine_Timer - Creates a high resolution timer
RTX_Fine_TimerP - Creates a high resolution timer based on parameters
RTX_Timer_Delay_RTI - Specifies delay to next timer callback in RTI ticks

When not to use a higher RTI rate

If your application needs an accurate sense of time, this alone is not a justification for increasing the system's real-time interrupt rate.   The system time resolved to microseconds is available from the C-library functions.   These functions are available on all @Chip-RTOS platforms and they do not require that the real-time interrupt rate be raised above the default 1 kHz rate.

High Resolution System Time

RTX_GetTick_us - Get system time with microsecond resolution
RTX_GetFineTick - Get high resolution system time

CPU loading considerations with higher RTI rate

It should not be surprising that the load placed on the CPU increases when the RTI rate is increased.   What loads down the CPU in particular is when tasks or RTX timer callbacks become due at a high rate.   For example if a timer callback is scheduled for each RTI tick, then the CPU quickly becomes swamped by this activity alone as can be seen by the example measurements in the table below.

On the other hand, a high RTI rate with sparsely scheduled tasks does not load the CPU that much.

The following table of measurements may help provide a general idea what rates of activity you can expect to achieve when raising the system's RTI rate.   These measurements were made with the Debug@Chip PROBE executing concurrently with a simple test program which installed an RTX timer to be called at specified RTI tick intervals.

RTI Rate      Idle      2 ticks      1 tick
-----      -----      -----      -----
1 kHz      5,5%      7,7%      9,4%
2 kHz      5,7%      9,7%      13%
5 kHz      6,1%      15%      25%
10 kHz      6,6%      24%      42%
15 kHz      7,6%      33%      59%
20 kHz      8,0%      43%      77%
30 kHz      9,5%      61%      dead
40 kHz      11.0%      71%      dead
50 kHz      12,5%      93%      dead

The Idle column in the table indicates the load with only the debugger's PROBE executing prior to starting the test program that operates the RTX timer.   The "2 ticks" column is for the case where the timer interval is set to two RTI ticks.   Likewise, for the "1 ticks" column the timer callback is execued on every RTI tick.

Note that you can configure a system which will appear to not start (from a TCP/IP point of view) by setting the RTI rate high enough and starting a program from the AUTOEXEC.BAT which configures a timer at too high a callback rate.   This was the case for trials in the above table where a "dead" indication appears.   So some care will be required when operating at higher RTI rates.

C-Library RTX Timing API

End of document