3

I am trying to learn an RTOS from scratch and for this, I use freeRTOS.org as a reference. I find out this site as a best resource to learn an RTOS. However, I have some doubts and I was trying to find out but not able to get exact answers.

1) How to find out that device have Real-time capability e.g. some controller has (TI Hercules) and other don't have(MSP430)?

2) Does that depend upon the architecture of the CORE (ARM Cortex-R CPU in TI Hercules TMS570)?

I know that these questions make nuisance, but I don't know how to get the answer of these questions.

Thanks in advance

EDIT:

One more query I have that what is meant by "OS" in RTOS? Does that mean the same OS like others or it's just contains the source code file for the API's?

Shaswat Dube
  • 93
  • 1
  • 4

5 Answers5

3

Real-time capability is a matter of degree. A 32-bit DSP running at 1 GHz has more real-time capability than an 8-bit microcontroller running at 16 MHz. The more powerful microcontroller could be paired with faster memories and ports and could manage applications requiring large amounts of data and computations (such as real-time video image processing). The less powerful microcontroller would be limited to less demanding applications requiring a relatively small amount of data and computations (perhaps real-time motor control).

The MSP430 has real-time capabilities and it's used in a variety of real-time applications. There are many RTOS that have been ported to the MSP430, including FreeRTOS.

When selecting a microcontroller for a real-time application you need to consider the data bandwidth and computational requirements of the application. How much data needs to be processed in what amount of time? Also consider the range and precision of the data (integer or floating point). Then figure out which microcontroller can support those requirements.

kkrambo
  • 6,643
  • 1
  • 17
  • 30
  • 32-bit DSP running at 1 GHz vs 8-bit microcontroller running at 16 MHz.... IMO it's true, especially in terms of capacity as you point out. I worked in a project where we implemented a 32-bit soft-core processor running at 50 MHz on a FPGA (also used for controlling some hardware with custom-made IPs) and it outperformed all other competitors in the validations made by the client, some competitors were using Linux running on ARM9 cores at ~400MHz. It was all a matter of application design and they improved performance to similar levels after making deep redesigns in their applications. – V.Lorz Jul 20 '21 at 10:41
3

Figuring out whether a device has a "Real-Time" capability is somewhat arbitrary and depends on your project's timing requirements. If you have timing requirements that are very high, you'll want to use a faster microcontroller/processor.

Using an RTOS (e.g. FreeRTOS, eCOS, or uCOS-X) can help ensure that a given task will execute at a predictable time. The FreeRTOS website provides a good discussion of what operating systems are and what it means for an operating system to claim Real-Time capabilities. http://www.freertos.org/about-RTOS.html

You can also see from the ports pages of uC/OS-X and FreeRTOS that they can run on a variety target microcontrollers / microprocessors.

Nate
  • 18,892
  • 27
  • 70
  • 93
  • @ShaswatDube : Don't ask further questions in comments - update your original question or ask a new question. – Clifford May 18 '15 at 09:04
3

While Cortex-R is optimised for hard real-time; that does not imply that other processors are not suited to real-time applications, or even better suited to a specific application. What you need to consider is whether a particular combination of RTOS and processor will meet the real-time constraints of your application; and even then the most critical factor is your software design rather then the platform.

Clifford
  • 88,407
  • 13
  • 85
  • 165
1

The main goal you want to obtain from an RTOS is determinism, most other features are already available in most other non-RTOS operating systems.

The -OS part in RTOS means Operating System, simply put, and as all other operating systems, RTOSes provide the required infrastructure for managing processor resources so you work on a higher level when designing your application. For accessing those functionalities the OS provides an API. Using that API you can use semaphores, message queues, mutexes, etc.

An RTOS has one requirement to be an RTOS, it must be pre-emptive. This means that it must support task priorities so when a higher-priority task gets ready to run, one of possible task states, the scheduler must switch the current context to that task.

This operation has two implications, one is the requirement of one precise and dedicated timer, tick timer, and the other is that, during context switching, there is a considerable memory operations overhead. The current CPU status, or CPU's in case of multi-core SoCs, must be copied into the pre-empted task's context information and the new ready to run task's context must be restored in the CPU.

ARM processors already provide support for the System Timer, which is intended for a dedicated use as an OS tick timer. Not so long ago, the tick timer was required to be implemented with a regular, non-dedicated timer.

One optimization in cores designed for RTOSes with real-time capabilities is the ability to save/restore the CPU context state with minimum code, so it results in much less execution time than that in regular processors.

It is possible to implement an RTOS in nearly any processor, and there are some implementations targeted to resource constrained cores. You mainly need a timer with interrupt capacity and RAM. If the CPU is very fast you can run the OS tick at high rates, sub-millisecond in some real-time applications with DSPs, or at a lower rate like just 10~100 ticks per second for applications with low timing requirements in low end CPUs.

V.Lorz
  • 293
  • 2
  • 8
  • 1
    There's a book about uC/OS-II [here](https://micrium.atlassian.net/wiki/spaces/osiidoc/overview?preview=/163892/164621/100-uC-OS-II-003.pdf), a bit outdated now, that provides a good background about RTOSes in general and uC/OS-II in particular. It also provides good explanations describing many implementation details. – V.Lorz May 09 '21 at 09:14
0

Some theoretical knowledge would be quite useful too, e.g. figuring out whether a given task set is schedulable under given scheduling approach (sometimes it may not), differences between static-priority and dynamic-priority scheduling, priority inversion problem, etc.

mangusta
  • 3,470
  • 5
  • 24
  • 47