FAQ

Ja, unsere Echtzeittreiber – wie generell alle unsere Installations- und Programmdateien – sind bereits mit einer Signatur versehen. Vor allem unter 64-Bit-Systemen ist dies zwingend erforderlich, um die Software ordnungsgemäß verwenden zu können. Aber auch generell zeugt eine Signatur von Seriösität. Das bedeutet auch, dass Sie unsere Software ohne weiteres Zutun als Treiber für Ihre PCI/PCIe- oder USB-Hardware verwenden können. Die mitgelieferte INF-Datei muss hierzu nur in der dokumentierten Weise um einen Eintrag erweitert werden. Dies ist sogar erforderlich, um die Hardware auf allen Systemen sicher ansprechen zu können.

Unser Angebot für Sie: Schicken Sie uns die benötigten Hardware-IDs und wir fügen diese in die INF-Datei ein, womit sie innerhalb der CAT-Datei auch signiert wird.

Bitte beachten: Ausnahme & Lösung

Nein. Da Microsoft die Zertifizierung für Windows 7 eingestellt hat, können auch von unserer Seite keine weiteren Updates mehr vorgenommen werden. Details dazu finden Sie hier.

Ja, Kithara RealTime Suite beinhaltet eine C#-Klasse, die das API von Kithara RealTime Suite exponiert. Mit dieser Klasse ist man in der Lage, den gesamten Funktionsumfang mit einer C#-Anwendung anzusprechen. Jedoch müssen die Programmteile, die echtzeitfähigen Code enthalten, in eine DLL mit nativem Maschinen-Code (x86 bzw. x64), also beispielsweise mit C/C++ oder Delphi generiert, ausgelagert werden. Um diesen Entwicklungsschritt so einfach wie möglich zu gestalten, liefern wir ein Projekt-Template aus, in dem gezeigt wird, wie dies geschieht. Dieses Projekt kann sofort als Vorlage für eigene Entwicklungen genutzt werden.

Im Prinzip ist es möglich, unsere Software mit VB6 zu verwenden. Da VB6 aber mittlerweile sehr alt ist, gibt es nur wenige Beispielprogramme. Das Hauptziel unserer Software ist das Bereitstellen von Bibliotheken, mit denen Echtzeit unter Windows umgesetzt wird. Dies kann nur auf der Kernel-Ebene von Windows geschehen. Es werden also Sprachen vorausgesetzt, die auf Kernel-Ebene laufen. Das sind zur Zeit nur C/C++ und Delphi. Wir unterstützen zudem auch C#-Projekte, da es möglich ist, die Hauptapplikation in C# zu programmieren und die zeitkritischen Teile über eine DLL in C++ zu schreiben.

Wenn Sie VB.NET verwenden würden, könnten Sie zwar ohne Probleme die C#-Schnittstelle nutzen, es wäre jedoch immer noch nötig, eine in C oder C++ geschriebene DLL zu programmieren. Wenn es nicht zeitkritisch (Echtzeit) sein muss, können Sie auf Anwendungsebene bleiben und alles in C# oder VB.NET schreiben.

Selbst wenn es möglich wäre, in VB6 zu programmieren, würden wir es dennoch nicht empfehlen, da VB6 nicht in der Lage ist, Multithreading-Anwendungen richtig auszuführen. Das Gleiche gilt für OCX, was der Grund ist, warum wir keinerlei Entwicklungen in OCX unternommen haben.

Windows selbst ist kein Echtzeitsystem. Um Echtzeiteigenschaften zu erreichen, ist es notwendig, die zeitkritischen Code-Teile im Echtzeitkontext (auf der Kernel-Ebene) auszuführen. Da C# aufgrund der .NET-Umgebung nicht direkt im Echtzeitkontext ausgeführt werden kann, ist das Zeitverhalten weiterhin vom Windows-Scheduler abhängig. Hierbei besteht die Möglichkeit, den zeitkritischen C#-Threads eine hohe, absolute Thread-Priorität zuzuweisen.

Diese Möglichkeit hatte man als Anwendungsprogrammierer bislang nicht. Kithara stellt dazu die entsprechenden Mechanismen bereit. Dies kann zumindest dafür sorgen, sich Vorrang vor allen anderen Windows-Anwendungsaktivitäten zu verschaffen. Für wirkliches Echtzeitverhalten sollten die entscheidenden Code-Teile mit C++ oder Delphi in eine DLL ausgelagert werden, die dann direkt in den Echtzeitkontext geladen wird.

Für die Kommunikation zwischen Anwendungs- und Echtzeitkontext stehen Shared Memory, Daten- und Message-Pipes, Events oder Sockets zur Verfügung. Eine Reihe von mitgelieferten Beispielprojekten verdeutlicht, wie „harte“ Echtzeit in C#-Anwendungen eingebettet werden kann.

Durch das Dedizieren von CPUs für Kithara RealTime kann Einfluß von Windows selbst oder anderer Software unter Windows auf das Echzeitverhalten nahezu komplett ausgeschlossen werden.
Allerdings kann die konkrete Hardware mehr oder minder gute Echtzeitfähigkeiten bieten und insbesondere Konfigurationsoptionen in BIOS/UEFI können die Echtzeitfähigkeiten erheblich beeinträchtigen.

