C Einfach gehaltenes Kommunikations Protokoll

[Janiiix3]

Liebe Community,
seit einiger Zeit beschäftige ich mich schon mit dem Thema "Kommunikation zwischen µC". Im Netz findet man viele schöne und unschöne Lösungswege / Lösungsansätze.
Von: "Wie viele Bytes sind sinnvoll zu versenden?", "Wie lange soll das ganze dauern?", "Checksumme?"

Dazu habe ich mir mal ein paar Gedanken gemacht und möchte diese mit euch teilen.
Ich gehe nicht davon aus das es perfekt ist, ganz im Gegenteil.
Würde mich sehr über Ideen und Vorschläge von euch freuen.

Hier mal der Link zu dem Repository >>KLICK<< (frame.h & frame.c)
In diesen beiden Dateien befinden sich Routinen zum zusammenbasteln eines "Telegrammes" (will ich es mal nennen).
Sollte sich das jemand mal anschauen, würde ich mich sehr über Feedback freuen.
Das ganze ist noch mehr oder weniger im Aufbau. Also es wird noch aktiv daran gearbeitet.

Ich hoffe das in der "frame.h" alles gut und ausreichend beschrieben steht?
Das ganze soll später die Kommunikation zwischen zwei Teilnehmer vereinfachen (ursprünglich für UART gedacht).


Evtl. kann es den ein oder anderen ja sogar behilflich sein.

Mfg
Janiiix3

 

[LotadaC]

Kannst Du uns(*) an dem Konzept teilhaben lassen? Ich stelle mir grad sowas wie 'ne Bibliothek vor, die mittels bedingter Kompilierung durch vorgegebene Kompilervariablen/-konstanten entsprechende Routinen (Senden/Empfang/Auswertung des Overheads/Bereitstellung der Nutzdaten) bereitstellt.

(*) ... nicht-C-Programmierern - wenn es ein einheitliches Protokoll sein soll, ließe sich dasselbe ja auch für Bascom, Assembler usw umsetzen, und es wäre egal, wer mit wem kommuniziert...

 

[Janiiix3]

@LotadaC Du hast Recht. Ein "einheitliches" Protokoll war eine total falsche Überschrift für das Thema.
"einfaches" trifft es besser.

Das ganze ist eigentlich ziemlich simpel gehalten.
Es gibt ein Datenfeld was aktuell 5 Byte groß ist ( der eigentliche Header von dem ganzen Telegramm ).

Der aktuelle Aufbau vom Header:
[0]: Gesamte Länge des Frames / Telegrammes.
[1]: Datentyp der Nutzdaten ( char , int. usw. ).
[2]: Telegramm Identifikation
[3]: Exitcode
[4]: Checksumme
Alle weitere steht in der "frame.h" beschrieben.

Mit den Funktionen die diese "Bibliothek" beinhaltet kann man jetzt quasi sich dieses Datenfeld bequem zusammen bauen lassen und die Nutzdaten mit hinten dran hängen lassen. Das ganze wird dann noch mit einer Checksumme versehen.

Man muss sich nicht mehr um die Berechnung der gesamten Länge kümmern und die Checksumme wird auch automatisch von der Funktion berechnet.
Man könnte das quasi auch in andere Programmiersprachen umsetzen bzw. umbauen.

Das ganze Ist jetzt aber kein Hexenwerk ( also nicht zu viel erwarten.. )

Hoffentlich ein bisschen besser erklärt..

 

[LotadaC]

Der aktuelle Aufbau vom Header:
[0]: Gesamte Länge des Frames / Telegrammes.
[1]: Datentyp der Nutzdaten ( char , int. usw. ).
[2]: Telegramm Identifikation
[3]: Exitcode
[4]: Checksumme

Die Gesamtlänge des Telegrammes ist sinnvoll, wenn die Länge nicht anderweitig bekanntist/übertragen wird. Aber wozu dann der Exitcode?

Bei einigen Kommunikations...wegen wirkt ja bereits das Protokoll der Verbindung: Chip Select bei SPI, Start/Stop-Conditions bei I²C, bei einigen 1wire-Verbindungen gibts 'ne Reset-Condition usw. Aber beim UART hast Du sowas nicht (wenn Du auf die Handshake-Signale verzichtest).
Wenn die Gesamtlänge des Telegrammes variieren darf, und dem Empfänger nicht bekannt ist, muß entweder vorher die Länge des jeweiligen Telegrammes übermittelt werden, oder ein End-Of-Telegram-, End-of-Nutzlast- oder wie auch immer -Char gesendet/ausgewertet werden. Sinn macht das zB bei Strings, aber nicht, wenn einfache Rohdaten übertragen werden sollen.

"Typ der Nutzdaten" erschließt sich mir nicht. Ok, der Empfänger weiß jetzt, daß 'n vorzeichenbehaftetes Byte, oder 'ne vorzeichenlose acht-Byte-Ganzzahl oder 'n Byte mit zwei Nibbles oder 'ne vier-Byte-Fließkommazahl oder so kommt, aber was soll er dann damit machen (außer sie in entsprechende Arrays zu sortieren)?

Meine Grundüberlegungen sind immer:
1.: Wird ein Hardware-Modul genutzt, oder muß man in Software ran? Hintergrund: Bei Hardware bekommt man die Daten "Byteweise" (jaja, ggf mit 5..9Bits pro "Byte" usw), möglicherweise vorgefiltert (I²C-Adresse) vom Modul übergeben - beim Software-Weg muß man sich selbst Bitweise drum kümmern.
Dafür kann man beim Bitweisen Empfang dann gleich diverse Checksummen miterledigen.
2.: Was soll eigentlich übertragen werden? ASCII-Strings, die zB auf 'nem Display ausgegeben werden sollen oder Sensordaten, die geloggt werden sollen, Sollwerte für PWM usw.

Mal ein Beispiel von mir:
Aufgabe war, zwei Lichtquellen anzusteuern, und zwar möglichst kompakt. Ich habe einen ATtiny25 vorgeschlagen, der die beiden LEDs direkt mittels PWM treibt.
Da UART vorgegeben war, und der Tiny selbst kein HW-Modul dafür besitzt, Soft-UART. Am Ende hatte ich meiner Erinnerung nach im Protokoll sogar 4 PWM-Kanäle vorgesehen.
Ich habs nicht mehr genau im Kopf, aber es wurde immer ein Kommandobyte, und danach ggf ein Wertebyte gesendet.
Dabei konnte fast alles nur über das erste Byte festgelegt werden - nur beim Festlegen der Sollwerte mußte ein zweites Byte übertragen werden.

Das Kommandobyte schaltete dabei bereits während des Bitweisen Empfanges durch die Statemachine...

 

[oldmax]

Hi
Exit-Code könnte Sinn machen, wenn weitere Datensätze folgen. Z.B.. Exit-Code 0 wäre letzter Datensatz, Exit-Code 3 , es folgen weitere Daten. Könnte Sinn machen, um eine große Datenmenge zu händeln, ohne den Controller zu lange zu blockieren. Aber natürlich geht sowas im Interrupt. War auch nur so ne Idee. Ansonsten könnte ich mir vorstellen, bei wichtigen Daten diese zurück zu spiegeln und einen OK Code abschließend zu senden
Gruß oldmax