S.N.A.P. Protokoll

Wenn man mehrere Mikrocontroller vernetzten will braucht man, um die Komunikation zu ermöglichen, ein Protokoll. Davon gibt es viele, leider verbrauchen die meisten Ressourcen, die bei kleinen Mikrocontroller häufig nicht vorhanden sind.

Benötigt wird daher ein einfaches, anpassbares Netzwerkprotokoll, welches ohne großen Ressourcenverbrauch auch in schon bestehen Mikrocontrollerapplikationen eingesetzt werden kann.

Von der Schwedischen Firma High Tech Horizont (www.hth.com) wurde für deren Powerline Modem PLM-24 ein auch in kleineren Mikrocontrollern einfach zu implentierendes Protokoll entwickelt, welches aber auch in größeren Systemen einsetztbar sein sollte. Das Ergebnis war S.N.A.P. (Scaleable Node Address Protocol).

Eigenschaften von S.N.A.P.

S.N.AP. hat vielfältige Eigenschaften welche in der folgenden Aufzählung Aufgelistet sind:

Einfach zu erlernen, einzusetzten und zu implentieren
Freies und offenes Netzwerkprotokoll
Skalierbares Binärprotokoll mit geringen Overhead
Sehr geringer Bedarf an Ressourcen bei der Implentierung
Bis zu 16,7 Millionen adressierbarer Netzwerkknoten
Bis zu 24 protokollspezifischer Flags
ACK/NAK optional
Kommandomode optional
acht verschiedene Fehlerdetektionsmethoden (Checksum, CRC, FEC usw.)
Einsatz in Master-/Slaver sowie in Peer-to-Peer-Netzwerken
Unterstützt Broadcasting
Unabhändig vom Übertragungsmedium
Arbeitet in simplex, halb-, oder vollduplex Verbindungen
Skalierbarer Header mit 3 bis 12 Byte
Minimale Packetgröße ohne Fehlerdedektion ist drei Byte
Minimale Packetgröße mit Fehlerdedektion ist vier Byte
Anwenderspezifische Anzahl von Preamble Bytes (0-n)
Arbeitet mit synchroner und asynchroner Übertragung
Arbeitet mit der freien PLM-24 - TCP/IP Gateway Software von HTH

Diese lange Liste soll keinsfalls erschrecken. Die länge der Liste liegt vielmehr daran das Vorkehrungen für umfangreichere Systeme in allgemeinen Ansatz berücksicht werden müssen. Für die praktische Anwendung mit Mikrocontroller ist ein Minimalansatz jedoch vollkommen ausreichend. S.N.A.P. Protokollbeschreibung

Protokoll

Die Kommunikation zwischen Netzwerkknoten erfolgt immer in Form von Datenpaketen. Diese Datenpakete können unterschiedlicher Länge sein. Die totale Paketlänge wird von der Anzahl Adreß- und Datenbytes, der Fehlererkennungsmethode und einiger spezifischer Bytes bestimmt. Die Header-Definition-Bytes HDB2 und HDB1 bestimmen den Aufbau des Datenpakets (Telegramm) und somit die Paketlänge. Jedem Telegramm können eine beliebige Anzahl von Preamblebytes (Vorspann) vorangestellt werden, bevor es mit dem eigentlichen Synchronisationsbyte beginnt. Die Preamblebytes können beliebig sein, müssen sich aber vom Synchronisationsbyte unterscheiden.

Das folgende Beispiel zeigt ein kleines S.N.A.P. Paket mit CRC16-Fehlerdetektion:

| PRE | ... | SYNC | HDB2 | HDB1 |DAB1 | SAB1 | DB1 | CRC2 | CRC1 |

Name	Bezeichnung (original)	Bezeichnung (deutsch)
PRE	Preamble Byte	Vorspann
SYNC	Synchronization byte	Synchronisation
HDB2	Header Definition Byte 2	Header Definitionsbyte 2
HDB1	Header Definition Byte 1	Header Definitionsbyte 1
DAB1	Destination Address Byte	Empfängeradresse
SAB1	Source Address Byte	Senderadresse
DB1	Data Byte 1	Datenbyte
CRC2	High byte of CRC-16	höherwertiges Byte der CRC16
CRC1	Low byte of CRC-16	niederwertiges Byte der CRC16

Die gesamte Paketlänge beträgt hier acht Byte ohne die optionalen Preamblebytes. Die Bytes sind mit ihrem LSB rechts positioniert (Bit7…Bit0).

2.1 Synchronization Byte - SYNC

Das Byte SYNC ist vordefiniert und kennzeichnet den Start eines jeden Datenpakets.

	Bit
	7	6	5	4	3	2	1	0
Binär	0	1	0	1	0	1	0	0

Dies entspricht 0x54 in der Hexadezimalen Schreibweise und 84 als Dezimalzahl.

2.2 Header Definition Bytes (HDB2 und HDB1)

