Hallo, ich will für meine Basteleien ein serielles Protokoll erstellen. Bisher habe ich recht "menschenfreundlich" ein paar "Symbole" per Terminal zum Controller geschickt. Im Endeffekt bin ich bis jetzt auch gut damit gefahren. (Symbole für reset, kommandos gefolgt von werten) Allerdings wird es bei grösseren sachen schon recht müssig ! Die ganzen Kommandos und deren Parameter zu definieren, (sich zu) merken und anzuwenden. Wie macht Ihr das ?
Thomas W. schrieb: > Hallo, > > ich will für meine Basteleien ein serielles Protokoll erstellen. > > Bisher habe ich recht "menschenfreundlich" ein paar "Symbole" per > Terminal zum Controller geschickt. > Im Endeffekt bin ich bis jetzt auch gut damit gefahren. > (Symbole für reset, kommandos gefolgt von werten) > > Allerdings wird es bei grösseren sachen schon recht müssig ! > Die ganzen Kommandos und deren Parameter zu definieren, (sich zu) merken > und anzuwenden. > > Wie macht Ihr das ? :-) Ein Kommando '?', woraufhin der µC mit einer Liste von Kommandos und ihren Argumenten antwortet.
Thomas W. schrieb: > Allerdings wird es bei grösseren sachen schon recht müssig ! Definiere, was in diesem Satz "müssig" heißen soll. "Müßig" kannst Du nicht meinen, das hat eine Bedeutung, die nicht zu Deinem Satz passt. Meinst Du "lästig" oder "umständlich"?
@ Rufus : Ja Du hast recht, wobei müssig wohl auf den Kerl vor der Tastatur passt. @ Wilfried : Naja, ich nötige meinen µC Zahlen als String zu verarbeiten. Dadurch muss ich führende Nullen abschicken. Kommunikation per UI braucht sowas nicht, ist eher hinderlich. Nebenbei, gibts diese >libserial< in Debian ? Kompiliert bei mir deswegen nicht. Warum hast Du eigentlich libserial und nicht qextserial verwendet ? @ KarlHeinz: Ja genau das habe ich gesucht ;) Nee, irgendwie weiss ich gerade nicht was ich will. Terminal, Terminal und klickibunt QT, oder nur QT. Das Abwägen ist echt schwer. Wenn Klickibunt wäre es doch blöd : 1. Den ASCII-Mensch modus zu benutzen. 2. Auf zwei Seiten (PC,µC) getrennt zu entwickeln. Immerhin müssen beide seiten die Kommandos kennen. Ich habe sowas noch nie gemacht und bin mir unsicher. Vielleicht wäre es auch gut alles per GUI erreichbar zu machen und den ASCII-Menschmodus zu kastrieren.
>Protokoll definieren in C
Ein Protokoll definiert man auf Papier und implementiert zB in C. Es
laeuft dann auf eine Zustandsmaschine raus.
Thomas W. schrieb: > Wenn Klickibunt wäre es doch blöd : > > 1. Den ASCII-Mensch modus zu benutzen. Textbasierte Protokolle lassen sich viel leichter debuggen, da du dir einfach mal mit einem Terminalprogramm anschauen kannst, was da rauskommt und von diesem aus aus Kommandos abschicken kannst. Ohne Textmodus sitzt du dann nachher an einem Hexeditor und friemelst dir deine Werte aus irgendwlechen Rohbytes zusammen. Wenn du eine neue Funktion auf der µC-Seite implementierst, kannst du die erst ausprobieren, wenn du auch die GUI-Seite fertig hast. Und wenn dann das Kommando nicht ausgeführt wird, ist es schwerer, rauszufinden, auf welcher Seite denn nun der Fehler liegt, als wenn du mal mit einem Terminalprogramm schauen kannst, was die GUI schickt bzw. was passiert, wenn du es selbst dem µC schickst. > 2. Auf zwei Seiten (PC,µC) getrennt zu entwickeln. > Immerhin müssen beide seiten die Kommandos kennen. Wenn du es nicht auf Textbasis machst, müssen sie das doch auch. > Vielleicht wäre es auch gut alles per GUI erreichbar zu machen und den > ASCII-Menschmodus zu kastrieren. Es muß ja nicht gleich ein vollwertiger Kommandozeileninterpreter mit Kommando-History und Autovervollständigung sein. Ein Zeichen für das Kommando, dann ein paar Werte z.B. Komma getrennt reicht ja schon.
@Rolf: Genau so mache ich das im moment (ohne Komma). Allerdings wird mir das viel zu umständlich, besonders wenn ich den verlauf von Istwerten darstellen will. Im moment läuft dann eine TAB separierte liste durch das Terminalfenster, nicht wirklich hübsch die Hausnummern... Das ganze lässt sich zwar gut einlesen aber für einen Wert schicke ich 5Bytes anstelle von 2. Irgendwie ist das Verschwendung. Heute Nacht hatte ich eine Idee : Im Prinzip komme ich doch mit knapp vier Funktionen aus. Startbyte, Endbyte, Variable lesen und Variable schreiben. Denn alles was ich konfiguriere muss ich im µC irgendwo im Speicher ablegen. Die Funktionalität schreiben und lesen ist in beide Richtungen gleich. Das müsste man doch kapseln und auf beiden seiten direkt "anbinden" können. Sollte doch das Implementieren auf beiden Seiten in einfache Schreib und Lesezugriffe vereinfachen. Die FSM auf dem Controller, welche die eigentliche Funktionalität aufruft, bedient sich dieser Variablen und ev. einem "Update Call". Sollte doch funktionieren !?
Thomas W. schrieb: > Das ganze lässt sich zwar gut einlesen aber für einen Wert schicke ich > 5Bytes anstelle von 2. > Irgendwie ist das Verschwendung. IN den meisten Fällen ist das ziemlich wurscht. Denn am anderen Ende sitzt ja ein Mensch vor der GLotze, der sich die Werte ansieht. Und der hat nun mal eine begrenzte Aufnahmefähigkeit (auch zeitlich!) die um Grödenordnungen über dem liegt, was du bei einer textbasierten Übertragung locker erreichst. > > Die FSM auf dem Controller, welche die eigentliche Funktionalität > aufruft, bedient sich dieser Variablen und ev. einem "Update Call". Vergiss auch nicht, dass eine textbasierte Übertragung mit einfachen Mittel absicherbar ist. Kommandos enthalten Buchstaben, Werte enthalten Ziffern, Werte werden durch Komma voneinander getrennt und eine Übertragung wird mit einem \n abgeschlossen. Alleine das schafft schon eine gewisse Übertragungssicherheit und einfache Möglichkeiten zur Sicherstellung der Erkennung von Fehlern, die du bei rein binärer Übertragung nicht hast. Und textbasierte Übertragung und GUI schliessen sich ja nicht aus. Der Druck auf einen Butten schickt einfach nur eine andere Bytesequenz auf den Weg, mehr ist das nicht.
Also ich hatte schon vor in Bytes über die Schnittstelle zu senden. (KISS) Die Sache mit dem Werteblock wird auch erstmal zu kompliziert. Also alles wie bisher : 1. Startzeichen 2. Kommando oder Identifizierung von Werten. 3. Ein oder mehrere Bytes für Einstell - oder Istwert. 4. Ende Zeichen "/n" Aber die Idee die Vereinbarungen in einen Header zu packen halte ich noch für sinnvoll. Dann gehe ich mal an die Arbeit :)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.