mikrocontroller.net

Forum: PC-Programmierung Hilfe bei RS232-Fkt in DLL


Autor: TK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich brauch mal eure Hilfe. Ich habe eine DLL mit C++ erstellt, in der 
sich diverse Routinen für die RS232 befinden (z.B. send_data(), 
receive_data(), setup_comm() usw.). Von einem anderen Programm binde ich 
die DLL ein, bzw. nutze die Funktionen innerhalb der DLL. Alle 
Funktionen liefern hierbei ein Ergebnis zurück - meist eine BOOL (z.B. 
success = receive_data(Parameter)).
Da ich innerhalb der Funktion receive_data im Polling-Modus auf Daten 
warte, und gleichzeitig dort auch einen Timeout-Timer laufen habe, kommt 
es nun vor, dass der Timeout-Timer (ca. 3s) immer dann anspricht, wenn 
keine Daten über die RS232 von einem entsprechenden Device zurückkommen 
- soweit ist das ja OK. Aber jetzt ist es so, dass mein Hauptprogramm 
ca. 70 Devices, die über einen Bus vernetzt sind, in regelmäßigen 
Abständen abfragt (abfragen muss!)
Da es sich um eine Art TOKEN-RING-BUS handelt (HARDWARE ist fest 
vorhanden
und NICHT verhandelbar!) kann es in seltenen Ausnahmen vorkommen, dass 
eben
ein Device in dieser Kette nicht mehr reagiert und somit das 
Gesamtsystem lahmlegt. Dann spricht bei jeder Abfrage der Timeout-Timer 
an - bei 70 Devices a)3s kann man sich ja ausrechnen, wie lange das 
Gesamtsystem blockiert wird.
Soviel zum Vorgeplänkel.
Jetzt meine Frage: Welche Möglichkeit habe ich, dass z.B. die Daten 
nicht mehr im Polling-Modus abgefragt werden? Wie kann ich, solange noch 
kein Rückgabewert der Funktion vorhanden ist, im Hauptprogramm 
weitermachen, ohne dass das System blockiert wird. Als Parameter zum 
Aufruf der Funktion dient u.a. ein Pufferbereich, der die Daten 
aufnehmen soll, die Adresse des abzufragenden Devices usw.

Danke schon mal - auch fürs durchlesen
Gruß
TK

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

In deinem Fall wäre es günstiger der COM-Schnittstelle einen eigenen 
Thread zu spendieren. Die Kommunikation zwischen Hauptprogamm und Thread 
erfolgt dann nur noch auf der Message-Ebene. Wenn du wissen willst, wie 
so etwas aussieht, dann suche mal nach 'cport'. Version 3 oder höher.

MfG Spess

Autor: TK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit einem eigenen Thread ist so eine Sache.
Ich benutze die DLL mit den 'Low-Level-Routinen' in fast allen 
Programmen,
die eine RS232 Kommunikation benötigen. Da müsste ich ja alle Programme 
umschreiben. Ist dann doch ein wenig zu viel. Ich komme um die DLL nicht 
herum. Mein erster Lösungsansatz war eigentlich die Timeout-Zeit von 3s 
auf z.B. 300ms zu reduzieren. Die Frage ist dann nur, ob die Devices 
nicht doch gerade in einer Interruptroutine irgendwas machen (z.B. Zeit 
verbraten). Wie könnte ich denn innerhalb der DLL einen Thread 
aktivieren, der die Daten von der RS232 einliest UND wie kann ich dann 
dem Hauptprogramm mitteilen, dass die Daten im Puffer stehen, wenn die 
DLL-Funktion bereits verlassen wurde?
Das ist hierbei mein größtes Problem. Kurz gesagt - ans Hauptprogramm 
möchte ich nicht ran. Aber wahrscheinlich komm ich wohl nicht darum.

Gruß
TK

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Vorab erst mal : ich programmiere meine Programme mit Delphi. Aber die 
Verwendung von API-Funktionen verläuft genauso wie unter C++.
Hast du die die Routinen in eine eigene Class verpackt? Wenn nicht, 
gehst du am Konzept von C++ vorbei und da sind deine Schwierigkeiten 
vorprogrammiert.

MfG Spess

Autor: TK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Routinen nicht in eine Klasse verpackt. Ich sehe aber hier 
auch nicht das Problem. OK - nur weil ich den Borland C++ Compiler hab 
muss ich ja nicht unbedingt immer auf die C++ Konzepte zurückgreifen. Im 
übrigen versteht  der ja auch Delphi.
Wo wäre denn der Vorteil bei der Behebung meines Problems, wenn die 
Routinen in einer Klasse stecken würden?

Gruß
TK

Autor: Spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Wie gesagt, ich komme aus der Delphi-Ecke. Der Vorteil für mich ist, 
dass ich  eine Serielle Schnittstelle als Komponente in ein Formular 
einfügen kann. Über die Schnittstellen der Komponente wird dann auf die 
Eigenschaften und Funktionen zugegriffen.
Zum Beispiel kann deine Komponente(class) einen eigenen Timer besitzen. 
Der fragt in bestimmten Abständen den COM-Port ab und liest ,wenn 
vorhanden, die Daten in einen internen Puffer. Danach wird eine 
Nachricht (message) an das Hauptprogramm geschickt. Das Hauptprogramm 
holt dann die Daten über eine Funktion der Class ab. Damit hast du die 
eigentliche Behandlung des COM-Ports vom Hauptprogramm abgekoppelt. Dein 
Hauptprogramm kann dann in aller Ruhe überprüfen, ob irgendwelche Sender 
ein Timeout haben, ohne blockiert zu werden.