• C1E = Enhanced Power-Save-Modes der CPU.
  Die Stromsparmechanismen moderner CPUs führen dazu, dass diese schnell in Schlafzustände wechseln und dafür Funktionsblöcke abschalten. Das Aufwachen aus diesen Stromsparmodi kostet wertvolle Zeit und führt somit zu unvorhersehbaren Latenzen. Für bestes Echtzeitverhalten sollten alle Stromsparmodi deaktiviert werden.
  Sie finden diese Einstellung (je nach BIOS/UEFI) unter Menüpunkten wie z.B.
  • C1E
  • C-States
  • Deeper C States
• SpeedStep
  Die Stromsparmechanismen moderner CPUs führen dazu, dass diese häufig die Betriebstakte temporär ungenutzter CPUs absenken. Diese, bei Bedarf, wieder anzuheben kostet wertvolle Zeit und führt somit zu unvorhersehbaren Latenzen.
  Für bestes Echtzeitverhalten sollten alle dynamischen Taktanpassungen deaktiviert werden.
  Sie finden diese Einstellung (je nach BIOS/UEFI) unter Menüpunkten wie z.B.
  • EIST
  • SpeedStep
  • Turbo Boost
  • PowerNow!
  • Cool'n'Quiet
• Legacy USB Support
  Führt erfahrungsgemäß (je nach UEFI Implementation) zu verschlechtertem Echtzeitverhalten und sollte daher abgeschaltet sein.
• Hyper-Threading / Simultaneous Multithreading (SMT)
  Für die meisten Einsatzszenarien empfielt sich Hyper-Threading abzuschalten, damit jede einzelne 'logische' CPU auch tatsächlich jederzeit deterministisch Zugriff auf all ihre Rechenwerke hat, siehe den entsprechenden Hinweis beim Dedizieren von CPUs für Kithara RealTime.
• WBINVD = Assembler Befehl zum Leeren aller internen Caches.
  Wird z.B. von Nvidia-Grafiktreibern benutzt. Abhilfe schafft nur der Verzicht auf Software, die diesen Befehl nutzt, im Falle von Hardware-Treibern nur der Wechsel auf Alternativen.

Windows 10 x64 verfügt zwar über die sogenannte „Kernel Patch Protection“, um Eingriffe in das Betriebssystem zu verhindern. Dadurch ist der Betrieb von Echtzeitaufgaben auf CPU-Kernen, die auch von Windows genutzt werden, nicht möglich. Sie können jedoch mit dem Dedicated Mode einzelne oder auch mehrere CPU-Kerne von Windows freihalten (siehe hier). In diesem Fall bootet auf den betreffenden CPUs ausschließlich das Kithara-Echtzeitsystem. Das ermöglicht auch Echtzeit unter Windows 10 x64 und zwar mit hervorragenden Echtzeiteigenschaften.

Wir unterscheiden drei verschiedene Kombinationen:
 

1. 32-Bit-Anwendungen auf 32-Bit-Windows
2. 64-Bit-Anwendungen auf 64-Bit-Windows
3. 32-Bit-Anwendungen auf 64-Bit-Windows

Fall 1) und 2) sind trivial und werden hier nicht weiter betrachtet.

Für den Fall 3) unterstützen wir folgendes Vorgehen:
Lagern Sie den Code mit den Echtzeitanforderungen in eine separate DLL aus.
Über unseren KiK64 Mechanismus können diese Funktionen dann aus Ihrer Applikation aufgerufen werden, auch wenn die Anwendung selbst nur für 32 Bit implementiert ist, die DLL aber auf einem 64 Bit System zwingend für 64 Bit implementiert ist.

Zu Details des KiK64 Mechanismus siehe
  White Paper: Zukunftsfähige Architektur mit Kithara RealTime Suite

Ja, mit Kithara DOS Enabler lassen sich hardwarenah entwickelte DOS-Programme auch unter Windows 10 betreiben.
Dabei werden sowohl 32- als auch 64-Bit-Systeme unterstützt.
Kithara DOS Enabler bringt ein eigenes DOS-System mit (FreeDOS) und führt die 16-Bit-Anwendungen auf einem dedizierten CPU-Kern nativ aus.
Durch Beseitigung jeglicher Windows-Einflüsse sind auch zeitkritische Anwendungen möglich.

Zur Programmierung von hardwarenahen und zeitkritischen 32- oder 64-Bit-Anwendungen siehe Kithara RealTime Suite.

Ja, mit dem USB RealTime Module können xHCI-controller direkt angesprochen werden, womit eine Echtzeit-Kommunikation mit USB Geräten (wie zum Beispiel USB3 Vision Kameras) möglich ist.

Die erneute Signalisierung eines bereits signalisierten Events ist wirkungslos.
Eine bestehende Signalisierung eines Events wird durch den Konsumenten des Events, durch den Konsum, automatisch zurückgesetzt, wenn es sich um ein "Auto-Reset-Event" handelt (Standardfall).
Wird beim Erzeugen des Events mit KS_createEvent das Flag KSF_MANUAL_RESET angegeben, ist das resultierende Event kein "Auto-Reset-Event", d.h. nach Signalisierung bleibt diese bestehen bis sie manuell durch Aufruf von KS_resetEvent wieder zurückgesetzt wird, womit zuvor mehrere Konsumenten auf das Event reagieren können.