RTOS realtime

From the real-time RTOS selection considerations

As we all know, real-time operating system, real-time performance is mainly reflected in two aspects, one for the system the ability to respond to interrupts, the other for the system the ability to respond to API. We judge a RTOS real-time, requiring a combination of these two aspects to consider.

In order to improve interrupt response time, we need to minimize the interruption in the operation of RTOS against time. But the speed of system response API, we need to run the RTOS to ensure that the API, the associated API function has run out or their behavior does not affect the operation of the API, then the guarantee of this phenomenon will no doubt need to run the API, with a certain degree of atomicity. And this atomicity, and flag can not be guaranteed, because by judging the flag to reflect the atomic operation if there is a consequence of the end is that if the atomic operation is not finished, then the system will suspend the currently running the API, return to atomic operation the scene, which undoubtedly affected the API response times. So more of this atom is determined by prohibiting interrupts to guarantee.

In this way, both for real-time nature of their mutual opposition to each other, and for specific RTOS, should be based on its location is different, they have different emphases. If several spread wider RTOS, UCOS-ii focus on the interruption of the system API call response speed, while the RTX is completely the opposite, more of its consideration is interrupt response time, the same phenomenon appears in the COOCOX OS on.

Therefore, in considering the RTOS selection should be based on their application environment needs to choose a different RTOS.

The attached several popular RTOS's website:
UCOS-ii http://www.micrium.com/
RTX http://www.keil.com/
COOCOX OS http://www.coocox.com/
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!