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
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.
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
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.
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
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.
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
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?
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.