www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik rs232 befehlsstruktur


Autor: Simon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,

wie sieht eine sauber strukturierte KOmmunikation PC<-> µC aus, wenn man 
bspw 10 Parameter im µC mit dem PC kontrollieren/regeln möchte und die 
Parameter einzeln geregelt werden.

1.: soll der PC immer den kompletten Datensatz übertragen?
2.: gibt es eine Standardadressierung /Zeichenfolge für die einzelnen 
Parameter oder definiert das jeder wie er will?
3.: ist es der richtige weg, Fehler in der Kommunikation (bspw. 
unvollständige Übertragung) über Timeouts abzufangen?

Viele Grüße
Simon

Autor: rene (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt viel Ansaetze, mit Vortteilen und Nachteilen, die muss man je 
nach Bedingungen abwaegen.

zB http://www.ibrtses.com/embedded/shortmsgprotocol.html

Zu den Fragen :
1) nein, da kaum erweiterbar
2) nein
3) CRC & Timeout

Autor: oldmax (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi
Nun, Aufwand zu treiben ist meist kein Problem. So könnte man z.B. ein 
Protokollverfahren entwickeln, welches entsprechend überwacht wird. So 
ist mir z.B. ein Protokoll bekannt, in welchem eine Befehlsstruktur über 
mehrere Telegramme abgewickelt wird.
1. Anforderung ( 2 Zeichen v. Sender )
2. Antwort ( 2 Zeichen v. Empfänger mit ok oder Err-Kennung)
bei ok-
3. Nutztelegramm ( lfd.Nr, Bef.Code, Nutzdaten, Prüfbyte, Ende-Kennung 
v.Sender)
4. Antwort (Telegramm gespiegelt, mit einer eigenen lfd.Nr v. Empf. mit 
ok oder Err-Kennung)
5. Wenn ok, dann erledigt, ansonsten Maßnahme oder Wiederholung.
Das Prüfbyte war in diesem Fall nichts anderes, als eine XOR-Verknüpfung 
aller Telegrammbytes, außer dem Prüfbyte selber unf der Ende-Kennung.
Ein solches Handling gibt dir die Möglichkeit, über den Befehlscode die 
Nutzdaten entsprechenden Routinen zuzuweisen. Die lfd.Telegrammnummer 
muß nicht ins uferlose laufen. In dem vorgegebenen Fall war ein 
Telegramm mit der Nummer 0 ein Starttelegramm nach Zuschaltung, danach 
wurde nur zwischen 1 und 2 gewechselt. Ist aber nicht unbedingt 
notwendig, weil der Befehlscode entsprechende Information auch tragen 
kann.
Gruß oldmax

Autor: Thilo M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze die VBus - Struktur.
http://resol-vbus.googlegroups.com/web/VBus-Protok...
Ist recht knapp, eindeutig und flexibel aufgebaut.
Vielleicht kannst du dir da ein paar Anregungen holen. ;)

Autor: Simon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na dass nenne ich hilfreich!
Vielen Dank, werde mir das zu Gemüte führen...


Viele Grüße
Simon

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hängt auch von deinem verwendeten System ab.
Was spricht z.B. gegen ein Web-Interface?

Autor: Simon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin mit dem/einem 'webinterface' nicht vertraut. Ich habe eine im 
prinzip autonom agierende Steuerung, der ich mit Hilfe der rs232 neue 
Parameter übergeben möchte (und diese evtl. auslesen). Also in der art:

neuer DAC_1-Wert = 4095
neuer DAC_2-Wert = 2023
neue Zeit_1=256
...
Die notwendige Hardware (max232) ist bereits angelegt, es geht mir also 
nur um das Protokoll.

Viele Grüße

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich benutze gerne das Protokoll, was die LMX9820 BlueTooth Chips 
benutzen, das macht sich ganz gut.

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

es müssen natürlich alle möglichen Fehler bearbeitet werden. Ich 
betrachte das jeweils als Transaktion: Befehle/Daten senden - Antwort 
empfangen - Prüfsumme checken - Antwort analysieren. Nur wenn bis zum 
Ende der Transaktion alles fehlerfrei ist, ist sie erfolgreich, sonst 
muss sie wiederholt werden.

Noch ein Tipp: verwende ASCII-Text, also z.B. "195," anstatt eines 
binären Bytes. Habe ich früher auch anders gemacht, aber die paar Bytes 
mehr spielen keine Rolle und das Debuggen wird auf allen Ebenen eminent 
vereinfacht. Früher bin ich mit den Taschenrechner dagesessen und habe 
dauernd Hex in Dezimal gewandelt, heute lese ich einfach mit.

Das haben andere auch gemerkt: alte Protokolle wie BitBus waren total 
binär, im Internet ist heute alles Text.

Gruss Reinhard

Autor: Karsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ascii übertragen. IGITT!!!

Mein Ansatz:

Startbyte, Länge, Befehl, Payload, CRC, Stopbyte

Gegenstelle antwortet mit ACK oder NACK.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karsten schrieb:
> Ascii übertragen. IGITT!!!

Kommt immer drauf an, wer an der Gegenstelle sitzt und wieviele Daten 
übertragen werden.

Wenn es ein Mensch ist, dann ist ASCII einfacher.
Wenn es ein Programm ist, dann ist binär einfacher.

ASCII hat den unerhörten Charme, dass man zum Testen bereits mit einem 
Terminalprogramm am PC loslegen kann.

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.