IPC@CHIP® RTOS-PPC – API Documentation
The @CHIP-RTOS-PPC Real-Time Interrupt (RTI) rate can be increased above its default rate of 1 kHz up to a maximum rate of 500 kHz. This configuration is controlled by the CHIP.INI file [TIMER] RTI entry.
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.
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 do not require that the real-time interrupt rate be raised above the default 1 kHz rate.
It should not be surprising that the load placed on the CPU increases when the RTI service 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 _DBG PROBE task executing concurrently with a simple test program which installed an RTX timer to be called at specified RTI tick intervals. Most of the measurements are made for kernel timer callbacks operating in User mode. The measurements in parenthesis were made with the kernel timer callbacks operating in Supervisor mode. As can be seen here, the Supervisor mode callbacks place slightly less load on the computer than do the User mode callbacks.
The Idle column in the table indicates the load with only the system tasks 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 executed 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.
Also it must be noted that the system can require significantly more time to service the RTI than the above table indicates when the instruction and data cache hit rate is lower than on the nearly idle test system which these measurements were made. Applications which require a very high frequency front end will probably need to use some cache locking techniques which are beyond the scope of the @CHIP-RTOS-PPC API.
Operating the system with too high an RTI setting can result in the system resetting due to a Interrupt Request Blocks exhausted shut down fault.