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.
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.