FAQ

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

No. Since Microsoft discontinued certification for Windows 7, we are also unable to provide updates for it. A more detailed explanation can be found here.

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.

By dedicating CPUs to Kithara RealTime neither Windows nor other software running in Windows context will have any impact on the real-time behavior of the system.
However, different hardware can have better or worse real-time capabilities and especially configuration options of the BIOS/UEFI can have an impact on the real-time capabilities.

• C1E = Enhanced Power Save Modes of the CPU.
  The power save modes of modern CPUs make the CPUs switch to different sleep modes very rapidly, unpowering different function blocks of the CPU. Waking the CPU from those sleep modes takes time and will introduce latencies.
  For the best real-time experience, all power save modes should be deactivated.
  You will find those options (depending on your BIOS/UEFI) at
  • C1E
  • C-States
  • Deeper C States
• SpeedStep
  The power save options of modern CPUs will make the CPUs switch to lower frequencies on idle. Recovering to higher frequencies on demand takes time and will introduce latencies.
  For the best real-time experience, dynamic frequency changing should be deactived.
  You will find those options (depending on your BIOS/UEFI) at
  • EIST
  • SpeedStep
  • Turbo Boost
  • PowerNow!
  • Cool'n'Quiet
• Legacy USB Support
  From our experience, this option can (depending on UEFI implementation) have bad impact on the real-time capabilities, it should be deactivated.
• Hyperthreading / Simultaneous Multithreading (SMT)
  In most cases, hyperthreading should be deactivated to ensure full access for each 'logical' CPU to the physical CPU resources. See the corresponding note at Dedicating CPUs to Kithara RealTime.
• WBINVD = Assembler instruction for clearing all internal caches.
  This instruction is used, for instance, by Nvidia graphics device drivers. This problem can only be solved by avoiding software utilizing this instruction. For device drivers, only a switch to different hardware with drivers not using this instruction will help.

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:
 

1. 32 bit applications on a 32 bit Windows
2. 64 bit applications on a 64 bit Windows
3. 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 USB RealTime Module it is possible to access xHCI-controllers directly, which enables real-time communication with USB devices (e. g. USB3 Vision cameras).

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  KS_resetEvent.
This allows for multiple consumers to react to the event.