MfG Spess

Autor: TK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Generell hab ich auch kein Problem mit Delphi. Ich hab AUCH in C++ eine
Komponente für die serielle Schnittstelle. Die kann ich hier aber nicht 
benutzen (Lizenzprobleme)! Deshalb hab ich ja die DLL geschrieben. Die 
kann ich nämlich weitergeben, OHNE Probleme mit anderen zu bekommen. Und 
selbst eine Komponente erstellen - so weit bin ich noch nicht in die 
Materie eingestiegen. Klar hat eine Komponente die Vorteile, die du 
angesprochen hast. Man kann dann schön auf Ereignisse reagieren usw.
Nur ist es bei diesem Projekt so, dass ich zwar das Hauptprogramm 
erstellt habe, aber dieses nur als "Demo" an einen Kunden rausging. Der 
hat jetzt sein eigenes Programm entwickelt und muss eben die DLL für die 
Kommunikation mit den Devices benutzen (da sind eben nicht nur RS232 
Routinen drin). Da liegt jetzt das Problem. Ich bzw. er kommt ohne die 
DLL nicht klar. Und die Routinen/Funktionen offen legen möchte ich dann 
auch nicht.
Vielleicht gibts ja eine Möglichkeit einen GLOBALEN Puffer zu 
deklarieren, den sowohl das Hauptprogramm, als auch die DLL benutzen 
können. Den könnte man ja dann füllen, wenn tatsächlich Daten da sind. 
Demnach müsste jede DLL Routine sofort wieder verlassen werden und das 
Hauptprogramm müsste dann zyklisch den Inhalt des Puffers prüfen. Aber 
auch hier seh ich eigentlich zu viel Aufwand für die DLL und das 
Hauptprogramm. Momentan bin ich echt ratlos.

Gruß
TK

Autor: Ekkehard Domning (ekkehard)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
nur damit ich es verstanden habe:
- ca. 70 Geräte hängen am gleichen CommPort
- Dein Hauptprogramm ruft eine Funktion in der DLL auf um Daten an ein 
einzelnes Gerät zu senden oder von einem einzelnen Gerät zu empfangen.

Unter dieser Annahme, könntest Du in der DLL einen Thread bauen der von 
sich aus mit allen Geräten spricht und die Ergebnisse in ein einen 
Puffer ablegt.
Deine Funktionen die von Deinem Hauptprogramm aufgerufen werden lesen 
dann z.B. nicht mehr von der Schnittstelle sondern aus der 
Ergebnisliste. Da da z.B. drinnsteht, das ein Timeout aufgetreten ist 
muss der Funktionsaufruf nicht bis zum Timeout dauern, sondern kehrt 
sofort zurück.
Allerdings musst Du mit Threads in DLLs aufpassen. Z.B. darfst Du im 
Initialisierungsbereich keine Threads erzeugen oder im 
Zerstörungsbereich keine Threads beenden. Falls Dein Hauptprogramm eine 
Funktion "Öffen CommPort" aufruft kannst Du dort den Thread erzeugen 
(und bei "Schließe CommPort" beenden).
Und du musst den Zugriff auf Deine Ergebnisse mit z.B. Critical Sections 
schützen, damit nicht das Chaos losbricht wenn Dein Hauptprogramm und 
Dein Thread gleichzeitig auf diese Bereiche zugreifen.

Gruß Ekkehard

Autor: TK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Ekkehard
Genau so / so ähnlich hab ich mir das vorgestellt.
Jetzt mal zu meinem Verständnis: Also die DLL agiert autark und fragt 
dann
zyklisch alle Teilnehmer von sich aus ab, trägt die gesammelten Daten in 
einen Ereignispuffer und wartet nur noch darauf, dass das Hauptprogramm 
den Puffer ausliest.
OK - soweit verstanden.
Jetzt kommt allerdings eine Kleinigkeit dazu. Es gibt ja mehrere 
Funktionen innerhalb der DLL, die auch unterschiedliche Ereignisse an 
den Devices auslösen. Also z.B. Datenwerte abfragen, Parameter 
übergeben, Selbsttests durchführen lassen usw.
Und jede dieser Routinen benutzt letztendlich die Schnittstelle mit den
Timeoutvorgaben.
Durch den Thread könnte ich also z.B. die Hauptfunktion (nämlich 
Datenwerte abfragen) automatisieren. Alle anderen Funktionen würden ohne 
Threadsteuerung arbeiten wie bisher - also mit Timeout.
Aber ich denke, das wäre schon mal ein riesiger Schritt in die richtige 
Richtung. Ich mach mich dann mal an die Überlegungen für einen 
Threadaufbau und dann an die Programmierung.
Danke erst mal

Gruß
TK

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.