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.
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.
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.
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
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
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
There are some things defined there in addition:
little/big endian defines, processors are different.
C++-keyword for C-usage, especially
The macro METHOD_C which maybe
extern "C" or not.
MemUnit-type. It is the type which describes one element in the address spaces. It is not a
char anytime, not in Signal-processors.
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.
The following documentation is generated directly from the header files: