CRuntimeJavalike - OSAL

Topic:.OSAL.

pStyle=std tableStyle=stdTable

OS-independent programming

Some programmers work for their project. It may be running on a special hardware with a special operation system, mostly a RTOS (Real Time Operation System). The tests are executed at the target hardware - reality tests. Thus the thought is C is not C, any target system needs its own slang (dialect).

What is missing? Compilation of the sources with a proper Integrated Development Environment (IDE). On the PCs, there are some good IDEs, such as Eclipse, Microsoft Visual Studio etc. Mostly, the IDEs for a special hardware are good, but not so good like PC-platform-tools.

What is also missing? Functional testing the algorithm. It isn't a real-time test. But it may be essential.

What is the effort? The algorithm in C need to compile in a PC-environment. It should be able to test, not in real-time, maybe only in one thread or more. For this reason the OS-functionality should be able to use at the test-environment.

What is the result:

• Well functional tested algorithms

• Faster writing, reorganization, optimizing and gardening of sources, because the PC-platform is able to use for faster work.

• Better sources.

The tests on the target-platform are reduced to test the real platform problems, not to test the algorithm basically.

Need of special Operation System capabilities

Most of the Operation Systems are similar in a large way of thinking. All of these support multi-threading, with mutex etc. Most of them have a file system in a adequate kind etc.

The differences are: They should be support the hardware platform with different processors, different equipment in RAM, ROM, different I/O. But the user programming shouldn't consider all of them so far. The user programming should be realized in a more abstract shell. This means the RTOS should be proper for the hardware, but it should not have to much special features for the user programming. It may be useful only for driver or interrupt-level-programming.

Conclusion: The user programming should use unified interfaces to the operation system.

Topic:.OSAL..

pStyle=std tableStyle=stdTable

Programming in Java is OS-independent in the first way. In that mind, the CRuntimeJavalike needs a Operation System Adaption Level (OSAL).

The given OSAL is layered closed to a not-only Java-like-programming. It supports standard C functionality. The typical Java-like functions like ThreadJc based on this OSAL-interface.

A first idea in the past was to introduce the OSAL-level in the OS-oriented classes like ThreadJc, ObjectJc with its synchronized_ObjectJc-methods etc. But a Java-independent definition of the OSAL-interface provides some use-cases for the non-java-like-oriented programming, too. So it is implemented independently from Java-like-C-classes.

Topic:.OSAL..

pStyle=std tableStyle=stdTable

An interface in C-language is established in header-files. Most of compiler-tool-associated header-files declare the same things, but in their own files in a maybe different form. So the risk of little differences are given.

Instead all OS-interface-functions should be declared in the same header-files, independent of the current used operation system. The implementation of the OSAL should use this files and adapt their OS-functions.

All of those OS-independent common header files are declared in the folder CRuntimeJavalike/OSAL/inc. The current file list is:

os_adapter.h
os_endian.h
os_file.h.bak
os_mem.h
os_serror.h
os_socket.h
os_sync.h
os_time.h.bak
os_waitnotify.h
os_error.h
os_file.h
os_thread.h
os_AtomicAccess.h
os_time.h

Topic:.OSAL..

pStyle=std tableStyle=stdTable

Some things should be declared or defined in a OS-specific way. The same things should be defined in a different kind, appropriate to the operation system and the compiler properties.

The most important file doing this is the os_types_def.h. The same file-name is used in different directories, all specific for OS and compiler. It defines the same things in a different way.

The most noticeable property is the definition of the OS- and compiler-depending definition of fix-size-integer types. The C99-standard suggests the usage of int32_t etc. But most of the programmers had created their own standard before or simultaneous to the C99-Standard. These types are present in many sources. They are defined in some special headers like standard.h, which is anytime mystandard.h. These types are defined in the os_types_def.h.

There are some things defined there in addition:

• little/big endian defines, processors are different.

• C++-keyword for C-usage, especially bool, true, false.

• The macro METHOD_C which maybe extern "C" or not.

• A MemUnit-type. It is the type which describes one element in the address spaces. It is not a char anytime, not in Signal-processors.

Topic:.OSAL..

pStyle=std tableStyle=stdTable

There are some things, which may defined in a good C-design able to use for the OSAL-level too. This C-basics are provided OS-independently in the following files (definition and implementation):

fw_Exception.h
fw_Exception.c
fw_LogMessage.h
fw_LogMessage.c
fw_Va_list.h
fw_formatter.c
fw_Formatter.h
fw_SimpleC.c
fw_SimpleC.h
fw_MemC.h
fw_MemC.c
objectBaseC.h
fw_Object.c
fw_timeconversions.h
fw_timeconversions.c
fw_ThreadContext.h
fw_String.h
fw_threadContext.c

This so-named framework-level is independent from the OSAL-adaption and it is ready to use for the OS-adaption.

Topic:.OSAL..

pStyle=std tableStyle=stdTable

see os_thread.h