Why is RTOS encoded only in c?

Question

Do I always need to encode RTOS in C? Why can't it be encoded in Java or any other technology. ?? Is it due to the lack of a pointer concept in java?

Answer 1

Garbage collection is a big reason Java is Real Time. JIT is different, but it can be overcome.

In general, however, C is an efficient portable assembly that provides very predictable runtime performance and is necessary for reliable, real-time execution.

Answer 2

Real-time systems can also be programmed in other languages. For example, Java has a Java RTS System .

Unlike other answers, there is a reasonable job of collecting garbage in real time. However, they do not fall into your typical distributions.

The problem is that other languages ​​usually have functions that make determinism and reliability difficult to achieve, such as traditional garbage collection, JIT, run-time optimization, etc.

Answer 3

At first, RTOS is not just encoded in C. They can also be encoded in other languages. However, the language used for RTOS should offer deterministic behavior. This means that the wait time for a particular action should always be for a certain period of time. This eliminates, for example, garbage collection, which in most implementations will stop all threads from executing indefinitely.

Answer 4

Since RTOS developers most likely do not know C ++ well enough.

C ++ in embedded systems: myth and reality

Some people think that C ++ has overhead and costs that make it somehow unsuitable for embedded programming systems, that it lacks control and C brevity, or that although it may come to some kind of application niche, it never will not supersede C as the language of choice for embedded systems.

These perceptions are erroneous. where compilers and other tools are adequate, C ++ is always preferable to C as an implementation language for embedded systems. By doing everything C does, it offers more options for expression, encapsulation, reuse, and even improves the size and speed that are impractical in C.

Why, then, are these perceptions preserved? The main reason is that when people form their opinions, they know much more about C than about C ++. They have read several books written with some code and are competent in using the features of C ++, but they lack knowledge of what is happening in the hood, an acquaintance that allows one to visualize disassembly during text input or even design wording.

Recommendations for using C ++ as an alternative to C in embedded projects

Embedded software applications are most often written in C. Over the years, C ++ has been seen as a natural successor and found greater acceptance, but its increased use was much slower than expected.

There are several reasons for this. Firstly, embedded developers are quite conservative and prefer to use proven solutions, rather than new ones "if it does not break, do not fix it."

There is also a lesson in experience. Many developers tried to use C ++ for embedded applications and failed. Such crashes can sometimes be attributed to flaws in the development tools, but more often than not, it is the misuse of the language “looking at an embedded system such as a desktop computer”, which is to blame.

Limitations of C Although C is widely used, it has limitations because it is not intended for embedded applications or for projects of scale, which is now a common occurrence. Key limitations include:

1) C is extremely powerful and flexible and therefore can be dangerous (it has a low level of capabilities that are useful to the built-in, but also pose many errors for the careless.)

2) Programmers must be very methodical and disciplined.

3) Programmers must understand how the program behaves at low and high levels (large projects are therefore difficult to maintain)

4) Programmers require expert knowledge of the application

However, C ++ has powerful object-oriented features that can greatly help with removing C restrictions:

1) it encapsulates and hides areas of high experience from non-specialists in “objects”; (A test case will demonstrate the encapsulation of experience later in Part 2 in this series).

2) Objects can be used intuitively by lay people for the implementation of conceptual projects at a high level

Answer 5

• The presence of highly optimized c-compilers for all equipment on which RTOS interfaces usually work.
• The relative ease with which you can include very low levels of optimization in c-code.
• The presence of c-code for a large number of useful low-level system tools, which therefore can be easily turned on.

Answer 6

Not "necessary", but much more practical

One could use Java as the language, and in fact various crazy cases occur.

But a few cases and demonstrations in the form of superfluous cases are really more of an "exception (s) that proves the rule."

In general, Java is a large, complex system designed for business logic, not OS kernels.

If we did not already have C, Java could develop in a different direction or in several directions.

