Gepuffertes Senden mit RFM12

[guenter1604]

Hallo sauerbruch,

gerne nimmt man ja eine Variable als Zwischenspeicher für Rechenwerte. Hier sieht man was passiert, wenn da jemand dazwischenpfuscht, eigentlich sollte D ja immer 6 sein. Lass das mal im Simulator laufen und drück immer wieder mal den Interruptknopf.

$regfile = "m8def.dat"
$crystal = 16000000

Config Timer0 = Timer , Prescale = 1024
On Timer0 Int_timer0
Start Timer0
Enable Timer0
Enable Interrupts
Dim A As Byte
Dim B As Byte
Dim C As Byte
Dim D As Byte
Dim E As Byte

Dim Tempvar As Byte

A = 2
B = 2
C = 2
Do
    Tempvar = A + B
    Waitms 10
    D = Tempvar + C
    Print D
Loop

Int_timer0:
    Tempvar = A + 10
    E = Tempvar + 10
Return

[Sauerbruch]

Hi Günter,

jetzt ist der "Kronkorken" gefallen - tnx!
Bislang waren meine Programme insoweit einfach unkompliziert, dass es in der Tat cool war, wenn mehrere Subs, ISRs usw. an der gleichen Variablen herumgefeilt haben. Von daher hat sich mir der Sinn von Byval und Byref nicht erschlossen. Das Beispiel mit der Interrupt-Taste macht´s aber sehr deutlich klar.

Mit diesem Wissen bewaffnet werde ich sicherlich auch den RFM12-Code aus Deinem Link aufdröseln und verstehen können.

Besten Dank,

Daniel

[guenter1604]

Daniel,

was macht dein Bierfunk?

Günter

[Sauerbruch]

Moin Günter!

Tja, der Bierfunk (*lach )...

Ich dachte mir, ich mach mal einen kleinen Szenenwechsel und wende mich dem Empfänger zu. Wäre ja auch ganz schlau, denn sonst kann man ja nicht überprüfen, ob das mit dem Senden klappt. Dabei bin ich aber an einer Reihe von ungelösten Fragen gescheitert:

Ich übertrage per SPI ein &Hb000 um den FIFO auszulesen - und dann?? Woher weiß der Controller denn, dass er jetzt mit Lesen dran ist? Und wer sagt dem Controller, wann die übertragenen 2 Bytes fertig sind? Die Verbindung µC -> nSEL scheint mir ja nur in eine Richtung zu gehen.

Außerdem habe ich mir lange über dem Code von "Gerold-Electronic" den Kopf zerbrochen, zu dem Du mir ja den Link gepostet hattet. Besonders interessant fand ich die Geschichte mit dem Flag namens "warten", da mir irgendwo hier ganz in der Nähe die Lösung meines Problems zu sein schien:

Function Spi_write(byval Befehl As Word , Byval Warten As Byte) As Byte
   Local A As Byte
   Local B As Byte
   If Warten = 1 Then
      Reset Rfm12_cs
      Bitwait Rfm12_sdo , Set
   End If
   Reset Rfm12_cs
   B = High(befehl)
   A = Spimove(b)
   B = Low(befehl)
   A = Spimove(b)
   Set Rfm12_cs
   Spi_write = A
End Function

Obwohl ich mir den Code auf der Gerold-Homepage unzählige male durchgeesen habe, finde ich nirgendwo eine Zeile, die das Flag "warten" setzt oder löscht... es wird immer nur mittels byval an die Subs übergeben und abgefragt. Auch das hat mein Verständnis dieser Dinge nicht gerade gefördert.

An diesem Punkt fiel mir dann wieder ein, dass die Datenübertragung in meinem Projekt im ungepufferten FSK-Modus über die UART-Schnittstelle ja eigentlich ziemlich gut funktioniert - und das auch im praktischen Einsatz der Geräte seit über einem Jahr. Bidirektional wäre halt sicherer, aber weil ich auch eine Prüfsumme mit übertrage, kann ich fehlerhafte Bytes zumndestens schon mal empfängerseitig aussortieren.

Leider muss ich im Moment aus Zeitgründen wichtige von weniger wichtigen Aufgaben trennen, und die RFM12-Geschichte fällt insgesamt zur Zeit definitiv in Rubrik 2... Trotzdem wurmen mich solche ungelösten Fragen ja schon immer ziemlich, und irgenwann (spätestens Weihnachten) wird auch der Spieltrieb wieder auf seine Kosten kommen. Vielleicht habe ich bis dahin ja die eine oder andere Erkenntnis gewonnen, die mir weiterhilft

Gruß & co.,

Daniel

[guenter1604]

Hallo Daniel,

falls du Fragen zum Gerold-Code hat, frag den Verfasser: mich

Die Funktion kann mit 0 oder 1 bei warten gesetzt werden.
Bei 0 wird einfach der Command ans RFM12 geschickt.
Bei 1 wartet die Funktion auf eine Antwort des RFM12 und gibt diese Antwort zurück.

Günter

[Sauerbruch]

Hey - diese Chance kann ich mir nicht entgehen lassen

Die Funktion kann mit 0 oder 1 bei warten gesetzt werden.

