mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Probleme mit serieller Kommunikation


Autor: Steffen Burr (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich habe ein Problem mit der Kommunikation zwischen Mikrocontroller und
PC. Dazu habe ich die serielle Schnittstelle (wie im Tutorial)
aufgebaut.

Der PC schickt 3 Byte über die serielle Schnittstelle an den uC (4433).
Dieser verarbeitet die Daten und schickt anschließend 2 Byte wieder
zurück. Dies wiederholt sich etwa alle 20ms.

Funktionieren tut das ganze auch soweit ganz gut. Problem ist, dass die
PC Software nach etwa 2 Stunden abstürzt, d.h. sie hängt imho in der
Schleife fest, in der sie auf die Antwort wartet. Ein Fehler in der
Hardware sowie in der uC Software kann ich eigentlich ausschließen.

Also muss wohl der Fehler in der PC Software liegen. Ich weiß, dass es
natürlich etwas off topic is, aber ich hoffe mal, dass hier schonmal
jmd. eine Kommunikation über die serielle Schnittstelle mit C++
realsiert hat. Mein OS ist Win2k und Programmierumgebung das Microsoft
Visual Studio.

Sourcecode ist im Anhang.

So, das wars eigentlich schon. Ich habe das Warten auf die 'Ankunft'
der Zeichen uach schon mit dem WaitCommEvent versucht - da ist er aber
auch nach einiger Zeit hängengeblieben.

Hat jemand eine Idee, was hier nicht funktioniert?!?

Ich bin bereits am überlegen, ob ich nicht auf eine andere Möglichkeit
umsteige mit dem PC zu kommunizieren (z.B. parallele Schnittstelle).
Gibt es hierzu irgendwelche Vorschläge, Links?!?
USB möchte ich nicht verwenden, weil mir das im Moment noch zu
kopmliziert ist und Ende Januar die Kommunkikation funktieren muss ...

Danke für eure Hilfe!!
Grüße
Steffen

Autor: Ronny Schulz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der ganze Code sieht recht merkwürdig aus. Aber da ich nicht genau,
weiss was Du damit später machen willst, ist das erst einmal egal. Die
do-while-Schleife hat natürlich einen großen Nachteil, fällt irgdendwo
ein Byte unter den Tisch ist alles vorbei und der bleibt bei ReadFile
stehen. Ich würde vorher prüfen, ob auch 2 Bytes anstehen und ggf. die
Routine abbrechen.

Autor: Steffen Burr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Es ist ganz einfach: Ich sende 3 Byte über die serielle Schnittstelle
und warte dann auf 2 Bytes die zurückkommen (müssen).

Vielleicht kann mir hier jemand einen Tipp geben, wie ich das in C++
realisieren kann!?!

Du sagst der Code sieht merkwürdig aus. Hast du evtl ein Beispiel, wie
man das machen sollte oder kannst du etwas genaer sagen, was an dem
Code merkwürdig ist?

Danke!
Steffen

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fehlerbehandlung gehört in jede serielle Kommunikation, da sie immer
wieder auch tatsächlich vorkommen. Das einfachste Verfahren ist ein
Timeout, d.h. antwortet die Gegenstelle nicht in angemessener Zeit,
wird diese Kommunikation erstmal abgebrochen und noch einige Male neu
gestartet. Passiert wieder nichts, wird das Programm mit Fehlermeldung
beendet. Auf feste Byteanzahl zu warten, ist gefährlich.

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
wenn ich das richtig sehe, benutzt Du malloc ohne am ende der Funktion
auch ein free zu nutzen.

Bei deinem kurzen Puffer geht doch auch ein lokaler Puffer

char puffer[3]; // oder auch etwas mehr

Das würde Dein Problem mit den 2 Stunden erklären. Dein Speicher ist
voll.

Das Verrückte Pferd hat natürlich recht, Timeout und Fehlerbehandlung
sind nicht zu vernachlässigen.

malloc und free sind auch etwas aus der Mode. In C++ gibt es new und
delete.


Dieter

Autor: Steffen Burr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Danke für eure Antworten.

Ich hätte das Warten mit der Funktion WaitCommEvent gemacht.
Wie kann diese Wartefunktion abbrechen (für einen TimeOut bzw. eine
Timeout-Zeit einstellen)?

Das Malloc werde ich dann auch abändern ...

Grüße
Steffen

Autor: Manfred Glahe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Steffen,

" d.h. sie hängt imho in der
                  Schleife fest, in der sie auf die Antwort wartet"

wie sehen denn dann die Statusregisterbits aus?
Höhrt sich für mich wie ein typischer Emfpangsregisterüberlauf an,
kannst Du daß ausschließen?

MfG  Manfred Glahe

Autor: Steffen Burr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Manfred,

das Programm ist ja für den PC. Einen Empfangsregisterüberlauf kann ich
in soweit eigentlich ausschließen, als dass erst nachdem 2 Byte
empfangen wurden auch wieder 3 gesendet werden (und damit erst nach dem
empfangen wurde wieder welche ankommen). Das Empfangsregister wird ja
beim auslesen geleert, oder?!

Wie kann man die Statusregisterbis denn auslesen? Über einen Debugger
?!?

Steffen

Autor: Manfred Glahe (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Steffen,

im Anhang ein TP Prog. welches auch das Statusregister ausliest.

MfG  Manfred Glahe

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.