www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Suche Protokoll


Autor: Günter R. (holzi_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute

Ich hoffe ich bin im richtigen Forum...

Ich bin auf der Suche nach einem guten Kommunikations Protokoll für 
folgende Anwendung:

Ich stell gerade ein neues Testsystem zusammen und nun stellt sich die 
Frage wie ich die Relais MUX Karten am besten anspreche. Der Aufbau ist 
ca. so:

PC- > FTDI2232H -> RS485 -> ~Kabel~ -> RS485 -> AVR

Der AVR schiebt dann über SPI die Daten auf einige 74HC595 raus wobei 
diese Anzahl immer unterschiedlich sein kann (also einmal nur 4x8bit 
oder auch 12x8bit). Weiters würde ich gerne die Möglichkeit für DA/AD 
Wandler nicht verbauen und natürlich auch digitale Eingänge (74HC165) 
sollten sich verbauen lassen.

Am liebsten würde ich nur eine Software für den AVR schreiben und per 
Protokoll die HW abbilden lassen. Ich dachte schon an ModBus, aber der 
ist gerade bei den analogen Sachen (AD/DA Wandler) nicht gerade 
geeigent, oder?

Was würden die alten Hasen in diesem Fall verwenden. Es gibt sicher 
genug bei euch die so etwas ähnliches auch schon mal aufbauen mussten...

ich danke schonmal für die Infos!

Günter

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

Bewertung
0 lesenswert
nicht lesenswert
Wie zeitkritisch ist die Übertragung?
Wie häufig müssen die Ausgänge geschaltet werden?

Autor: Günter R. (holzi_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ups, ganz vergessen, sorry

Zeit ist unkritisch und so ein setztvorgang sollte in ca. 1ms gemacht 
sein. Wenns 5ms dauert ist es aber auch egal...

So ein Setzvorgang wird ca. einmal pro Sekunde gemacht. Bei den DA 
Wandlern könnte es schneller werden aber nicht schnaller als 50-100ms.

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

Bewertung
0 lesenswert
nicht lesenswert
Hmm.
Gibt es Einwände gegen

Ausgang setzen
**************
S<Nr>=<Wert>;

S      ... Setze
<Nr>   ... Nummer des Ausgangs. Ausgänge werden einfach durchnummeriert
           Ein ev. DA WAndler hat genauso eine Nummer
<Wert> ... Wert der zu setzen ist.
           Bei ordinären I/O ist das 0 oder 1
           Bei analogen Ausgängen ist das der Wert für den DA Wandler
;      ... Abschluss des Kommandos


?<Nr>;
******
Eingang abfragen
Der entsprechende Eingang schickt seinen Wert zurück. Wieder
digital: 0 / 1
analog:  entsprechender Zahlenwert

Format könnte zb sein
V<Nr>=<Wert>;

V      ... Value of
<Nr>   ... Nummer des Eingangs
<Wert> ... Wert des Eingangs

Selbigen Datensatz könnte der Peripheriebaustein auch selbsttätig 
generieren und zum Host schicken, wenn sich sein Eingang verändert hat. 
Das könnte man vom Host aus zb auch einstellbar machen ob er das darf 
oder nicht.

Autor: Günter R. (holzi_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab vergessen zu sagen, dass ich mehrere Slaves auf der 
Schnittstelle habe.

Master soll also immer der PC sein. Ich brauche also bei den Slaves eine 
Adresse.

Bei deinem Vorschlag wäre noch ein Nachteil, dass ich für jedes Relais 
einen Befehl brauche.

Ich dachte eher an sowas:

<Start><Addr><DatenType><Anzahl Byte><n Daten><CRC><Ende>

DatenTyp wäre hier also In, Out, DA oder AD. Die passenden Daten würde 
ich im PC verwalten. Der µC soll hier einfach nur "dumm" das passende 
dazu machen. Beispiel bei mir:

<Start><Addr><DatenType><Anzahl Byte><n Daten><CRC><Ende>
   #     12       1           4       12 1 0 0 crc   ;

Ich muss auf jeden Fall verhindern, dass in den Daten ein 
<Start><Adresse> vor kommt. Ich hoffe du verstehst auf was ich raus 
will...

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

Bewertung
0 lesenswert
nicht lesenswert
Günter R. schrieb:

> Bei deinem Vorschlag wäre noch ein Nachteil, dass ich für jedes Relais
> einen Befehl brauche.

Genau deswegen hab ich nachgefragt, wie das Zeitverhalten aussieht :-)
es hindert dich allerdings auch nichts Befehle zu postulieren, die 
dieses Manko beheben.
Zb ein Broadcast, so dass alle Ausgänge darauf reagieren.
Oder Broadcast für Ausgänge eines bestimmten Typs
oder ...

denk dir was aus :-)


> <Start><Adresse> vor kommt. Ich hoffe du verstehst auf was ich raus
> will...


Ich weiß worauf du raus willst.
Genau aus dem Grund hab ich nämlich ein Kommando einfach als Text 
aufgefasst. Dann ist diese Forderung nämlich leicht zu erfüllen, während 
sie bei rein binärer Übertragung eher schwer zu erfüllen ist (wenn auch 
nicht unmöglich). Und wenn du jetzt deine Bytes mal abzählst kommst du 
drauf, dass du auch nicht signifikant weniger Bytes brauchst :-)

