-         

+ Antworten
Ergebnis 1 bis 5 von 5

Thema: Protokoll für mehrere Schnittstellen. Suche Programm-Tester

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    30
    Beiträge
    795

    Protokoll für mehrere Schnittstellen. Suche Programm-Tester

    Anzeige

    SMARTPHONES & TABLETS-bis zu 77% RABATT-Kostenlose Lieferung-Aktuell | Cool | Unentbehrlich
    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.
    Gruß,
    Franz

  2. #2
    Super-Moderator Robotik Visionär Avatar von PicNick
    Registriert seit
    23.11.2004
    Ort
    Wien
    Beiträge
    6.835
    Schau mal da (und folgende), da haben wir uns schon ein paar Gedanken gemacht und tw. auch realisiert.
    http://www.roboternetz.de/wissen/ind..._Controller/PC

    Vielleicht magst du dich da einbringen ?
    mfg robert
    Wer glaubt zu wissen, muß wissen, er glaubt.

  3. #3
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    30
    Beiträge
    795
    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
    Gruß,
    Franz

  4. #4
    Erfahrener Benutzer Fleißiges Mitglied
    Registriert seit
    05.10.2005
    Ort
    Zürich
    Beiträge
    117
    Hört sich super an. Äh wie komme ich an die Source um das zu testen?

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.01.2005
    Ort
    Bayern
    Alter
    30
    Beiträge
    795
    Hallo,

    Schreib mir deine email per "Persönliche Nachricht"
    Gruß,
    Franz

+ Antworten

Berechtigungen

  • Neue Themen erstellen: Ja
  • Themen beantworten: Ja
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •