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.
Our offer: Send us the required hardware IDs and we will insert them into the INF file, making them signed by the CAT file in the process.
Please note: exception and solution
Yes, Kithara RealTime Suite includes a C# class, which exposes the API of Kithara RealTime Suite. Using this class it is possible to utilize the entire range of functions with a C# application. However, parts of the program, which contain real-time capable code, have to be provided in a DLL using native machine code (x86 or x64) as produced by C/C++ or Delphi. In order to keep this stage of development as simple as possible we deliver a project template, which shows how to do so. This project file can be used immediately for own developments.
In principle, it is possible to use our software with VB6 . 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.
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 behavior in time still depends on the Windows scheduler. But 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++ or Delphi and moved into a DLL file, so that it can be loaded directly into 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 example 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 certainly a driver is responsible for this. In this case the respective driver has to be replaced. Because it is difficult to determine it we offer payed help on such cases by our support team.
WBINVD = command to flush the entire internal cache.
According to experience, only Nvidia graphic drivers cause such and should be replaced with an ATI (AMD) graphics card.
C1E = Enhanced Power Save Mode of the CPU.
Especially, the overdeveloped Intel CPUSs (i7, Xeon, …) switch to idle mode after short breaks, delaying the wake up after a timer interrupt up to several milliseconds.
This can be switched off in the BIOS (see CIE or similar) or the PC is not real-time capable.
Ordinary Windows activities cannot replace real-time tasks.
Windows has the priority 0, whereas the RealTime tasks have priorities from 1 to 255. DPC has no influence.
- To achieve the best real-time behavior use the dedicated mode, which supports the exclusive use of single CPU cores in real-time. Without Windows influence the maximum jitter will be less than 1 us.
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 Mode it is possible to keep single or multi CPU cores free from 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.
We distinguish 3 different combinations:
- 32 bit applications on a 32 bit Windows
- 64 bit applications on a 64 bit Windows
- 32 bit applications on a 64 bit Windows
Case 1) and 2) are trivial and aren't discussed here.
For case 3) we suggest the following solution:
Move the part of your functions with real-time requirements into an own DLL.
Using our KiK64 mechanism you will be able to call those functions from your application, even if your application is developed for 32 bit and the DLL is developed for 64 bit as required in case of an 64 bit operating system.
For details about the KiK64 mechanism see
White Paper: Future-Proof Architecture with Kithara RealTime Suite .
Yes, Kithara DOS Enabler enables hardware-dependent DOS and 16 bit Windows programs to work under Windows 10.
32-bit and 64-bit systems are supported.
Kithara DOS Enabler has its own DOS-System (FreeDOS) and executes the 16-bit applications native on a dedicated CPU core.
By the elimination of any impacts of the Windows system time-critical applications are possible.
For programming hardware-dependent and time-critical 32-bit and 64-bit applications see Kithara RealTime Suite.
Yes, with the XHCI/USB3 module it is possible to access XHCI-controllers directly, which enables realtime communication with USB 3.0 devices (e. g. USB3 Vision cameras).
Callback, Signal, and Kernel Code
Signaling an already signaled event has no effect at all.
If an event gets signaled the consumer of the event will reset the signal automaticly by consuming the event, if the event is an "auto-reset-event" (default).
If the event is created by
KS_createEvent with the flag
KSF_MANUAL_RESET it will not become an "auto-reset-event".
In this case the consuming of the event will not reset the signal, which has to be done by a call to
This allows for multiple consumers to react to the event.