But we have C, which is almost perfect for the kernel of the OS and is a rather difficult task for business logic.

Arguments that Java is as good as it is for the kernel are as realistic as arguments that C is as good as Java for applications. Experience, minus a few additional examples, overwhelmingly proves that it is suitable for each language.

Answer 7

By definition, RTOS must support deterministic planning and execution. In general, low latency interruptions and direct access to hardware are also a desirable factor. Technologies used in Java, such as garbage collection, JIT compilation, and byte code execution, make it difficult to achieve these goals.

Java can be used in real-time systems, but it usually works in RTOS, rather than being used in its implementation.

All that was said would equally be wrong to assume that RTOS is always implemented in C. Any system-level language would be suitable, including assembler. In most cases, at least part of the kernel will be in assembler anyway. C ++ would be a suitable language (quite obvious, since it is essentially a superset of C), many commercial RTOS have C ++ wrappers anyway; I usually design C ++ abstraction layers for RTOS to support portability.

Another reason C is commonly used is because the C compiler (often C / C ++) is usually the first and often the only language (other than assembler) available for the new architecture (often these days in form GNU Compiler Implementation). Therefore, if you want to be able to port RTOS to the largest number of platforms, it makes sense to use the most common language.

Answer 8

I think the biggest problem with java for this purpose is automatic garbage collection. Here is a link about creating real-time systems in java.

Answer 9

Because C-based OCPs are well known and have been used for decades. Their behavior is predictable for many specific situations, and you can find many experts to develop with these systems.

I do not know that Java-based RTOS has reached such a level that a company making critical applications in real time would accept it.

Technically, there is no argument against Java-based RTOS, but research, development, and products on this issue have not yet matured.

Answer 10

Real time in Java, but this requires OS support. See: http://java.sun.com/javase/technologies/realtime/index.jsp

Answer 11

Do I always need to encode RTOS in C?

Not. You can also code RTOS in assembler, Ada, and some others.

Why can't it be encoded in Java or any other technology .. ?? Is it due to the lack of a pointer concept in java?

Not. Unpredictable code execution time.

Answer 12

C was designed to write operating systems, so the general wording is "portable assembler", so you should expect that it is used for this purpose.

If you want to have Java in real time, Sun has a commercial offer.

Answer 13

Anyway, this is because of pointers. In Java, everything except the main data types is allocated on the heap, and any variable that does not look like an int is a pointer. This is not a good way to write an operating system, since it imposes one layer of indirection on most operations, and in an OS record this layer can kill you.

The kernel of the OS is the place where you want to optimize and improve performance, because you do not know what will work on it. This is especially true for real-time operating systems, in which a delay in milliseconds can be critical. This requires special interest in the processor and other equipment, as well as the ability to write highly optimized code that will perform specific things with great predictability.

For this reason, C is a very good tool for building the RTOS kernel, but Java is not. This does not mean that you could not do this with Java, but it would be more difficult and probably not so successful.

I am curious why you are asking a question. If you use RTOS, it really doesn't matter what it was written to. If you want to hack one, it matters what it was written for, but the concepts and implementation of the OS are quite complex in themselves, learning a new language is trivial to learn. (Moreover, if you study the design and implementation of the OS, you will almost certainly find that the resources you use will use C as a learning language.)

Answer 14

RTOS is not always written in C. This is usually the case, but in ThreadX I believe that they use assembly.

Answer 15

A garbage-collected language such as Java is very unsuitable for real-time programming. The reasons for this should be obvious.

Answer 16

Do I always need to encode RTOS in C?

Not. For example, RTOS is written to Lisp or Smalltalk.

Why is it impossible to code in java or any other technology.

What makes you think it's impossible?

Is it due to the lack of a pointer concept in java?

No, this is because there is a myth that operating systems can only be written in C. A myth that can be trivially proven false, but still refuses to die.

This myth is so widespread that people who want to write a new OS are just too afraid to try anything other than C.