Diese Bedeutung des Bytes "Warten" habe ich schon geahnt - aber nicht verstanden, wo im Programm der aktuelle Wert von "Warten" geändert wird. Ich sehe immer nur Zeilen im Sinne von "If warten = 1 then...". Wenn Du jetzt sagst, dass das innerhalb einer Funktion geschieht, müsste ich meine Frage vielleicht dahingehend umformulieren dass mir nicht klar ist, wie der Wert von "Warten" verändert wird. Aber das mag daran liegen, dass ich in der Kategorie "Funktion" noch nicht flüssig denken kann.

Bei 1 wartet die Funktion auf eine Antwort des RFM12 und gibt diese Antwort zurück.

Aber das ist wirklich nahe dran - wie entlockt die "Funktion" dem RFM12 das empfangene Byte? Bis zum SPI-Kommando &Hb000 komme ich noch mit, und dass am Schluss der FIFO-Speicher mit &Hca81 und &Hca83 gelöscht wird, ist auch okay. Aber was dazwischen passiert, da versagt meine Phantasie vollständig

Wie auch immer - das Video von dem Wheelie ist beeindruckend!!

[guenter1604]

Wenn ich eine Funktion aufrufe, kann ich ihr Werte mitgeben.

Declare Function Spi_write(byval Befehl As Word , Byval Warten As Byte) As Byte

Hier sage ich, daß ich 2 Werte mitgeben will, der erste ein Word, der zweite ein Byte.
Das "as Byte" am Schluß ist der Rückgabewert der Funktion.

  A = Spi_write(&H8239 , 0)

Übergibt also &H8239 an Spi_write und zwar an "Befehl" und 0 an "Warten"
Falls die Funktion was zurückgibt ist das nachher in "A" gespeichert
Den Kern des Empfängers bildet:

 For I = 1 To L
      Rxbuf(i) = Spi_write(&Hb000 , 1)
   Next

Es wird also &Hb000 gesendet und auf Antwort gewartet. Das Ergebnis ist dann im Array Rxbuf(i).

[Sauerbruch]

Hmmm, Puzzleteilchen finden langsam zusammen... Das mit den Funktionen ist mir jetzt klar - und auch, an welcher Stelle "Warten" auf 0 oder 1 gesetzt wird.

Eins verstehe ich aber noch nicht ganz:

Es gibt doch auch viele Befehle an den RFM12, auf die das Modul nicht mit irgendeinem Byte antwortet, z.B. Frequenzeinstellung, Baudrate, etc., etc. Weshalb werden die denn auch alle über die Funktion (!) Spi_write übertragen, wenn man nach dem Befehl gar keine Antwort erwartet? Ginge da denn nicht auch ganz banal der Bascom-Befehl Spiout?

Und das mit dem FIFO-Auslesen ist mir auch noch nicht so ganz klar - wahrscheinlich habe ich (trotz intensiver Bemühung der Bascom-Hilfe) den Befehl SPIMOVE noch nicht ganz kapiert... ich stell´s mir so vor:

X = Spimove(Y)

sendet Y an das Modul und weist X den Wert des Bytes zu, das das Mdul zurückschickt. Richtig??

Aber das Modul weiß doch erst nach dem zweiten gesendeten Byte (z.B. &Hb0 und &H00 für FIFO-read) , dass es etwas zurückgeben soll. Wie kann denn dann in den ersten beiden "Rück"-Bytes schon die gewünschte Information drin sein??

Sorry für meine Begriffsstutzigkeit, aber wenn ich´s jetzt nicht anpacke, werde ich´s nie verstehen...

[guenter1604]

Hallo Daniel,

ich wollte einfach alles mit einer Funktion erschlagen. Klar könnte man für den Konfigurationsbefehl eine extra Sub machen, da ja nichts zurückgegeben wird. Dann kann man sich auch das Wartenbyte sparen.

Wir warten doch extra bis das RFM12 meldet, daß was da ist. Dann sagen wir mit &Hb0, daß wir den FiFo-Puffer lesen wollen. Dann stellen wir mit &H00 einen leeren Eimer hin, der gefälligst gefüllt werden soll. Wir hohlen also immer nur 1 Byte mit der Funktion.

Günter

[Sauerbruch]

Okay - langsam verstehe ich es glaube ich...

Wenn ich folgendes schreibe:

X = Spimove (&Hb0)
Y = Spimove (&H00)

dann ist X irgendein Müll-Byte, und Y das Nutz-Byte aus dem FIFO???

Wenn der RFM12 sowieso erst nach &Hb0 merkt, dass er was zurückgeben soll, könnte man dann auch folgendes schreiben:

Spiout &Hb0, 1
Y = Spimove (&H00) ?

Und eine letzte Frage habe ich noch (zumindst bis zur nächsten ):

Wie ist das mit dem nSEL-Eingang: Wird der nicht automatisch auf 0 gezogen, wenn die SPI-Befehle ins Spiel kommen? Und wenn ja, weshalb machst Du es in Deinem Code dann mit extra Befehlen - kommt sich das denn nicht in die Quere? Und wie sähe das bei Verwendung von Soft-SPI aus?

Sorry für die vielen Fragezeichen - und vielen Dank für die bisherige Nachhilfe!!

Daniel