mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Idee/Link etc. für einfachen Telegrammrahmen gesucht (UART)


Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich suche für eigene (private) Zwecke einen einfachen seriellen 
Telegrammrahmen (CMD-Byte, Datenbyte, Chesumme, Timing etc.). Bevor ich 
mir nun etwas selber definiere wollte ich mal nachhören, ob es evtl. 
bereits etwas "sinnvolles" mit wenig Overhead und guter 
Übertragungsqualität/-quantität gibt.

Warum das Rad nochmal erfinden ?

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gast schrieb:

> Warum das Rad nochmal erfinden ?

weils eigentlich so einfach ist: Adressbyte, Record-Typ-Byte, n x 
Datenbyte, 2 x Checksummmenbyte, CR.

Adresse ist nicht weiter zu erklären und wird nur gebraucht, wenn 
mehrere Stationen angeschlossen sein können.

Record-Type ist i.d.R. Command vom Master und Status vom Slave. D.h. der 
Master sendet ein Command und wartet auf die Antwort.

Datenbytes hängt natürlich vom Bedarf ab, bei geringer Datenrate kann 
man die Länge immer gleich machen, oder die Länge hängt vom Record Typ 
ab, oder man stellt noch ein Längenbyte voran.

Checksumme ist die hexadezimale Summe aller Bytes bis dahin (also MOD 
0xFFFF), man könnte auch CRC16 nehmen, aber das ist eigentlich nicht 
nötig.

Allerdings muss ich anmerken, dass ich früher so programmiert habe, 
heute mache ich alles im Klartext, weil das das Testen ungemein 
erleichtert. Das ändert aber nichts grundsätzliches, es werden eben 3 
Ziffern für die Adresse geschickt, dann Komma, dann 3 Ziffern für Record 
Typ, Komma, usw.

also 001,012,  ist Record Typ 12 an Station 1.

Natürlich gibts 1000 andere Möglichkeiten, die werden hier ja noch 
kommen.

Ich empfehle, erst mal eine Protokoll-Beschreibung auf Basis der Records 
zu erstellen (was steht drin, was kann geantwortet werden) und dann erst 
zu programmieren.

Gruss Reinhard

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit S.N.A.P. (Scalable Node Addressing Protocol).

Ein offenes Protokoll für allgemeine Zwecke ;-)

Autor: Tim Seidel (maxxie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, so trivial ist es nun auch nicht.

Man kann z.B. mal darüber nachdenken, ob CRC nicht die falsche Lösung 
ist, wenn man durch nicht 100%ige Timings z.B. öfters mal Bitfehler 
erhält.
Da kann man sich (wenn man nicht immer nochmal nachfragen/neusenden will 
oder kann) mal Fehlerkorrekturverfahren anschauen.

Autor: Andy H. (vinculum) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein professioneller Frame ist

10H 03 Datenbytes 10H 02 CRC

Falls ein Datenbyte 10H vorkommt, wird eine weitere 10H eingefügt.

Damit sind für alle Frames eindeutig Anfang und Ende definiert. Auch 
wenn ein Frame irgendwo getrennt wird (z.B. bei einer TCP-Verbindung)
http://www.tecchannel.de/netzwerk/management/40242...

10H = DLE
02 = STX
03 = ETX

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.