Protokoll für mehrere Schnittstellen. Suche Programm-Tester

**Kaiser-F** · 23.06.2006, 13:12

Hallo.

Ihr kennt sihcer das Problem... Wie übermittle ich klare und eindeutig zuweisbare Befehle über den UART, SPI, Parallel.... usw...

Die Lösung ist... Ein Protokoll zu schreiben.
Aber wie ist es dann mit mehreren Schnittstellen?

Und genau dieses Problem habe ich versucht zu lösen.

Daher benötige ich jetzt eure Hilfe, um es zu testen.

Zum Protokoll:
Das Datanpaket dieses Protokolls sieht so aus:

<STARTBYTE><IDENTIDYER><LENGTH><D0><D1><D2><D3><D4 ><D5><D6><D7><PRÜFSUMME>

Der Empfänger eines solchen Paketes muss mit <ACK> bestätigen,
Oder bei einem Übertragungsfehler mit <NAK> antworten.
Der Sender entscheidet dann, wie lange er wartet bis er den
Vorgang wiederholt, und wie oft er dies tut.

Zum Protokollmanagement:

Will man nun daten übermitteln, dann führt man eine Funktion aus:
SMART_send( DEVICE, ID, LENGTH, DATA0...7 );

Device ist dabei die Schnittstellte,
ID der Paketidentifizierer,
LENGTH die Anzahl der Datenbytes.

Das Management trägt nun diese Informationen in einen Freien Puffer ein.
Und setzt diesen auf den Status "Ready-To-Send".

Eine andere Funktion, welche bei jedem Programmdurchlauf ausgeführt wird:
SMART();
Untersucht jeden Puffer. Findet er einen, der RTS ist, dann wird dieser, wenn dessen Schnittstelle frei ist, gesendet.

Die Schnittstelle wird dabei auf "SENDE" gestzt.
Wurde gesendet, wird die schnittstelle auf "WAIT" gesetzt, und eine
wartezeit gesetzt.
Nun wird auf ein <ACK> gewartet.
Kommt ein <NAK> wird nach der NAK-WAIT-TIME neu gesendet.
kommt garnichts, wird neu Gesendet.
Ist der sendeversuch SENDTIMES mal fehrlgeschlagen, wird der Pufferihnalt verworfen und eine Errorfunktion ausgeführt, bei der die ID des paketes mitgeliefert wird. Der andwender kann hier dann etwas unternehmen lassen.

KOmmt ein <ACK> wird der Puffer und die Schnittstelle(DEVICE) wieder auf "FREI" gesetzt.

Empfang:

Wenn die Schnittstelle auf "FREE" ist und ein STARTBYTE empfangen wurde, wird ein Puffer geöffnet und auf "RECEIVING" gesetzt.
Ausserdem merkt sich die Schnittstelle die Puffernummer, und deklariert einen Zähler...
die nachfolgenden Daten können nun empfangen werden.
Wurden alle daten empfangen, wird die Prüfsumme berechnet und mit der mitgesendeten verglichen. Stimmen sie überein, so wird ein <ACK> gesendet, der Puffer auf "READY-TO-READ" gesetzt und die schnittstelle "FREI" gegeben.

In der SMART() werden auch die RTRs abgefragt.
Ist ein Puffer RTR, so wird er ausgelesen. Die werte werden in eine FUnktion übertragen, und der user kann diese Umsetztn.
Anschließend wird der Puffer auf "FREI" gesetzt.

Ich möchte das Protokoll jetzt nicht gleich hier rein stellen, sondern es dann gesondert vorstellen wenn es vollkommen ausgereift ist.

Es belegt bei 8 Puffer und 5 Schnittstellen etwa 105Bytes im RAM.

ALSO,
An EINER Schnittselle kann ENTWEDER empfangen ODER gesendet werden. Dass Datenpakete an EINER Schnittstelle gleichzeitig gesendet und empfangen werden, das geht nicht. (weil eben auf ACK oder NAK gewartet wird!

Die verschieenen Schnittstellen sind aber UNABHÄNGIG von einenader..

Also wenn Device 1 gerade sendet, können die anderen Devices machen was sie wollen....

Wenn jemand Zeit, Lust und Interesse hat, und ein paar Schnittstellen
gleichzeitig testen kann, dann melde dich bitte per PN.

**PicNick** · 23.06.2006, 14:25

Schau mal da (und folgende), da haben wir uns schon ein paar Gedanken gemacht und tw. auch realisiert.
https://www.roboternetz.de/wissen/in..._Controller/PC

Vielleicht magst du dich da einbringen ?

**Kaiser-F** · 24.06.2006, 10:00

Hallo,

Danke für den Hinweis.

Ich habe halt jetzt schon dieses Protokoll geschrieben, und es
Funktioniert bei mir auch schon perfekt. Ich Suche halt nur Leute,
Die es schnell einbinden, und testen... Ob es auch wirklich so einfach
einzubinden ist, wie es sollte. Es wird dann als open-source zur
Verfügung stehen.

Zum einbinden sind Folgende Schritte Notwendig:

#include <smart.h>
#include <smart.c>
SMART_time(); -->(im Timer-Interrupt. Frequenz dann bei den Wartezeiten ausgleichen)
SMART_receive( device, data ); -->(In den Empfangs-Interrup_routinen)
SMART_init(); -->(Einmalig ausführen, um Pufferwerte auf 0 zu setzten)
SMART(); -->(In der Hauptschleife)

Dann nur noch anpassen:

in der smart.h die gewünschten Wartezeiten eintragen, und wie oft
ein Senderversuch stattfinden soll. Auch wieviele Puffer bereitgestellt
werden sollen usw...

in der smart.c die gewünschten Aktionen eintragen.
Hier ist ein switch(id){} vorbereitet, in der mit case nur noch die
entsprechende id eingetragen wird, und schon kann man mit den Datenbytes was anstellen!

Auch die aktionen bei den bestimmten Errors kann man hier steuern.

Was man ändern darf, ist jeweils mit "!!! BENUTZERDEFINIERTER BEREICH !!!" und "!!! ENDE DES BENUTZERDEFINIERTER BEREICHS !!!" gekennzeichnet.

Schön ist halt, weil das Protokoll ähnlich aufgebaut ist wie das CAN-Protokoll