Forum: Mikrocontroller und Digitale Elektronik Wie serielle Kommunikation zwischen µC und PC aufbauen???


von Manuel (Gast)


Lesenswert?

Hallo Leute,

habe mal ein paar grundsätzliche Fragen zu der seriellen Kommunikation
zwischen µC und PC!!!!!

Ich arbeite mit PIC´s und habe ein Projekt am laufen, bei dem mehrere
Sensordaten mit einem µC(PIC) gesammelt werden, abgespeichert usw. Dies
geschieht alles auf dem µC Board und läuft soweit!

Zur Info, bin kein Profi auf dem Gebiet, habe aber schon mehrere kleine
Projekte mit µC gemacht, und möchte mir hier ein paar Denkanstöße
holen!

Nun habe ich die Aufgabe erhalten, eine "online" Anzeige der
angeschlossen Sensoren am PC zu erstellen! Außerdem sollen auch die
gespeicherten Messwerte zur Visualisierung an den PC übergeben werden!

Ich muss dafür jetzt ein Konzept oder Protokoll erstellen, wie man
einigermaßen sicher und sinnvoll die Daten vom µC zum PC übergibt!

Es sollte möglichst einfach zu implementieren sein!
Wie wird das in der Praxis gemacht, kann man z.B. mit Hilfe eines
VisualBasic Programms ein ASCI "D"(steht für Daten) für Datenanfrage
an den µC schicken? In meinem µC-Programm würde ich dann eben warten
bis ein "D" kommt und dann meine Daten auf die Schnittstelle geben!
Macht man das so, oder ist das nicht praktikabel?

Die Daten habe ich auf dem µC schon im ASCI Format Byteweise
gespeichert. Zu übertragen sind rund 200 Bytes am Stück, sollte man
diese stückeln oder kann man die am Stück rüberschieben?
Ich weiß, dass es unzählige CRC Prüfroutinen usw. gibt, aber das ist
wohl alles sehr aufwendig zu implementieren und mich würde mal
interresieren, wie das Ihr so macht?

Vielleicht habt ihr ja ein paar Ansätze und Informationen für mich!


Gruß


Manuel

von Unbekannter (Gast)


Lesenswert?

KISS ist die Devise: http://de.wikipedia.org/wiki/KISS-Prinzip

Mach' es so einfach wie möglich:

- Soll immer zyklisch gesendet werden, dann schickt der Controller das
einfach regelmäßig, egal ob Computer angeschlossen ist oder nicht.

- Soll der Datensatz auf Anforderung gesendet werden? Dann reicht dafür
der Empfang eines einzigen Zeichens. Andere Zeichen einfach ignorieren.

- Sind die Datensätze schon in ASCII-Format vorhanden, bietet sich als
Datensatztrennung ein "Newline" perfekt an.

- Prüfsummen: Wieviel Prüfsummen werden zwischen Modem und Computer
übertragen? Antwort: Keine. Alternativ: Was passiert wenn ein Datensatz
unter einer Millionen Sätze falsch übertragen wird, besteht dann die
Möglichkeit dass eine Atombombe explodiert oder der OP-Roboter wichtige
Aterien durchtrennt, oder ist dann in der sowieso mit Messfehler
behafteten Messreihe nur ein einzelner Messpunkt völlig daneben?

- Handschake: Mit wieviel Bits/s willst Du den Controller an den PC
hängen? Bei 2400 Bits/s und kurzen Datensätzen kannst Du auf Handschake
locker verzichten, wenn auf dem PC ein ordentliches Betriebssystem
läuft. Ansonsten gibt's Software-Handschake wie XON/XOFF (bei ASCII
ideal), oder auch Hardwarehandschake.

- XXX: Du musst Dir nur überlegen, was wirklich notwendig ist. Das
hängt immer sehr von der konkreten Situation ab.

von GerhardB (Gast)


Lesenswert?

Hallo Manuel

Ein einfaches Protokoll bei Ascii-übertragung wäre beispielsweise:

$..als Startzeichen
XXX..Sensor- oder Gerätenummer
YYYYY Messwert1
YYYYY Messwert2
#13 ein Returnzeichen

Der zu sendende Datenstrom sieht dann so aus:

$0010102300512#13

Der Pic könnte die Messdaten dann in vordefinierten periodischen
Abständen an den PC senden.

Die Kommunikation zum PIC könnte ebenso realisert werden. Ich habe
diesen Weg bei vielen meiner Projekte gewählt und sehr gute Erfahrungen
gemacht. Ausserdem kann man den Datenstrom in einem Terminalprogramm
sehr einfach auf Richtigkeit prüfen.

Zur Fehlerprüfung könnte man z.B. auch einen DLC (Data Length Code) an
den Datenstrom anhängen. Die Länge des eingelesenen Strings wird dann
ermittelt und mit dem DLC verglichen.

$0010102300512 DLC=14 #13

Beste Grüsse

Gerhard

von Unbekannter (Gast)


Lesenswert?

Warum denn so kompliziert?

Einfach die Werte eines Datensatzes durch Leerzeichen getrennt als
Zeile übertragen. Und wenn's dann unbedingt sein muss, kann die letzte
Zahl in der Zeile noch eine Checksumme sein:

Also einfach Zeilen dieser Form:

4 123 542 669
7 9832 0023 9862
17 0000001 435 453
5 -434 +43 -386

Das ist absolut eindeutig, und in diesem Beispiel ist die letzte Zahl
schon eine einfache Prüfsumme.
Dieses Protokoll ist auch tolerant: Es gibt keine Probleme mit
führenden Nullen, Wertebereich der Zahlen bei späteren Änderungen usw.

Wie gesagt: KISS

Alles was komplizierter wird birgt nur Risiko.

von GerhardB (Gast)


Lesenswert?

Hallo

Das $-Zeichen dient hier zur Synchronisation. Falls Zeichen verloren
gehen - das kann bei der Kommunikation mit der seriellen Schnittstelle
schon hin und wieder vorkommen - dann gerät die Lese-Routine nicht aus
dem Takt. Dies macht die Kommuninkation robuster. Das Verfahren wird
übrigens bei vielen elektronischen Geräten eingesetzt (beispielsweise
Escape-Sequenzen zur Steuerung von Drucker).

Die Leseroutine lässt sich auf diese Weise auch sehr einfach
realisieren. Die Leerzeichen kann man sich sparen. Durch eine
Erweiterung um Befehlscodes wäre die Anwendung zudem einfach
erweiterbar.

Weiter Vorteile (u.a) habe ich ja bereits beschrieben.

Und wie gesagt, ein Ansatz.

Freundliche Grüsse

Gerhard

von Jadeclaw (Gast)


Lesenswert?

Die Methode Leerzeichen zwischen den Werten und Zeilerücklauf als
Zeilentrenner birgt einen großen Vorteil zur Weiterverarbeitung.
Die Daten lassen sich auf diese Weise einfach in einer Textdatei
sammeln,
dann speichern und dem Ganzen die Extension CSV verpassen.
Diese Datei kann dann problemlos in Openoffice Calc oder Excel
importiert werden und man kann dann alles mit den Daten anstellen.

Gruss
Jadeclaw.

von GerhardB (Gast)


Lesenswert?

Hallo Jadeclaw

Du hast recht, eine Weiterverarbeitung der Daten, wenn man mit
Leerzeichen arbeitet ist damit sehr einfach. Man nimmt damit aber auch
einen bestimmten Overhead in Kauf.

Manel hat geschrieben, er wolle die Kommunikation uP und PC mit Hilfe
von Visual Basic realisieren. Nachdem die Daten vom seriellen Empfänger
am PC decodiert werden, können sie aber auch sehr einfach in eine Datei
geschrieben werden. In vielen Fällen möchte man mit der PC-Software die
Daten ausserdem auch gleich visualisieren. In diesem Fall muss man sie
sowieso decodieren.

Beste Grüsse
Gerhard

von Unbekannter (Gast)


Lesenswert?

GerhardB,

ich kenne mich mit VB nicht aus. Aber VB hat doch bestimmt auch
irgendeine INPUT oder READ funktion die eine String-Zeile mit Zahlen
parst und Varaiblen zuweist.

Also so ähnlich wie sscanf() in C.

Nichts ist doch einfacher als:
1
  int sensor, wert1, wert2, pruefsumme;
2
  sscanf(zeile, "%d %d %d %d", &sensor, &wert1, &wert2,
3
&pruefsumme);

Wenn Du da keine Leerzeichen dazwischen hast, musst Du erst den String
in Substrings zerlegen, dann die Substrings selbst parsen etc. Ist doch
alles ein Haufen Arbeit für nichts und wieder nichts.

Warum kompliziert, wenn es auch einfach geht?

von GerhardB (Gast)


Lesenswert?

Hallo

Unter der Annahme, dass die Datenzeilen wie von Dir gezeigt ankommen
ist der Weg, den man mit sscanf geht sehr einfach, das stimmt. Für
diesen von Dir bestimmten Fall auch i.O.

Schwieriger wird es allerdings, wenn die Daten unterschiedliche Länge
haben bzw. eine unterschiedliche Anzahl von Parametern übermittelt
wird.

Man sollte aber auch die Anforderungen die sich aus der Anwendung
ergeben sehen. Also z.B. wie sicher sollte z.B. die Kommunikation sein
oder wie funktioniert die Kommunikation zum uP.

Darüber hinaus sollte man sich aber jedenfalls auch über die
Wiederverwendbarkeit von Code Gedanken machen.
Mit dem oben aufgezeigten Ansatz ist man jedenfalls sehr flexibel.
Ich habe mir inzwischen ein Anwendungs-Framework für meine
uP-Anwendungen in der Sprache C geschrieben, mit der eine
"allgemeine" Kommunikation realisiert wird.
Dieses Framework konnte ich bereits in mehreren Projekten erfolgreich
einsetzen.

Was dann auf den ersten Blick etwas komplizierter aussieht erweist sich
dann doch als sehr praktikable Lösung. Die Decodierung der Daten lässt
sich übrigens auch recht einfach vornehmen. Die sehr mächtige
sscanf-Funktion wird auch nicht von allen uP-Compilern unterstützt.

Beste Grüsse

Gerhard

von Peter Dannegger (Gast)


Lesenswert?

Ich benutze auch Textkommandos, man kommt beim Debuggen viel einfacher
mit sinnvollen Texten zurecht und die Synchronisation bei Fehlern ist
recht einfach (Zeilenende->neues Kommando).

Ein Kommandointerpreter ist ganz schnell zusammengezimmert und sehr
flexibel (beliebig erweiterbar).

Als Standard ist auch SCPI nicht schlecht, wird von vielen Meßgeräten
verwendet:

http://de.wikipedia.org/wiki/SCPI


Peter

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.