Wobei ich allerdings auch zugeben muss, dass ich eine gewisse Affinität 
zu textbasierten Protokollen habe.
Warum?
* weil sie bisher eigentlich immer schnell genug waren
* die Frameintegrität ist leicht herzustellen
* der Aufwand sie zu parsen hält sich in Grenzen
* sie sind leicht zu testen solange das Frontend noch nicht
  fertig ist.

Autor: Günter R. (holzi_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, wenn ich ASCII übertrage, gehts natürlich. Heißt aber, dass ich im 
AVR ASCII -> Binär wandeln muss, find ich eher unschön. Natürlich ist es 
schöner wenn man mit horcht, aber wenn ich in der PC SW etwas mehr 
investiere, kann ich es auch lesbar nach außen tragen, was ich schicke.

Naja, werd mir erst mal das Modbus RTU Protokoll anschauen. Evtl. lässt 
es sich ja "billig" erweitern.

Danke trotzdem für die Hilfe!

Autor: Kakadu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Heißt aber, dass ich im
>AVR ASCII -> Binär wandeln muss, find ich eher unschön.

Durch die Redundanz kannst Du aber besser auf Fehler prüfen. So dürfen 
in einem numerischen Feld nur Zeichen '0' - '9' vorkommen. Auch Zeichen 
wie '=' oder ';' synchronisieren die Daten.

Eine andere Möglichkeit wären gepackte Hexwerte, wo dann nur '0' - '9' 
und 'A' - 'F' vorkommen dürfen. Ich nehme immer gerne Befehle, die wie 
Datenzeilen eines Intel-Hex-Formates aufgebaut sind. Die enthaltene 
Prüfsumme sichert nochmals ab. Dafür ist es schwieriger per Terminal zu 
simulieren und mitzulesen.

Autor: gk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt beim blauen C eine Relaiskarte die ist kaskadierbar, da kannst 
Du mal
nachschauen, wie die das gelöst haben:

http://www.produktinfo.conrad.com/datenblaetter/17...

Ich tendiere auch eher zu Textbasierten Protokollen, zum Beispiel eine 
Untermenge von SCPI,

gk

Autor: Günter R. (holzi_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok der Ansatz mit hex find ich gut. Damit lässt es sich eigentlich 
lesbar und für den µC gut machen.

Beispiel:

<Start><Addr><DatenType><Anzahl Byte><n  Daten><CRC><Ende>
   #    001       01         08       00100A00  crc   ;

Damit wäre der Byte "Verbrauch" relativ gering und der µC muss bei den 
Daten immer nur zweier Pakete wandeln. Adresse fix auf drei Byte damit 
hätte ich 4095 Adressen. 255 verschieden Datentypen reicht auch und 255 
für numBytes reicht auch.

Ich denke damit sollte es klapppen! Werds mal implementieren und schauen 
obs noch irgendwo klemmt...

Danke nochmal

Autor: Stephan W. (sir_wedeck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Günter,
nimm für sowas ModBus ist recht verbreitet und ist recht einfach zu 
programmieren.

Wenn du dafür Hilfe brauchst, hier wird dir geholfen.

www.modbus.org

Stephan

Autor: Günter R. (holzi_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stephan

Ich hab mir das Modbus vorher schon angeschaut, aber AD/DA Sachen sidn 
in diesm Protokoll meines Erachtens nicht wirklich abgebildet. Da hätte 
ich bei meinem eigenen Protokoll viel mehr Möglichkeiten.

Ok bei Modbus RTU bräuchte ich ein paar Bytes weniger, habe aber dadurch 
einige Nachteile (Lesbarkeit, max. 255 Adressen, usw.). Weiters muss ich 
beim RTU aufs Timing achten, was beim eigenen durch Start und Ende 
komplett fallen würde.

Kurz gesagt, was bringt mir hier Modus? Es wird einen Grund geben, sonst 
würdest du Modbus ja nicht vorschlagen gg

Autor: Stephan W. (sir_wedeck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
also in Modbus ist auf 16Bit Werten, sogenannten Registern aufgebaut.
Was sich in den Reg. befindet ist Definitionssache. AD / DA Werte werden 
in in ein Reg. abgelegt und gut.

Lass das mit dem RTU weg, ist zu alt. Das andere, binäre, ist besser 
geeignet und lässt sich auch gut lesen.
Die Beschränkung auf 255 Slaves stimmt aber.

Stephan

Autor: Günter R. (holzi_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja wenn ich RTU nicht nehmen soll, bleibt ja nur Modbus ASCII übrig. 
Da hab ich meiner Meinung nach mehr Daten als bei meinem eigenen.

Ich brauche für 32 I/Os 19 bytes, Modbus im Ascii Mode braucht 27 bytes.

OK Modbus wäre ein Standard Protokoll was natürlich wieder als pos. 
anzusehen wäre.

Aber ich habe dann immer noch das Problem, dass ich meine 
Sonderfunktionen in die bestehende Modbus Funktionliste packen muss. Und 
dann bin ich meines Erachtens wieder weg von einem Standard.

Dazu kommt, dass ich bei meinem Protokoll noch eine Sende Adresse 
hinzufügen könnte und somit auch Interrupts oder ähnliches realisieren 
könnte.

Ich werd jetzt erst mal mein eigenes ausprobieren und wenn das nicht 
klappen sollte, kann ich immer noch mit Modbus herum probieren.

Gruß Günter

Autor: Stephan W. (sir_wedeck)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

>Naja wenn ich RTU nicht nehmen soll, bleibt ja nur Modbus ASCII übrig.
sorry, meinte natürlich anders rum, RTU ist das richtige und das ASCII 
das ältere.

Bin halt schon etwas raus, sorry.

Stephan

Autor: Günter R. (holzi_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und ich dachte schon ich spinne gg

Eben aber die RTU Sache hat die Pflichtpausen und den min. Abstand 
zwischen Befehlen drin. Da kann ich mir vor stellen, dass der FTDI (hab 
schon genug mit dem Ding mit gemacht) nicht immer so brav mit macht. 
Wenn ich mir von dem Teil die Timings anschaue, stell ich immer wieder 
solche Lücken zwischen einzelnen Blöcken fest.

Naja, werd mal basteln und dann wird es sich schon zeigen, was sich 
besser eignet.

Gruß Günter

Autor: Christian Kreuzer (christian_rx7) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau dir doch mal das S.N.A.P. Protokoll an, ich finde es eigentlich 
ganz gut und vor allem sehr universell: 
http://www.kreatives-chaos.com/artikel/snap-protokoll
http://www.hth.com/snap/

Christian

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.