Dem Byte SYNC folgen die beiden Header Definition Bytes HDB2 und HDB1, die die Telegrammstruktur festlegen.

	Bit
	7	6	5	4	3	2	1	0
HDB2	DAB		SAB		PFB		ACK
HDB1	CMD	EDM			NDB

Die enthaltenen Bits haben die folgende Bedeutung:

Name	Bezeichnung (original)	Bezeichnung (deutsch)
DAB	Number of Destination Address Bytes	Anzahl Bytes für Empfängeradresse
SAB	Number of Source Address Bytes	Anzahl Bytes für Senderadresse
PFB	Number of Protocol specific Flag Bytes	Anzahl Bytes für protokollspezifische Flags
ACK	ACK/NAK bits	ACK/NAK Bits
CMD	CoMmanD mode bit	Kommandomodebit
EDM	Error Detection Method	Fehlerdetektionsmethode
NDB	Number of Data Bytes	Anzahl der Datenbytes

Für die Bits im Header Definition Byte HDB2 gelten die folgenden Vereinbarungen:

DAB	Definition
0 0	Empfängeradresse 0 Byte
0 1	Empfängeradresse 1 Byte
1 0	Empfängeradresse 2 Byte
1 1	Empfängeradresse 3 Byte

SAB	Definition
0 0	Senderadresse 0 Byte
0 1	Senderadresse 1 Byte
1 0	Senderadresse 2 Byte
1 1	Senderadresse 3 Byte

PFB	Definition
0 0	Protokollspez. Flags 0 Byte
0 1	Protokollspez. Flags 1 Byte
1 0	Protokollspez. Flags 2 Byte
1 1	Protokollspez. Flags 3 Byte

Diese max. drei Flagbytes sind vorerst nur reserviert, aber noch nicht definiert. Sie sind für spätere Ereweiterungen des S.N.A.P. Protokoll vorgesehen.

In zukünftigen S.N.A.P. Protokollversionen können diese Bytes definiert werden und sollten vorerst auch nicht benutzt werden. Die folgende Nutzung dieser Bytes ist vorstellbar: ferngesteuerter Reset von Netzwerkknoten, ferngesteuertes Programmupdate bzw. Konfiguration, erweiterter Kommandomode, Telegrammzähler, Zeitstempel u.v.a.m.

ACK	Definition
0 0	kein Acknowledge
0 1	Sender fordert Acknowledge
1 0	Empfänger sendet ACK zurück
1 1	Empfänger sendet NAK zurück

Für die Bits im Header Definition Byte HDB1 gelten die folgenden Vereinbarungen:

CMD	Definition
0	kein Kommandomode
1	Kommandomode (DB1 enthält Kommando)

Ein Netzwerkknoten im Kommandomode bietet mehr Flexibilität, indem er auch dann reagiert, wenn er als Empfänger das Telegramm eigentlich nicht bedienen kann. Ist das Command Bit gesetzt (CMD=1), dann enthält das Datenbyte DB1 ein Kommando. Hiermit sind 256 unterschiedliche Kommandos möglich.

EDM	Definition
0 0 0	keine Fehlerdetektion
0 0 1	dreimalige Wiederholung
0 1 0	8-Bit Checksumme
0 1 1	8-Bit CRC-CCITT
1 0 0	16-Bit CRC-CCITT
1 0 1	32-Bit CRC-CCITT
1 1 0	Fehlerkorrektur
1 1 1	spez. Fehlerdetektion

NDB	Definition
0 0 0 0	0 Byte
0 0 0 1	1 Byte
0 0 1 0	2 Byte
0 0 1 1	3 Byte
0 1 0 0	4 Byte
0 1 0 1	5 Byte
0 1 1 0	6 Byte
0 1 1 1	7 Byte
1 0 0 0	8 Byte
1 0 0 1	16 Byte
1 0 1 0	32 Byte
1 0 1 1	64 Byte
1 1 0 0	128 Byte
1 1 0 1	256 Byte
1 1 1 0	512 Byte
1 1 1 1	spez. Anzahl

Zum Anfang

Kommentare

# Stefan meinte am 19. August 2007, 18:40 dazu:

Wir arbeiten seit Jahren erfolgreich mit diesem Protokoll. Leider ist die snap.dll für Windows-Anwendungen auf PC?s fehlerhaft. Es kommt bei bestimmten Bitmustern nachweislich zu fehlenden oder falschen Antworten vom PC. Zwischen Hardwaregeräten läuft das Protokoll einwandfrei. Allerdings passiert seit 2002 weder an der Homepage von HTH etwas, noch wird die benötigte dll überwarbeitet. Warum, weiß kein Mensch, schade eigentlich. Das Projekt ist wirklich gut. Auf diesbezügliche Anfragen gibt es jedoch keine Rückantwort.

kreatives-chaos.com

Themen: