这个网站需要JavaScript

常见问题：

General

Yes, our real-time drivers - in general, all our installation and application files - are already signed. Especially, for 64 bit systems this is compulsory required to use the software correctly. However, a signed driver shows reliability.

That implies also that our software can simply used as a driver for your PCI/PCIe or USB device. For this reason, the included INF files have to be upgraded by an entry on the documented way. This is even needed to address hardware safely on every system.

In principle, it is possible to use VB6 to use our software. But since VB6 is very old now, there are only a few sample programs. The main goal of our software is to offer libraries for implementing "real-time under Windows". This can only be done on the kernel-level of Windows. So, languages that can run on the kernel-level are needed. Those languages are currently only C/C++ and Delphi. For many examples, we also support C# projects, because it is possible to program the main application in C# and put only the time-critical parts into a DLL written in C++.

If you would use VB.NET, then it would be easy for you to use the C# interface. But still it would be necessary to program a DLL written in C or C++ for time-critical code. If it is not time-critical (real-time), then you could stay on the application level and write everything in C# or VB.NET.

Even if it would be possible to program in VB6, we do not recommend this, because VB6 is not capable to execute multi-threaded applications properly. The same occurs for OCX, so it should be clear why we do not made any attempt to develop OCX components.

Real-time System

Windows itself is not a real-time system. In order to achieve real-time features, it is necessary to execute time-critical code in a real-time context (at kernel level).

Due to the fact that in a .NET environment C# can not be executed in real-time, the behvior in time still depends on the Windows scheduler. Thus, it is possible to assign the time-critical C# threads the absolute highest thread priority. Previously this was not possible for programmers. For this reason, Kithara provides the respective mechanisms. At least, the mechanisms can ensure that the application takes priority over all other Windows applications.

For true real-time behavior the essential code should be programmed in C++ and swapped in a DLL file, so that it can be loaded directly in the real-time context.

For communication between application and real-time context shared memory, data or messages pipes, events, or sockets are available. A number of examples projects are included to show how "hard" real-time can be embedded in C# applications.

As long as no other real-time software or similar system-critical software is installed, (almost) nothing exists, which interrupts or delays the real-time task except:

- CLI = general interrupt blocked through Windows and drivers

(unfortunately, no software can do something against it; However, in Windows the blocking time is limited and almost the driver is responsible for this; in this case the respective driver has to be replaced; it is difficult to determine it, thus only possible by our support (in return of payment).

- WBINVD command to flush the entire internal cache

(according to experience, only by using Nvidia graphic drivers; only by replacement of the card with an ATI (AMD) the problem can be solved)

- C1E = Enhanced Power Save Mode of the CPU

(especially, the overdeveloped Intel CPUSs (i7, Xeon, ...) turns into the idle mode after short breaks, so that the wake up after a timer interrupt can take several milliseconds; that can be switched of in the BIOS (see CIE or similar) or the PC is not real-time capable.

Ordinary Windows activities cannot replace real-time task. Windows has the priority 1, whereas the RealTime tasks have the priorities from 1 to 255. DPC has no influence.

To achieve the goal to improve the real-time behavior, only the Dedicated Mode, which supports the exclusive use of single CPU cores in real-time. Without Windows influence the maximum jitter is less than < 1 us.

Porting

Yes. However, Windows 10 x64 has the so called 'Kernel Patch Protection' in order to restrain access to the OS. Thus, the code execution of real-time tasks on CPU cores, which are also used by Windows, is not possible.

Nevertheless, by using the Dedicated Module it is possible to keep single or multi CPU cores free by the Windows OS (further information). In this case, the Kithara real-time system is booted exclusively on the respective CPUs. That enables real-time on a Windows 10 x64 systems with the best real-time features.

One version of our software only supports 32 bit applications on a 32 bit Windows. An extended version also supports to run 64 bit application on a 64 bit Windows.

If 32 bit applications should run on a 64 bit Windows, then the so called “KiK64” (Kithara32-in-Kithara64) is required. This is a special extension to support executing 32-bit code within the 64-bit real-time context. Thus, the KiK64 enables by only one 32-bit application all Windows systems (32 and 64 bit).

For comprehensive and challenging projects it should be noted though, that often a conversion between 32 and 64 bit addresses (code and data) takes place. For a better run-time behaviour it is strongly recommend running rather native 64-bit applications on a 64-bit system.

If you have any questions concerning this topic, feel free to contact us.

Yes, the new »DOS Enabler« enables hardware-dependent DOS and 16 bit Windows programs to work under Windows 7, 8/8.1. 32-bit and 64-bit systems will be supported. The new »DOS Enabler« has its own DOS-System (FreeDOS) and perform the 16-bit applications native on a seperate CPU core. By elimination of any Windows-effects time-critical applications are possible.

Notice: For programming hardware-dependent and time-critical 32-bit and 64-bit applications see »RealTime Suite«.

Callback, Signal, and Kernel Code

If a KS_setEvent selected again, eventually the already selected event still persists (1x). The reaction to that depends on, whether the event is a "auto reset" (default) or a "manual reset" ( by KSF_MANUAL_RESET at KS_createEvent) event.

At a "auto reset" event at most one waiting thread is released and in the case of the release, the event is subsequently reset automatically. A "manual reset" event remains as long as it is reset by KS_resetEvent. Thus, it is also possible to release several waiting threads. The "manual reset" event is like a gate, which after specification let pass any number of threads until the gate is closed again.