Zur Übersicht - INFO - Neueste 50 Beiträge - Neuer Beitrag - Suchen - FAQ - Zum CC1-Forum - Zum CC-Pro-Forum

Re: Probleme mit HWCOM und mehreren Threads Kategorie: Programmierung (von Tom - 13.11.2003 12:18)
Als Antwort auf Re: Probleme mit HWCOM und mehreren Threads von Georg Mallebrein - 13.11.2003 1:19

Hallo Georg,

poste halt einfach mal diesen Programmteil, dann wird sich der Fehler schon
finden lassen.

mfg Tom



> Hallo André, hallo Tom
>
> das mit dem "Hallo" auch beim ersten Forum-Eintrag ins "Anonyme" will ich mir gerne angewöhnen,
> das ist mein erstes Forum, jedoch habe ich in diesem CC2net-Forum schon einiges geblättert.
> Und ich mu� Euer Forum loben, es sind sehr gute Hinweise drin und es ist übersichtlich.
>
>
> Dir und Tom vielen Dank für die Antworten.
>
> André, ich befürchte durch durch Deine Hinweise nicht ganz zum Ziel zu kommen.
> Heute hatte ich zwar nicht die Zeit es nochmals auszuprobieren.  
>
> Ich habe die COM-Komunikation bisher nie auf zwei Threads aufgeteilt!!
>
> Schon die reine Existenz eines zweiten Threads, der irgend etwas rechnet macht bei mir
> Probleme mit der COM-Kommunikation im anderen Thread.
>
> Ich habe jetzt versucht Deine Antwort trotzdem zu interpretieren:
>
> Vielleicht darf ich solche Befehle wie "wait hwcom.ready()" nicht verwenden.
> Laut Buch gibt ja die wait-Anweisung die Programmführung einfach an den nächsten Thread ab und
> schon hätten wir das Problem. Sehe ich das richtig ?
>
> Ist wohl auch die yield-Anweisung verboten im Thread der mit HWCOM arbeitet ?
>
> Am Wochenende probiere ich es weiter. �ber eine kurze Rückmeldung wäre ich dankbar.
>
> Grü�e von Georg
>
>
>
> > Hallo Georg,
> >
> > Zuerst: Ein kleines "Hallo" oder ähnliches am Anfang eines Postings könnte nicht
> > schaden. Das gehört einfach zur Höflichkeit in Foren.
> >
> > > Ich will mehrere Threads einsetzen und gleichzeitig über die serielle Schnittstelle Daten nach
> > > Excel oder zu einem Hyperterminalprogramm übertragen.
> >
> > Prinzipiell sollte man nie "gleichzeitig" von mehreren Threads auf die serielle Schnittstelle
> > zugreifen. Das endet, ohne speziellem Protokoll, fast immer in einem Datendurcheinander.
> > Besser ist es die COM von einem eigenem Thread übernehmen zu lassen.
> >
> > > Eine Messung soll im Hintergrund auch dann noch Daten erfassen, wenn ich bereits gemachte
> > > Messungen aus einem EEPROM-Ringspeicher in den PC auslese.
> > >
> > > Alle Versuche mit mehreren Threads brachten bisher irgendwie seltsame Ergebnisse.
> > > Einmal brach die Ã?bertragung ab, ein anderes Mal ging gar nichts, ein drittes Mal
> > > kamen total andere Zeichen am PC an. Ein viertes Mal ist das Terminalprogramm ausgestiegen.
> > >
> > > Verwende ich nur einen Thread "main" funktioniert die Ã?bertragung..
> >
> > Verwende einen Thread für die Kommunikation und einen für die Datenerfassung.
> > Das scheint hier das sinnvollste zu sein.
> >
> > > Mit Capture und Release habe ich auch nichts erreicht, dann wird gar nichts mehr übertragen.
> > > Bemerkung: Ich habe einfach vor den COM-Ausgaben in einer Funktion zunächst Capture
> > > geschrieben und am Ende der Ausgaben ein Release.
> >
> > Verschachtelte Systemcaptures funktionieren nicht. Da die ser. Schnittstellen
> > bereits gecaptured sind, führt eine weitere System-Capture-Eben zum verriegeln(=anhalten)
> > aller Threads, die dieses Capture nutzen.
> >
> > Verschachtelte Captures funzen nur mit Hilfe von cap.c2, wie es bereits Tom
> > geschrieben hat.
> >
> > > Was muss man beachten um eine fehlerfreie �bertragung über die COM-Schnittstelle
> > > bei Programmen mit mehreren Threads zu erreichen?
> >
> > Wie gesagt, sollte ohne einem speziellem Ã?bertragungsprotokoll immer nur ein Thread
> > Zugriff auf eine ser. Schnittstelle haben.
> > Andernfalls muÃ?t Du mit den erweiterten Captures (cap.c2) arbeiten, und ein
> > Ã?bertragungsprotokoll festlegen, damit keine Daten durcheinanderkommen.
> >  
> > > Es wäre schade, wenn ich die Multi-Thread Technik nicht verwenden könnte.
> >
> > Hier spricht nichts dagegen.
> > Wie gesagt: Ein Thread für die Datenerfassung, und einer für die Kommunikation.
> >
> > MfG André H.




    Antwort schreiben


Antworten: