Hallo,

Mit Windows-Programmierung habe ich mich noch nicht beschäftigt, dagegen habe ich einige größere Software-Pakete
für schnelle Echtzeitanwendungen mit div. Mikrokontrollern und DSP erstellt.
Meine PC-Programmier-Kenntnisse hören bei Interrupt-Programmierung unter DOS (Borland-C) auf.
(DOS mit abgeschalteten Interrupts bzw. nur mit "eigenen" Interrupts und wenig Betriebssystemaufrufen
ist erstaunlicherweise gut echtzeitfähig, Reaktion auf Hardware-Ereignisse ist selbst mit älteren PCs bis zu
wenigen Mikrosekunden möglich)

Der Einstieg in Visual-Forms ist ja recht einfach, ich scheitere nun aber an schnellen Reaktionen auf Hardware-Ereignisse.
Ich möchte nun unter Visual-Basic (alternativ Visual-C) eine Software erstellen, die möglichst schnell auf eine Pegel-Änderung
an einem der Handshake-Pins einer RS232 reagiert.

Einen periodischen Timer und Pollen Pins der Schnittstelle per Software kriege ich hin.
Allerdings wird mir das zu lahm, bzw. die CPU-Belastung wird zu hoch, wenn ich den Timer zu schnell einstelle.

Gibt es sowas wie eine "Ereignis-Reaktion", d.h. eine Methode, die aufgerufen wird, wenn sich mein Handshake-Pin ändert?

Hmm - ich glaub hier in Dotnet proggen wir total abgehoben, und wissen nix von Handshake-Pins und Kram.
Ich täte mir ein SerialPort-Objekt aufs Form ziehen, und wenn Daten kommen erhalte ich ein Event, ja.

Handshake und Krimskrams lasse ich dieses SerialPorts-Dingens selbst ausmachen mit dem Gerät - da will ich möglichst nix mit zu tun haben, und vertraue darauf, dass Microsoft da kompetente Programmierer eingesetzt hat, die das effizient im SerialPort gelöst haben.

Jo, so ist halt die Denkweise in einer Hochsprache: "Bleib mir fern mit Hardware!"

Also guck dir die Klasse SerialPorts im ObjectBrowser/ObjektKatalog an, ob die leistet, was du brauchst.

Wenn du nix verstehst von den Infos, die der OB dir gibt, dann musst du die Sprache lernen, weil logisch ohne die Sprache zu verstehen kann man keine Doku lesen, und der OB ist die Doku, und zwar eine geniale Doku.
also evtl. dieses Buch lesen (hingegen das Galileio-Openbook ist Mist)

Ach hallo und willkommen ühaupt

Willkommen im Forum.
.NET und Echtzeit / zeitnah (wie Du es Dir vorstellst) ist nicht vereinbar.
GUIs und gemütlich Zeugs bekommst Du unter .NET wunderbar hin, doch wenn Du auf die Uhr sehen musst, solltest Du solch doch in C / C++ schreiben.
Wenn Du da eine feine DLL machst, kannst Du sie natürlich bequem in .NET einbinden.

Hallo
Für die Steuersignale gibt es Events!
Suche nach Bitwackeln, wo alle 3 Ausgaben und 5 Eingaben abgefragt werden.
Ist die schnellste Möglichkeit mit Event.
Wird immer noch nicht schnell genug sein.
Minimale Reaktionszeit.
Du musst dem Programm maximale Rechenzeit zuordnen.
Im Moment für mich nicht wichtig.

Wenn du die Schnelligkeit testen wirst,bitte hier das Ergebnis einstellen.

Gruß

Darf ich kurz mal darauf hinweisen, dass es ein Event mit namend PinChanged gibt?

Dass dürfte genau passend sein. Normalerweise kommt man bei einem Computer allerdings nicht in die Verlegenheit, sich auf das Timing zu verlassen.

Bist du sicher, es wäre nicht besser, noch einen kleinen MCU dawischen zu kleben?

Auch ich frage mich, warum dich der Handshake-Pin überhaupt interessiert.
Bei normaler Datenübertragung wird der Handshake vom Controller ausgewertet und die Datenübertragung unterbrochen bzw. gestartet.

Den Handshake-PIN auswerten musst du eigentlich nur, wenn du den COM-Port für reine Signalübertragung vergewaltigst.
Welchen Handshake meinst du, DSR oder CTS?

Vielen Dank für die Reaktionen auf meine Frage

Manawyrm schrieb:

Darf ich kurz mal darauf hinweisen, dass es ein Event mit namend PinChanged gibt?

Dass dürfte genau passend sein. Normalerweise kommt man bei einem Computer allerdings nicht in die Verlegenheit, sich auf das Timing zu verlassen.

Bist du sicher, es wäre nicht besser, noch einen kleinen MCU dawischen zu kleben?

Das war das Schlagwort, mit dem durch weiterkuugeln den "SerialPort.PinChanged Event" gefunden habe.
Das ist wohl das, was ich gesucht habe.
Doch als Teil von .NET Framework traue ich mich da nicht ran. Wie gesagt, nur Anfänger-Kenntnisse im programmieren von Windows.

Den MCU wollte ich mir eben sparen.

petaod schrieb:

Auch ich frage mich, warum dich der Handshake-Pin überhaupt interessiert.
Bei normaler Datenübertragung wird der Handshake vom Controller ausgewertet und die Datenübertragung unterbrochen bzw. gestartet.

Den Handshake-PIN auswerten musst du eigentlich nur, wenn du den COM-Port für reine Signalübertragung vergewaltigst.
Welchen Handshake meinst du, DSR oder CTS?

Eigentlich will ich gar keine Datenübertragung durchführen, sondern den seriellen Port zweckentfremdet benutzen.
Zu DOS-Zeiten mit hardwarenaher Programmierung habe ich einige abenteuerliche Tools programmiert.
Eigentlich möchte ich die Zeitdauer zwischen zwei Ereignissen messen - die wollte ich eben über DSR und CTS erfassen.
Ein paar ms als zeitliche Auflösung würden mir reichen.

Ich werde mich wohl damit abfinden, dass solche hardwarenahen Tricks unter Windows mit meinen Kenntnissen nicht mehr möglich sind
und werde dann doch einen kleinen uC programmieren, der dann wieder ganz brav seine Ergebnisse über einen UART meldet.

Kommt halt auf den Verwendungszweck an.

Zum Messen der Rundenzeit eines Spielzeugautos tuts auch das PinChanged Event.
nur das Mischverhältnis von Medizin würde ich nicht umbedingt mittels .net steuern

Für wirklich genaues Timing ist Windows da selbst mit C / C++ nicht geeignet. Auch Standard Linux ist nicht für Echtzeit geeignet. Auf der Industriemesse vor einigen Jahren wurde ein echtzeitfähiges Linux vorgestellt. Dieses wurde jedoch extra für solche Zwecke angepasst.

Ich selbst habe mal für einen Kollegen eine Stoppuhr für ein Sportfest gebaut. Die Zeiten liefert da ein AtTiny 2313 per TTL-USB Kabel. Zum Vergleich hatte ich zusätzlich auf dem PC eine Uhr gestartet, wenn die Info kam, dass der AtTiny gerade seine Stoppuhr gestartet hatte. Ebenso dann auch gestoppt, wenn die Info zum Stoppen kam.

Die Abweichungen waren zwar minimal, existierten aber. Zusätzlich variierten diese, sodass auch ein Offset nicht zuverlässig programmierbar war.

War Windows nebenbei beschäftigt, beeinflusste das die von Windows gemessene Zeit zusätzlich negativ.