Unterbrechung einer RS 232 Verbindung

Technik Elektronik & Elektrotechnik
1

Hallo!

Zunächst einmal möchte ich vorweg schicken, das ich im Bereich Elektronik völliger Laie bin. Ich habe nun eine bestimmte Idee und mich würde interessieren a. ob das überhaupt möglich ist und b. wie aufwenidig das wäre.(Vielleicht gibt es ja schon entsprechende Schaltungen, die nur modifiziert werden müssen.)

Ein Gerät soll unter Windows über die RS 232 Schnittstelle
in verschiedenen Zeitabständen ausgelesen{(1/2-300)s} werden. Nun stellt sich aber Windows diesen Anforderungen in den Weg.
Bisher habe ich keinen sicheren Weg gefunden dieses Problem rein durch Software zu umgehen und bin so auf eine „Hardwarelösung“ verfallen.
Meine Idee war nun, die RS 232 Leitung mit einer Schaltung, die über eine separaten Uhr verfügt, in den entsrechenden Intervallen zu unterbrechen.
Ich glaube das Kommunikationsprobleme der Schnittstelle über die Software aufgefangen werden können.
Aber könnte so etwas überhaupt funktionieren?

Vielen Dank für die Mühe im Voraus.

Lothar

2

Hallo!

Ein Gerät soll unter Windows über die RS 232
Schnittstelle
in verschiedenen Zeitabständen ausgelesen{(1/2-300)s} werden.

Bedeutet das nun, daß Werte aller 0,5 Sec …300Sec ausgelesen
werden sollen?
Falls ja, warum soll das unter Windows nicht gehen?
Dazu braucht man doch nur ein passendes Programm, keine spezielle
Hardware.

Nun stellt sich aber Windows diesen Anforderungen in den Weg.
Bisher habe ich keinen sicheren Weg gefunden
dieses Problem rein durch Software zu umgehen und bin so auf
eine „Hardwarelösung“ verfallen.

Wo ist das Problem?

Meine Idee war nun, die RS 232 Leitung mit einer Schaltung,
die über eine separaten Uhr verfügt, in den entsrechenden
Intervallen zu unterbrechen.

Wozu die Leitung unterbrechen, wenn was ausgelesen werden
werden soll (Achselzuck) ???

Ich glaube das Kommunikationsprobleme der Schnittstelle über
die Software aufgefangen werden können.
Aber könnte so etwas überhaupt funktionieren?

Prinzipiell ist das kein Problem. Probleme gibt es max. wenn man
mit Windows viel schneller und zeitgenau was machen will.
Aller halbe Sekunde (+/- einige 10ms) die RS232 abfragen sollte
kein Problem sein.
Gruß Uwi

3

Hallo!

Zunächst einmal vielen Dank für die Antwort!

  1. Ja, es soll im Bereich von (0,5-300)s ausgelesen werden und Windows
    hat diesbezüglich, meiner Erfahrung nach, ernste Probleme!
    Ich bin dann davon ausgegangen, das ich einfach nur ein miserabler Programmierer bin. Deswegen habe ich mich auch an andere Leute gewendet.
    Und auch deren Programme wiesen den gleichen Schwachpunkt auf. Außerdem gibt es ja auch kommerzielle Erfassungsprogramme, wo im Handbuch steht, das „zeitabhängige“ Messungen durch Windows vereitelt werden.
    Deswegen lief das Programm bisher unter DOS, da dort das Problem nicht besteht!

  2. „Aller halbe Sekunde (+/- einige 10ms) die RS232 abfragen sollte
    kein Problem sein.“
    Das funktionierte auch, aber nur die erste halbe Stunde! Danach wurde aus der halben Sekunde mal eben drei Minuten!

  3. Das mit dem unterbrechen der Leitung ist Blödsinn! Es tut mir sehr Leid , aber das ist mir gestern abend erst aufgefallen!

  4. Eigentlich müßte eine äußere Taktung genügen, die von Windows nicht als irgendwie „zeitähnlich“ verstanden wird!

Ich hoffe damit die offenen Fragen geklärt zu haben!

Tschüß

Lothar

4

Wenn du der Software / dem Betriebssystem (es gibt auch echtzeitfähige Betriebssysteme wie z.B. QNX) nicht traust, schalte doch einfach eine Hardware vor, die das puffert (lagere also den zeitkritischen Teil nach Außen). Spontan fällt mir da so etwas wie eine Microcontroller Lösung (Conrad C-Control o.ä.) ein.

Ich hoffe es hilft,

Mirko

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

5

Hallo,

was Du willst, lässt sich über Interrupts sehr gut softwaretechnisch lösen. Da gibts dann auch keine Probleme mit dem Zeitverhalten von Windows. Jedenfalls nicht in dem von Dir geschilderten Zeitrahmen.

Bisher wird von einem Programm aus im polling die Serielle Schnittstelle abgefragt. Pfiffiger wäre es doch, bei anliegenden Daten einen Interrupt auszulösen und dadurch entsprechende Routinen zur Bearbeitung der Daten zu starten.

Gruß

