Hallo,

A)
Wie schon geschrieben wurde ist Windows nicht wirklich Echtzeitfähig. Da kann es im Normalbetrieb schon mal vorkommen, dass es 1-2 Sekunden alle anderen Tasks sperrt. Von Updates mal ganz abgesehen.
Ein weiteres Problem ist, dass es diese Karten nach ein paar Jahren nicht mehr gibt und die PCs einen anderen Bus verwenden.
So vor 25 Jahren wollte ein Kunde unbedingt so eine Lösung, weil er dachte so Entwicklungskosten zu sparen. Nach ein paar Jahren ist dann bei einem Kunden der PC ausgefallen und die Neuen hatten keinen ISA-Bus mehr. Schon vorher gab es die I/O-Karte aber nicht mehr, bzw. das Nachfolgemodell benötigte umfangreiche Anpassungen der Software.

B) Auch hier hast du das Problem der Reaktionszeiten des Betriebssystems. Du darfst auch nicht vergessen, dass sich die Geräte bei USB die Bandbreite teilen müssen. Die 100µs kannst du mit USB überhaupt nicht garantieren.

C) Finde ich die beste Lösung und hat sich bei mir auch im Industrie-Bereich bewährt.
Mindestens die grundsätzlichen, und vor allem zeitkritischen Funktionen werden komplett auf den µC ausgelagert. Je nach Anwendung kann der µC sogar Stand Alone arbeiten und der PC wird im Betrieb nur für Start/Stopp und Statusanzeigen benötigt.
Ein weiterer Vorteil ist die Stabilität! Welche Updates auf dem µC gemacht werden, liegt total in deiner Hand. Bei einem Betriebssystem musst du, schon wegen der Sicherheit, immer Updates ausführen. Dabei kommt es öfters vor, dass Programme danach nicht mehr oder fehlerhaft funktionieren. Dieses Problem fällt dann auch eher weg.

Die Tests müssen nicht aufwändiger sein, im Prinzip können sie auch einfacher werden. Verwendest du einen Befehlssatz welcher nur aus sichtbaren ASCII-Zeichen besteht, kannst du in der ersten Phase mit einer Terminal-Emulation auf dem PC testen.
Wenn du einen µC mit LAN oder WLAN verwendest. Ist natürlich auch eine Webseite als Userinterface möglich. Dann musst di auf dem PC gar nicht programmieren und verwendest einfach einen Browser. Dann ist es sogar egal ob du einen PC, Notebook, Tablet oder Handy verwendest um das alles zusteuern.

Das sind jetzt natürlich grundsätzliche Überlegungen und nicht alle meine Ideen sind für jeden Anwendungsfall ideal. Du schreibst ja nicht, was die Steuerung genau machen soll.



Die war dann auch, ein paar Jahre später die Lösung für das oben genannte Projekt. Über eine serielle Schnittstelle wurde ein mehr oder weniger autonomes System an den PC angeschlossen. Die Software auf dem PC übernahm dann die Bedienung, die grafische Aufbereitung und Anzeige der Messdaten und die Speicherung der Messwerte.

Übrigens habe ich bei diesem Projekt die PC-Oberfläche in Visual BASIC geschrieben, weil dies eine grafische Oberfläche zum Zeichnen der GUI hatte. Einige Grafik-Elemente wurden als ActiveX umgesetzt und der Einfachheit halber auch in VB programmiert. Der Rest wurde in C geschrieben, wie auch die Firmware auf dem µC. Der Protokoll-Handler wurde portierbar geschrieben, somit gab es dafür nur einen Source-Code, welcher gepflegt werden musst.
Achja, die PC-Software hatte ich in 3 Module zerlegt.
Zuunterst war ein COM-Server welcher das Protokoll abgewickelt hat und ein API für die nächste Schicht bereit stellte.
Darauf setzte dann ein weiterer COM-Server auf, welcher die Ablaufsteuerung usw. enthielt und ein weiteres API zur Verfügung stellte. Zudem konnte man diese COM-Server über die Comandozeile so starten, dass er eine Art Debug-Interface anzeigte. Damit konnte man dann alle I/Os einzeln ansteuern und anzeigen. Zudem gab es noch Routinen um die ADC und DAC abzugleichen.
Hier setzte dann das eigentliche Userinterface auf, welches zudem für die meisten Kunden unterschiedlich war.
Das Ganze lief dann Anfangs unter WIN 95.

Wie schon angegeben war das Meiste in VB und C geschrieben. Kleinere Teile, wie das COM-Interface, war in C++ geschrieben, weil MS dazu einen Wizard mit der Entwicklungsumgebung mitgeliefert hat.
Technisch ist es nicht wirklich ein Problem unterschiedliche Sprachen zu mischen und diejenigen zu verwenden, welche die Teilprobleme am einfachsten lösen. Zumindest wenn man in mehr als einer Sprache fit ist.

MfG Peter(TOO)