Fritze

6

Hallo,

was Du willst, lässt sich über Interrupts sehr gut
softwaretechnisch lösen. Da gibts dann auch keine Probleme mit
dem Zeitverhalten von Windows. Jedenfalls nicht in dem von Dir
geschilderten Zeitrahmen.

das ist auch die Lösung, die professionelle (Mess-/Steuer-/Regel-)Karten eine Zeit lang benutzt haben, um Windows ‚echzeitfähig‘ zu machen: einfach einen zyklischen Interrupt erzeugen und eine entsprechende Interruptroutine zum Auslesen bestimmter Ereignisse benutzen. Man muß halt die Interruptroutine auf verschiedene Interrupts einstellbar machen (z.B. beim Start abfragen) und bei jedem Interrupt erstmal nachprüfen, ob man selbst gemeint ist (wg. Doppelbelegung von Interruptleitungen).
Hört sich ganz einfach an…

Axel

7

Daten auslesen
Hallo!

Und auch deren Programme wiesen den gleichen Schwachpunkt auf.

tja, das sind Symtome, aber was ist die Ursache?
Es gbt keinen wirklich plausiblen Grund, daß Windoofs nach einiger
Zeit quasi einfrieren können-sollen-muß.

Womit is die Sache programmiert?

Wir haben z.B. für Klimatest (ca.18h) ein Windowsprogramm, das
sogar im Multiasking (also mehrfach gestartet) auf verschiedenen
Schnittstellen Daten etwa im Sekundentakt einliest. Das funktioniert
gut (ist mit -> Delphi programmiert).
Kann es am Programm selber liegen, daß es nach 1/2h Probleme gibt
(z.B. irgend ein Überlauf, eine falsche Deklaration usw.).

Außerdem gibt es ja auch kommerzielle Erfassungsprogramme, wo
im Handbuch steht, das „zeitabhängige“ Messungen durch Windows
vereitelt werden.

Das betrifft schnelle Erfassungen mit ms-Auflösung.
Aller paar 10ms bekommt Windows irgend ein Interrupt und geht
dann aus der Routine raus und kommt dann erst nach einigen ms wieder
zurück. Wenn man also etwas z.B. exakt aller 50ms abtasten will, dann
passiert es regelmäßig, daß die Abtastung unterbrochen und verzögert
wird und dann z.B. erst nach 60ms vollendet wird.

Deswegen lief das Programm bisher unter DOS, da dort das
Problem nicht besteht!

Ja, DOS hat diese Problem natürlich nicht. Schnelle Sachen bis 30kHz
und vor allem Sachen, die ein exaktes timing erfordern habe ich auch
immer noch mit DOS gemacht.

  1. „Aller halbe Sekunde (+/- einige 10ms) die RS232 abfragen
    sollte
    kein Problem sein.“

Das funktionierte auch, aber nur die erste halbe Stunde!
Danach wurde aus der halben Sekunde mal eben drei Minuten!

Da wäre die Ursache zu erforschen.
Was äuft den sonst noch auf dem rechner parallel?

  1. Eigentlich müßte eine äußere Taktung genügen, die von
    Windows nicht als irgendwie „zeitähnlich“ verstanden wird!

Natürlich könnte man einen externen Kontroller als Puffer benutzen.
Bei Deinen Anforderungen scheint mir das überflüssig zu sein, zumal
das Problem des Einfrierens damit nicht wirklich behoben ist.

Für solche Sachen empfehle ich Delphi.
Leute, die da mit C++ arbeiten, müssen echte Profis sein sonst werden
die von solchen einfachen Problemen voll erschlagen. Mag sein, daß
es auch anders geht, aber bei uns ist die Programmierung mit C++
ein Leid ohne Ende.
Gruß Uwi

8

Und auch deren Programme wiesen den gleichen Schwachpunkt auf.

Es gbt keinen wirklich plausiblen Grund, daß Windoofs nach
einiger Zeit quasi einfrieren können-sollen-muß.

Womit is die Sache programmiert?

ich stimme dir insofern zu, als dass ein programm, dass nach 1/2h nciht mehr laeuft ein problem hat.
aber war bei windows nicht dass problem, dass sobald es z.b. meint jetzt arbeitsspeicher auslagern zu muessen (weil z.b. auf dem messrechner noch andere appikationen laufen) niemand mehr das laufzeitverhalten der anwendung vorhersagen kann?

9

Hi Lothar

Ich wüsste auch nicht warum windows nach einer ZEit probleme mit der RS232 bekommen sollte.
In einem Projekt war es mal nötig, Daten von einem Mikrocontroller über die RS232 (RS485 mit Adapter interface auf RS232)am PC zu übertragen. Dort sollten diese dann in Diagrammen dargestellt werden. ZU beginn haben wir uns auch mit Echtzeitübertragungen gespielt und das hat gut funktioniert. (Ist mit MS Visual C++ 6.0 geschrieben)

Ausserdem wenn Windows nach einer halben Stunde ein Problem mit der seriellen Schnittstelle hätte, würde ja kein Modem funktionieren.

mfg martin