Hallo zusammen,
ich muss mich jetzt auch einmal melden... Gestern hab ich mich
nachmittags hingesetzt und die Bibliothek etwas erweitert.
Zunächste einmal habe ich die Sende- und Empfangs-Methoden etwas
modifiziert.
Beim empfangen von Strings muss man jetzt nicht mehr wissen wie lange
das Paket ist. Es können variable Paketlängen bis zu 240Byte übertragen
werden. Der Rückgabewert von rf12_rxdata() ist die Länge des Pakets.
Zusätzlich sind die Pakete noch mit einem CRC16 gesichert und wurden
bereits überprüft und nur richtige Pakete ausgegeben.
Dann ein großer Punkt ist das blockieren der Funktionen. In einem
eingebetteten (meist echtzeit) System sind solche Funktionen eigentlich
unerwünscht. Vorallem wenn einmal ein Paket nicht empfangen wird.
Deadlocks sind hier ja schon fast vorprogrammiert. (Dieses Urteil mase
ich mir jetzt einfach mal an.) Asynchrones programmieren (mit
Interrupts) ist nie verkehrt...
Deshalb hab ich die Bib noch etwas erweitert. Mit den defines:
1
#define RF12_UseBlockingCalls //NEVER USE BOTH
2
#define RF12_UseNoneBlockingCalls //NEVER USE BOTH
kann man die blockierenden Methoden durch nicht blockierend ersetzten.
Das Senden/Empfangen wird dann im Hintergrund abgearbeitet. Allerdings
braucht man dazu einen Interrupt Pin. Der Prozessor blockiert jetzt nur
noch kurz wenn man Daten an das Modul überträgt, oder anders herum.
// check whether the package is already transmitted
11
unsignedcharrf12_txfinished(void);
12
13
// stop all Rx and Tx operations
14
voidrf12_allstop(void);
Zugegeben ich war irgendwie unfähig einen Hardware SPI zu verwenden. Da
hat das Empfangen der Daten irgendwie nie geklappt. Ka Wieso. Aber wenn
das wer zum laufen bringt, dann kann man das blockieren noch weiter
reduzieren G
Vom Prinzip her reicht mir das aber erstmal.
Probiert es einfach mal aus. Ich hab 2 Sample Projekte mit dem
Kontrollerlab angelegt. Die Bib selber liegt in dem Lbr Verzeichnis und
sind in die Projekt Verzeichnise gelinkt. Wenn wer Windoof verwendet
dann muss er sie ggf in die passenden Verzeichnise kopieren.
Auch interessant ist vielleicht meine
Methode, die ist ähnlich nicht blockierend... Man schickt einen
beliebigen String über den UART ab und während der String gesendet wird
kann man schon etwas anderes tun (mit winzigen Unterbrechungen).
Guggs euch an und sag mir was ihr davon haltet, oder wie scheiß ich bin
G
Sers
Jürgen
Hier noch ein kleines Bugfix. schäm
Es gab kleine Probleme beim empfangen wenn die CRC Checksumme nicht
gestimmt hat.
Ich hab bei der Gelegenheit auch gleich ne Versionsnummer eingeführt,
falls andere die Lbr noch weiter entwickeln wollen.
2.0.1 ist der momentane Stand.
So far
Jürgen
Hallo,
Ich hatte ja vorhin das Problem, dass ich von 8 gesendeten Bytes nur die
ersten 2 empfangen konnte!
Ich verwende den FFIT und habe diesen an Int0 meines Mega8
angeschlossen. Immer, wenn ein Interrupt auftritt, führe ich dann die
RX-Routine aus! Nun bin ich draufgekommen, dass, wenn ich eine Baudrate
unter 2400kbps verwende, am FFIT-Pin mehrere Impulse hintereinander
kommen und daher die RX-Routine vom Int0 unterbrochen und nochmals
gestartet wird. Und siehe da, die Daten kommen vollständig an!
Also stimmt irgenetwas mit meiner Empfangsroutine nicht! Aber was könnte
da sein??
Vielen Dank!
Andy
Andreas Posch wrote:
> Ich verwende den FFIT und habe diesen an Int0 meines Mega8> angeschlossen. Immer, wenn ein Interrupt auftritt, führe ich dann die> RX-Routine aus! Nun bin ich draufgekommen, dass, wenn ich eine Baudrate> unter 2400kbps verwende, am FFIT-Pin mehrere Impulse hintereinander> kommen und daher die RX-Routine vom Int0 unterbrochen und nochmals> gestartet wird.
Wie hast du das genau gemacht ? Normalerweise wird ein Interrupt nicht
durch einen anderen Interrupt unterbrochen.
Das ganze erinnert mich an meine Versuche das ganze Interruptgesteuert
zu machen: Es kam nur jedes 2. Byte an.
Auch wenn ich diese Art der Programmierung als schrecklich betrachte
(soviel Code in der Interruptroutine), müsste es aber trotzdem
funktionieren. Ich kenne mich mit Bascom überhaupt nicht aus, daher weiß
ich nicht, ob während einer Interruptroutine die Interrupts auch aus
bleiben, oder ob bascom die Interrupts wieder aktiviert. Letzeres würde
den Fehler erklären.
Eine bessere Lösung wäre: Einen Empfangspuffer einrichten, in den im
Interrupt nur die empfangenen Daten geschrieben werden und ein
Bytezähler erhöht wird. Dann noch eine Variable, die anzeigt ob der
Empfang vollständig ist.
Ich würde vorschlagen, pro Interrupt jeweils nur ein Byte zu empfangen
und für das nächste empfangene Byte wieder einen neuen Interrupt
generieren zu lassen, ansonsten wird zwar der Start des Empfangs per
Interrupt angestoßen aber der eigentliche Empfang des Pakets läuft dann
wieder pollend.
Danke einaml für deine Antwort, ich werd es mal so probieren.
Aber in meiner Empfangsroutine hab ich ja schon so eine Art Buffer. Ich
speichere zunächst alles in der Variable Rfdata und wenn der Empfang
abgeschlossen ist, werte ich die Daten aus. Nur ist ja das Problem, dass
nur die ersten 2 Bytes ankommen. Nur wenn ich während des Empfangs
nocheinmal sende, kommen weitere Daten an!
Irgendwelche Ideen??
Ich weiß nicht mehr weiter.
Int2_int:
Disable Int2
Enable Interrupts
.......
......
enable int2
return
int musst du ausschalten und enablen die internen int(wurden
ausgeschaltet), dann kannste die daten weiter empfangen.
Andreas,
wie die anderen schon zum Teil bemerkt haben, ist Deine
Interrupt-Routine nicht so ganz nach den Regeln der Kunst :-)))
Du führst nach dem Einsprung in die Int0-Routine Print "....." aus. Das
kann eventuell (wenn das Senden nicht interruptgesteuert ist) viel zu
lange dauern. In dieser Zeit läuft Dir eventuell der Empfangs-FIFO des
Transceivers über und Du verlierst Zeichen.
Im Übrigen wird eigentlich der Empfang jedes einzelnen Bytes durch einen
Interrupt signalisiert. Du solltest also nicht nach dem ersten Interrupt
versuchen, mehrere Zeichen zu lesen, sondern nur jeweils eins (wie
Benedikt schon schrieb).
Gruß,
Jörg.
Mann, bin ich blöd...
ich hab die ganze Zeit am nIRQ ausgang gehangen und hab mich gewundert
warum das nicht geht ^____^;
mit FFIT gehts natürlich. Und zwar genau so wie Benedikt das schon
irgendwann mal beschrieben hatte...
also:
FFIT an INT1
1
...
2
3
Config Int1 = Rising
4
On Int1 Ffit_handler
5
Enable Int1
6
7
...
8
9
Ffit_handler:
10
11
' Byte lesen
12
Temp = Rf12_trans(&Hb000)
13
Rfdata(count) = Temp
14
15
' Momentan einfach feste länge lesen, STX ETX oder sowas ist aber
16
' hier auch kein problem...
17
If Count >= Maxchar Then
18
19
' Wenn 32 Bytes gelesen wurden, Text ausgeben
20
For Count = 1 To Maxchar
21
Print Chr(rfdata(count));
22
Next Count
23
24
' FIFO SYNC Erkennung wieder scharf machen
25
Temp = Rf12_trans(&Hca81)
26
Temp = Rf12_trans(&Hca83)
27
28
' und von vorne zählen
29
Count = 1
30
31
Else
32
' ansonsten nur zähler erhöhen
33
Incr Count
34
End If
35
36
37
Return
38
39
....
Ich programmier mir jetzt mal die STX ETX Erkennung mit einem timeout,
dann seh ich weiter...
@Wigbert: ich hab jetzt mal gerade beim empfänger die abfrage auf
spi_sdo=1 geändert... funktioniert auch... wenn er beim sender dann ne
sekunde aufhört zu senden, dann wird das wohl richtig sein...
Hallo Marvin,
ich habe Deinen Soft SPI Code
und deine ready Methode in den Code von Fossy eingebaut.
wenn ich spi_sdo auf 0 lasse.
pendelt das programm nach dem Durchlauf zwischen
>While Spi_sdo = 0
>Wend
wenn es klappt habe ich mein Code beigelegt.
Irgendetwas stimmt bei mir dann nicht
Wigbert
Nachtrag:
Pinb.4 ist ja wohl als Eingang declariert.
Kann mir mal jemand erklären wann der Spi_sdo Port des RFM12 ein H
Pegel hat.Wenn bei Empfang Daten empfangen werden, oder wann noch?
>Spi_sdo Alias Pinb.4 ' MISO-PIN
Dank Euch
Wigbert
@Jörg:
Ich habe nun meine Interrupt-Routine so abgeändert, dass ich dort nur
eine Bit-Variable setze und dann den Code im Hauptprogramm ausführe.
Aber es geht trotzdem nicht!
Was mir aufgefallen ist: Wenn ich die Baud-Rate auf 1200 stelle, kommt
für jedes Byte ein extra Interrupt; und dann funktioniert die
Übertragung auch! Aber wenn ich die Baud-Rate auf 19200 stelle, kommt
nur mehr ein Interrupt für alle Bytes! Wahrscheinlich kommen die
einzelnen Interrupts dann schon zu schnell, dass nur mehr einer erkannt
wird. Und bei 19200 funktionierts nicht! Ich würde gern wissen, was da
falsch läuft!
THX Andy
Andreas,
Du solltest in der Interrupt-Routine sofort das Byte aus dem FIFO lesen.
Bei 19200 Baud sollte nur ca. alle 500us ein Zeichen ankommen, das
sollte eigentlich immer reichen, um das Zeichen schnell genug abzuholen.
Hängt aber alles stark von Deiner Programmstruktur ab.
Schreib doch mal einfach eine Senderoutine, in der Du jede Sekunde ein
Paket mit z.B. 10 Zeichen sendest, vielleicht die Zahlen 1,2,...,10. Im
Empfangsprogramm liest Du in der Interrupt-Routine die empfangenen
Zeichen in einen Puffer, wie beschrieben jedes einzeln. Wenn Du eine 10
empfangen hast (oder zehn Zeichen), dann setzt Du ein Flag. Im
Hauptprogramm wartest Du auf das Flag und schreibst dann den Inhalt des
Puffers auf die RS232. So kommen sich die beiden Dinge nicht ins Gehege,
da ja das Senden auf der RS232 in die Sendepause des Senders fällt.
In der Interruptroutine aber nur die wirklich notwendigen Dinge machen.
War doch Bascom, oder? Sollte aber auf jeden Fall schnell genug sein.
Gruß,
Jörg.
Ich hab mich noch nicht komplett mit den Modulen beschäftingt, da meine
noch nicht da sind aber so wie ich das verstanden habe haben die Module
einen Fifo. Und für Jedes ankommende Byte wird ein Interrupt erzeugt.
Dann würde ich, solange die Main nicht so lang ist, dass der Fifo
überlaufen kann in der maximalen zeit bis zur Bearbeitung, in jedem
Interrupt eine Variable hochzählen, die anzeigt, wieviele Bytes noch
gelesen werden müssen. Wenn du dann ein Byte ausliest, ziehst du wieder
eins von dieser Variable ab. Wenn sie 0 ist brauchst du natürlich auch
nichts zu lesen.
Hauke Radtki wrote:
> aber so wie ich das verstanden habe haben die Module einen Fifo.
Ja, der ist aber nur 16 Bit (also 2 Byte) lang. Man muß also jedes
empfangene Byte aus dem FIFO holen, bevor das nächste komplett ist, sost
läuft der FIFO über.
> Und für Jedes ankommende Byte wird ein Interrupt erzeugt.
Nein, ein Interrupt wird immer dann erzeugt, wenn der FIFO den bei der
Initialisierung eingestellten Füllstand erreicht hat. Wird er dann nicht
geleert, gibt es den nächsten Interrupt erst wieder wenn er übergelaufen
ist, was dann bedeutet, daß man Daten verloren hat.
Hallo,
Ich lese nun jedes Byte einzeln ein und siehe da: Es funktioniert bei
jeder Baud-Rate! An dieser Stelle mal danke an alle, die mir geholfen
haben!
Einen Fehler hab ich aber noch! Beim ersten Senden nach dem Einschalten
funktionerts nicht. Es wird nur bei ersten Byte ein Interrupt ausgelöst.
Bei den folgenden nicht! Sende ich dann nocheinmal haut es hin!
Was könnte da noch sein? Hab schon einiges durchprobiert - komm aber
nicht dahinter!
THX
Andy
Hallo!
Möchte das RFM12 an einem PIC 16F876 betreiben. Auf was muss ich achten?
Hat das schon jemand mit einem PIC versucht?
Danke für eure Hilfe.
mfg
Martin
Hallo!
Habe mittlerweile eine Funkstrecke zwischen zwei RFM12, die jeweils an
einem PIC16F876 hängen, aufgebaut.
Habe den Code von Benedikt auf den PIC umgelegt. Beide Module können
senden! (Mittels TV Karte getestet) Leider kann keines der beiden
empfangen.
Die Module bleiben in RX_Data in rfm12_ready hängen.
Habe mittlerweile anstatt nur auf SDO zu warten, den ganzen Status
ausgelesen.
Habe dann auch noch den Sender aus und eingeschalten.
Folgendes Ergebnis:
Der einzige Unterschied zwischen eingeschaltenem und ausgeschaltenem
Sender ist, dass sich das 8 Bit (RSSI) von high auf low ändert.
Das ffit und das ffem (Fifo Empty) änder sich nicht.
Bitte um Hilfe.
Danke schon im Voraus!
mfg
Martin
Stelle bei meiner TV-Karte die Frequenz ein und hänge die Antenne an den
Antenneingang. Wenn der Sender dann Daten sendet, kann man dies anhand
der Rauschimpulse im Ton genau hören.
mfg
Martin
Junge Junge, lebst mit deiner TV Karte aber ganz schön gefährlich
Jürgen
PS:
Keiner was zu sagen zu meiner Erweiterung der Lib (siehe oben)? Hat die
überhaupt schon mal wer getestet?!
@ Jürgen
Sobald ich meine Hardware neu aufgebaut habe werde ich deine Lib mal
testen.
Der erste Versuch mit meiner Hardware ist gescheitert , der von mir
eingesetzte FTDI FT232R ist für meine Anwendung zu "langsam" (Latenz).
Wie weit bist Du denn mit der Hardware SPI gekommen?
Hallo,
Mein Bascom-Code funktioniert doch noch nicht so einwandfrei, wie ich
mir das gedacht hatte. Beide, der Empfänger und der Sender, stürzen in
regelmäßigen Abständen ab.
Der Empfänger empfängt dann einfach nichts mehr. Zumindest kommen keine
Impulse mehr aus dem FFIT-Pin. Ich habe aber auch schon mal beobachtet,
dass dann dauernd Impulse am Pin anliegen und der Empfänger ebenfalls
nicht mehr reagiert. Ist aber erst 1-2mal vorgekommen.
Und der Sender resetet sich einfach.
Beide Abstürze kommen ziemlich gleichzeitig, d.h. in gleichen Abständen
vor.
Hat irgendwer eine Idee, was da sein könnte? Vielleicht falsche
Einstellungen bei hw- und swstack? Hab mich damit schon gespielt - kommt
aber nix brauchbares raus!
Vielleicht kann mir irgendwer weiterhelfen!
THX Andy
@Claude
naja also das Senden ging einwandfrei. (Getriggert über nIRQ) aber
empfangen habe ich immer nur mist bzw: 0xFF. Ka wieso.
Momentan geht aber die Uni wieder vor und ich habe momentan keinen
wirklichen Verwendungszweck für die Teile, deshalb lass ich es etwas
schleifen...
Eigentlich wollte ich einen ultra leicht empfänger für Flugmodelle damit
bauen, aaaaber die Reichweite (die im Datenblatt mit 150m angegeben
wurde) ist mir dann doch eteas zu gering... Auch wenn ich schon eine
Platine anfertigen hab lassen, die mit ATmega48 und Pinout (also Prog
Anschluss + 4 Servos) nur 19x19mm hat....
Jürgen
> Is sowieso ein uraltes Ding und wird ohnehin nicht mehr verwendet.> Reicht aber um festzustellen, ob der Sender funktioniert.
... dazu reicht auch ein 16..17cm langes Stück Draht am Sender und eine
Zimmerantenne oder ein weiteres Drahtstück an der TV-Karte. Damit kannst
Du den Sender testen, ohne gleich die Karte aufs Spiel zu setzen.
Ja gut so weit war ich auch schon. Nur das ich eben den SPI mit voller
Geschwindigkeit laufen hab lassen. Nur ging dann das Empfangen nicht
mehr. Und ich hatte das warten dann über den nIRQ bin gelöst. Wieso hast
du eigentlich meine Async routinen weg gemacht?! Ist doch wesentlich
besser wenn der CPU nicht blockiert oder?!
Ahm als CRC Start Polynom hab ich jetzt einfach die 0x0000 genommen. Ich
denke wenn man da ein anderes nimmt kann man Fehler besser dedektieren,
das muss ich mal nachlesen...
Jürgen
Jürgen: Eine Funkfernsteuerung für Modellflieger würde ich lieber auf 27
MHz machen (das ist die "Spielzeugfrequenz"...)
Aber dafür gibt es glaube ich keine Fertigmodule. Gibt es überhaupt
TX/RX Module für Modellfunk? Also nur rein zur Signalübertragung, keine
Aufbereitung etc.
Naja also die Flugfrequenzen sind 35 bzw 40Mhz. Aber gut da is die
Reichweite halt mal >500m. Deswegen hab ichs auch sein lassen. Mich hat
halt nur das Gewicht und die Größe interessiert und das ich dann am
Modell alles selber gemacht hätte.... Aber gut ich hab eh ned so viel
Zeit G
Hallo,
Also habe nun das Senden und Empfangen von Daten getestet, funktionieren
mit einen Mega8, Mega88 und Mega32. Mal sehen was passiert wenn man den
SPI-Bus höher taktet. Ich werde auch bald eine Interruptroutine
benutzen, ist besser als Polling, habe auch noch irgendwo schon einen
fertigen Ringbuffer für Senden und Empfangen herumliegen.
Gruss
Ulrich
Hallo@Marius Schmidt
Natürlich gibt es nur Sendemodule für 27 und 35MHZ Band z.B. hatte ich
mal eins von Graupner habe dann mit einen Mega88 das RC SummenSignal
erzeugt und auf den Sender gegeben. Den SourceCode dafür habe ich sogar
auf meiner HP. Für den Empfang baue ich mir immer die Module um.
Gruss
Ulrich
Moins,
bin auch gerade am Spielen mit den RFM12. Eigentlich wollte ich damit
eine RS232-Verbindung verlängern, muß nun aber in diesem Thread
betroffen zur Kenntnis nehmen, daß die Module nicht gleichzeitig senden
und empfangen können.
Gibt es noch Hoffnung (hab ich vielleicht was falsch verstanden)?
Die Funkverbindung soll transparent für die jeweilige Applikation sein,
d.h. wenn die Anwendung eine full-duplex-Verbindung erwartet, muß die
Funkstrecke das realisieren.
Hat hier jemand eine gute Idee, ob sowas mit den RFM12 prinzipiell
überhaupt zu realisieren wäre? Wie schnell kann so ein RFM12 zwischen
den Betriebsarten Senden und Empfangen umschalten?
Würden sich zwei Funkstrecken mit RFM01 und RFM02 gegenseitig ins Gehege
kommen?
Fragen über Fragen...
Gruß
Horst
Ulrich: Ich hab's mir noch nicht angeschaut, aber warum überträgt man
mit diesen RC Summensignal? Kann man nicht rein digital bitweise
übertragen und das dann wieder beim Empfänger umsetzen?
@ Horst Meier
Du hast 2 Möglichkeiten:
1) Du sagst das das eine 38k4 oder 56k6 Verbindung ist und läßt die
Funkstrecke selbst mit 115k2 laufen (also mindestens doppelt so schnell
wie die Kabel Verbindung).
Oder
2) Du nimmer 2 Einheite pro Seite und gibt ihnen nicht gegenseitig
stöhrende Sende/Empfangs Freq. Also z.B. das eine Paar 500kHz mehr als
dem anderen.
Hmm oder
3) Du arbeitest mit Handschaking und/oder mit einem Buffer der groß
genug ist.
Jürgen
Hallo Leute,
Ich lese mit meinen Bascomcode über ein Interrupt meine RXD-Strings
ein.Soweit so gut.Kann also mit ein Terminalprogramm mein Text
von rf12 zu rf12 senden.
Jetzt soll jeder rf12 mit Empfang starten,nach übertragen der Strings
zum Controller (m8) auf Senden umschalten. Benötigt der rf12 zum
umschalten Empfang-Senden ein Reset,oder wie macht Ihr das generell.
Wigbert
Hallo Avr Nix,
das Problem ist ,glaub ich das bei Empfang die Schleife nicht
beendet wird.Er wartet das ein Pin H wird.Wollte mal wissen ob das
warten
zeitlich begrenzt wird, oder Reset oder ?
Wigbert
Wenn ein Reset geben soll - vielleicht den Watchdog einschalten wird der
nicht immerhalb von max 2sek zurückgesetzt wird ein REset gemacht.
Oder die lässt einen Zähler hochlaufen bis er einen Wert hat und
springst dann raus.
Ich hoffe ich habe dich richtig verstanden.
hi
bin auch gerade an den RFM12 Modulen. Habe das gleiche Problem wie schon
andere beschrieben haben. Senden scheint zu funktionieren, nur empfangen
nicht. Auch bei mir bleibt die Empfängerseite in der Funktion
rf12_ready() hängen.
Den Sender konnte ich heute ein wenig in der Uni testen (OSZI). Der
Sender schaltet den CLK auf 10Mhz um und wenn ich die Messspitze an die
Antenne halte sieht es wie im Bild zu sehen aus.
Wie geht ihr bei testen vor?
Ich benutze eine TV Karte mit 17cm Draht als Antenne. Das Signal kann
man wunderbar auf Kanal S37 (+/- Finetuning) Empfangen und die Daten
hört man im
Tonkanal. Was Du da mit dem Oszi beobachtest ist wahrscheinlich ein
einschwingen der HF Sendestufe des Moduls, schaut bei mir genauso aus.
Mit einem normalen Oszi ( alles kleiner 5GSPs ;-) ) wirst du nichts am
Antennenausgang des Moduls sehen können.
Das die Empfängerseite im rf_ready() hängen bleibt ist normal solange
keine Daten eintreffen. Gibt hier im Thread schon ein paar Lösungen
dafür.
Hallo Benedikt, hallo alle
ich bin erst kurz mit den RFM01 und RFM02 beschäftigt und weiß nicht, wo
der Fehler in meiner Konfiguration ist. Wie ich hier gelesen habe, ist
in den Dokumentationen und Beispielprogrammen von Pollin diverse Fehler.
Da ich C nicht kann und in Assembler einen PIC programmiere, ist es mir
noch nicht gelungen eine Verbindung zwischen den Modulen aufzubauen.
Deshalb wäre es toll, wenn jemand die Minimalst-Konfiguration eines
laufenden "Duos" aus RFM01 und RFM02 posten würde, nicht als C-Code,
sondern nur die Adressen und Hexwerte für Sender und Empfänger.
Vielen Dank
Kalli
so klingt es wenn ich meine TV-karte auf 433,93MHz stelle. Viel rauschen
und im Sekundentakt ein klicken oder piepen. Mein Sender sendet also.
Mit dem empfang bin ich auch noch nicht weiter. Ich wollte es eigentlich
vermeiden noch extra die Interruptleitung zu verwenden. Habt ihr noch
andere änderungen vorgenommen? Also ich habe jetzt
- rf12.c aus dem erten beitrag
- in der rf12_ready() nop's eingefügt und den timeout von JBecker
- in der main() die Warteschleife verkürzt;
Bringt es was, wenn ich die Baudrate verkleiner?
Hat der Kontroller eingentlich ein Register das ich nur auslesen kann,
Revisionsnummer oder so? Vieleicht ist ja mein SDO im A**.
Hallo alle
hier noch einmal meine Bitte, die Minimalst-Konfiguration eines
laufenden "Duos" aus RFM01 und RFM02 zu posten, nicht als C-Code,
sondern nur die Adressen der benötigten Register und Hexwerte für Sender
und Empfänger.
Ich habe es jetzt geschafft, das Statusregister auszulesen. Es wechselt
zwischen 0x0F30 und 0x0FC0, Daten im FIFO alles 0. Hilft das bei der
Fehlersuche?
Danke und ein schönes Wochenende
Kalli
Hallo Leute,
habe Marvin seine Interrupt-Empfangscode (Ffit an Int1)
eingebaut. Emfange aber nur das 1.Zeichen und noch irgendeins.
Hardwaremässig sollte dann alles ok sein.
Versaut mir das Print das Zeitfenster?
und wo bleibt rf12_ready
Wigbert
Hallo Leute,
selbstverständlich funktioniert Marvin sein Interrupt-Code
Man muss ihn nur richtig einbauen. schäm.
Enable Interrupts 'Interrupts global zulassen
sollte nicht fehlen.
Wigbert
Hallo alle
Ich kriege die Verbindung der Module einfach nicht hin.
Deshalb stelle stelle hier mal meine Sende und Empangsroutine ein, mit
der Bitte mal rüber zu sehen, was an der Konfiguration nicht passt.
Original-Listings im Anhang
Empfänger:
nSEL=1 ; Grundzustand der Selekt-Leitung
SCK=0 ; Grundzustand der Clock -Leitung
nSEL=0 ; Modul selektieren
Initialisieren:
C2E0 CLK: 10MHz
C42B Data Filter: internal
CE88 FIFO mode
C6F7 AFC settings: autotuning: -10kHz...+7,5kHz
E000 disable wakeuptimer
CC00 disable low duty cycle
A640 set freqenz
C823 baudrate
898A Bandbreite
C0C1 RX on
CE89 FIFO
CE8B enable FIFO
Statusregister und FIFO auslesen:
SEL=1 ; Grundzustand der Selekt-Leitung
SDI=0 ; Datenleitung auf Lo
nSEL=0 ; Modul selektieren
16 mal SCK auf High und wieder auf Lo setzen für Statusregister aus SDO
lesen
8 mal SCK auf High und wieder auf Lo setzen für FIFO aus SDO lesen
Sender:
nSEL=1 ; Grundzustand der Selekt-Leitung
SCK=0 ; Grundzustand der Clock -Leitung
nSEL=0 ; Modul selektieren
Initialisieren an SDI:
CC00 ? was macht das?
8B61 Config. Setting commands (CLK - Pin - Frequenz, ...)
A640 Semdefrequenz
D040 ????
C823 Baudrate
C220 enable TX, ...
C038 Power - Amp., Disable CLK-Pin, ...
4 mal 0xAA (preamble) an FSK
Frame 0x2DD4 an FSK
Daten zum Senden an FSK schicken
Beim übertragen der Daten an SDI habe ich eine Warteschleife eingebaut,
beim übertragen an FSK frage ich den IRQ - Pin ab.
Hallo,
Ich hab da wieder mal eine Frage! Und zwar will ich das RFM12 als Sender
und Empfänger nutzen. Und zwar soll das Modul etwas senden und dann in
den Empfangsmodus wechseln. Aber wann und wie schalte ich auf Empfänger
um? Ich habe einmal probiert, gleich nach dem Senden mit:
Temp = Rf12_trans(&H82c8)
Temp = Rf12_trans(&Hca81)
Temp = Rf12_trans(&Hca83)
auf Empfang zu schalten, aber das hat nicht so recht funktioniert!
Wie stelle ich das richtig an??
THX... Andy
Hab jetzt auch zwei RFM12 + ATmega8 am laufen. Software ist die von
Jürgen Eckert.
Könnten alle, die an der Firmware weiterentwickeln bitte jeweils die
aktuellste Version hier verlinken:
http://www.mikrocontroller.net/articles/AVR_RMF12#Software
Dann muss man nicht immer den ganzen Thread durchsuchen.
@Ulrich Radig,
in rf12_init()
verstehe ich was nicht.
Was bringt
SPSR &= ~(0<<SPI2X); ???
Denn ~(0<<SPI2X) == ~(0) == 0xFF, und var & 0xFF ändert nichts.
Gruß
Werner
Hallo zusammen,
Also ich hab ja jetzt alles zusammen. Das Pollin Evaluations-Board und
den RFM12. Die hier herunterladbaren Bascom-Beispiele laufen nicht
darauf. (So wird nirgends PortD.4 eingeschaltet (und das RFM12 bekommt
so auch keinen "Saft")
Bevor ich jetzt das Rad komplett neu erfinde:
Hat jemand einen laufenden Code für das Evaluations-Board?
(Mir reicht ja schon ein einfaches Beispiel, das nur sendet.)
Pollin hat da ja leider gar nix parat...
Wolfgang
Hallo Wolfgang,
der Code von Bastelbär(blätter mal hoch)funktioniert.
Wobei bei dem Pollinboard gibt es mit den Optokoppler probleme.
Ich hab Ihn durch eine Brücke ersetzt.Würde mal Deine Erfahrung
dazu gerne lesen.
http://www.roboternetz.de/phpBB2/viewtopic.php?t=30824
Wigbert
Hallo,
Mit dem Optokoppler hatte ich die gleichen Probleme. Spannung am RM12
Module brach zusammen. Habe dann den Optokoppler durch einen
Jumperbrücke ausgetauscht.
Gruss
Ulrich
@wigbert, @radiguli
Vielen Dank, da werde ich mir wohl heute Abend auch nen Jumper
einbasteln. Mal schauen ob ich heute noch dazu komme. Melde mich auf
jeden Fall mit dem Ergebnis!
Schöne Woche
Wolfgang
Hallo Wolfgang,
bitte bei den o.g.Code den 10KOhm Pullup-Widerstand nicht vergessen.
Sonst bleibt die Schleife stehen.
Ich hab den einfach auf die richtigen Pins eines freien Controller-
sockels gesteckt.
Wigbert
Hi, also meine Abänderungen betreffen das Pollin-Board. In den Routinen
sind die notwendigen Pullups und Optokoppleranschaltungen bereits drin.
(c) by Benedikt! (danke dafür)
An den Bitsetzungen fürs SPI habe ich auch etwas verändert.
Schaut einfach mal rein, senden tut das Teil prima.
Led 1 dient der Anzeige ob das Device bereit ist.
Led 2 blinkt beim senden
DAmit das Teil auch was sendet müsst ihr den Taster gedrückt halten.
Ein anderer wichtiger Punkt. Ich habe den Optokoppler nun entfernt, da
ich den AVR mit dem Takt des RM12 takte. Und das Ding kann keinen
Optokoppler anschalten wenn noch kein Takt anliegt.
Deshalb eine Brücke einlöten wenn ihr den externen Takt verwenden wollt.
Noch ein wichtiger Nachtrag:
Die Spannungsversorgung für das RFM12 muss wirklich sehr sauber sein.
Ich hatte auf meinem Empfangsboard (Breedboard mit Mega8) riesige
Probleme damit. Mit angeschlossenem Programmer (mit 5V-Versorgung per
USB) lief der Empfang problemlos. Mit meinem "üblichen" Netzteil ging
zwar der Mega8 und alles andere, jedoch kam nichts an: Der RFM12 war
einfach tot!
Kaum hatte ich das Netzteil gewechselt ging alles prima.
Hallo Lorenz,
>Mach den Pullup doch einfach im Atmel an. Geht schneller...
vielleicht wird der Pin irgendwann gebraucht, und dann musst Du doch
externen Pullup-Widerstand nehmen.Vielleicht war mir auch 10K
lieber als ein Port.
Hauptsache der Pullup wird bedacht.
Wigbert
Hallo Wigbert,
Ich verwende den ATMEGA32. Der Optokoppler scheint sogar damit zu
funktionieren. Egal, jetzt ist er raus und noch immer geht nix.
Ich nun aber das Problem, dass der Pullupwiderstand nicht nur den RFM12
nach Plus ziehen will auch der PIN B.3 vom ATMega32 liegt da. Bevor ich
jetzt den Mega32 zerschieße:
Ich hab auch nen ATMega8 hier. Ich denke, ich sollte es erst einmal mit
dem probieren. Du hast das ja damit zum Laufen gebracht. Kann ich dein
Programm bekommen?
(Ein brauchbares Übertragungsprotokoll hab ich dann schon fast fertig.
Ist noch von nem früheren Projekt... Auch mit Funk... aber mehr
amateurfunklastig :-) Mir schwebt da so eine Routinglösung vor, wie beim
THENET-Protokoll in Packet Radio. Kurz: Wenn viele solche RFM12-Knoten
da sind, und einer hört nicht, sollen die anderen Router spielen. Sollte
grad noch so in nen ATMega8 passen...)
Hallo Wolfgang,
mach ich doch glatt. Der Code ist so frisch, das Du die Druckerschwärze
noch riechen müsstest.
-für m8
-10K auf m32 Sockel Pin4(PB3) ,Pin10(VCC)
-wurde gerade auf mein Pollinboard nochmals getestet
-Dein Quarz reinschreiben !!!!!! (9216000 steht drin)
-linke LED muss im Sekundentakt blinken
-Sendet im Sekundentakt.
- wenn Du den Code auf Empfang umstellst, wait 1 raus. !!!!!
Wigbert
@wigbert
Es lebt, es lebt! Im Sekundentakt kommen herrliche Bursts über den
Empfänger. Selbst OHNE Antenne kann ich eine Signalstärke von über 60dB
messen. Jetzt wird es Zeit, die zweite Patine aufzubauen! Leider ist
unter der Woche nicht soo viel Zeit.
Wolfgang
P.S.: Es ist schon irre, was auf der Frequenz 433.920Mhz in unserer
Kleinstadt so alles sendet. Da ist keine Sekunde Ruhe!
Warum der ATMega32 Schwierigkeiten macht?
Ich hab jetzt nicht intensiv nachgeschaut, aber der PinB.3 scheint da
die Schlüsselrolle zu spielen...evtl. müsste der FSK/DATA/nFFS
abgetrennt und via 10 kOhm an Plus gelegt werden...
Oder anders herum gesagt: Das Board ist ja ganz nett... aber nicht so
gut durchdacht... Naja zum Testen geht der ATMega8 auch sehr gut und
wenn da alles ausprobiert ist folgt eh eine eigene (und viel kleinere)
Platine ;-)
Gruß Wolfgang
Moin Leutz,
es ist vollbracht!
Wie ich weiter oben bereits angedeutet habe, wollte ich mit den RFM12
eine drahtlose Duplex-RS232-Verbindung realisieren und hatte dazu einige
Fragen.
Mittlerweile habe ich eine - erstaunlich gut - funktionierende Lösung.
Die Hardware ist recht übersichtlich konstruiert (im Wesentlichen RFM12,
ATtiny2313 und MAX3232 sowie einige Status-LEDs) und läuft bereits ab
deutlich unter 3V Betriebsspannung (angepeilt ist eine Versorgung durch
eine Lithiumzelle CR123A). Der Mikrocontroller wird vom RFM12 mit 10 MHz
getaktet (Fusebits auf externe Taktquelle setzen).
Die Firmware realisiert eine anwendungstransparente
"not-that-full-duplex transmission", d.h. wenn die eine
Übertragungsrichtung vollkommen ausgelastet wird, kann in der
entgegengesetzten Richtung u.U. nicht die gesamte Bandbreite der
seriellen Schnittstelle genutzt werden (für Bursts stehen sende- und
empfangsseitig je 57 Byte Pufferspeicher zur Verfügung). Für den
typischen Anwendungsfall einer Dateiübertragung via X/Y/Z-Modem oder
Kermit ist dies jedoch völlig ausreichend.
Die Bitrate der seriellen Schnittstelle kann bis hinauf zu 115,2 kbit/s
konfiguriert werden, auf der Funkseite sind ebenfalls max. 115 kbit/s
möglich. Mit einem Trick (Aktivierung des Paritätsbits auf der seriellen
Schnittstelle, um eine Bitzeit mehr "Luft" zu gewinnen) konnte ich dabei
mit Kermit oder ZModem Übertragungsraten von bis zu 9,5 KByte/s
erzielen. Allerdings wird die Übertragung über mehr als einige Meter bei
dieser Geschwindigkeit bereits recht unzuverlässig. Eine ein oder zwei
Stufen geringere Funkdatenrate und dementsprechende serielle Bitrate von
57,6 kbits/s konnte ich aber problemlos in meiner gesamten Wohnung
ausnutzen. Die Firmware stellt im Bedarfsfall auch eine fehlertolerante
Übertragung via (8,4)-Hamming-Code (mit entsprechender Reduzierung des
Durchsatzes) zur Verfügung.
Eine Verschlüsselung der übertragenen Daten oder eine Adressierung
mehrerer Adapter ist nicht realisiert, auch eine gesicherte Übertragung
(mit CRC, Sendewiederholung etc.) ist nicht implementiert.
Die Konfiguration der Parameter erfolgt über ein einfaches
Terminalinterface, das mit nahezu jedem Terminalprogramm bedient werden
kann. Wird beim Einschalten des Adapters der Pin 9 (Port D.5) des ATtiny
über eine Taste auf L gezogen, wird der Konfigurationsmodus gestartet.
Nach dem Senden eines Leerzeichens (0x20) zur Messung der Bitrate der
seriellen Schnittstelle erscheint dann das Hauptmenü:
Serial Bridge V0.1
1-Serial Bitrate
2-Serial Interface Settings
3-Radio Data Rate
4-Base Frequency
5-FSK Range
6-Receiver Bandwidth
7-Output Power Setting
8-DQD Threshold
9-Protection
Navigiert wird mit den Ziffern 0...9, wobei man mit 0 immer wieder
zurück in das Hauptmenü gelangt. In den Untermenüs kann mit den Ziffern
1 bis max. 9 der gewünschte Parameter gesetzt werden. Im
"Protection"-Untermenü wird die oben angesprochene fehlertolerante
Hamming-Übertragung aktiviert.
Alle Einstellungen werden natürlich im EEPROM des ATtiny gespeichert.
Die Beschaltung des ATtiny2313:
Pin 2: RxD - vom MAX 3232
Pin 3: TxD /
Pin 5: CLK vom RFM12
Pin 6: LED1 (grün)
Pin 7: LED2 (gelb)
Pin 8: LED3 (rot)
Pin 9: Taste
Pin 10: Vss
Pin 11: nRES -
Pin 12: SDI \ \
Pin 13: SDO vom RFM12
Pin 14: SCk
Pin 15: nSEL -
Pin 20: Vdd
Am RFM12 ist der Anschluß FSK/DATA/nFFS über einige kOhm auf H-Pegel zu
legen. Als Antenne wird ein Stück Draht (idealerweise ca. 17 cm lang)
verwendet.
Der MAX3232 ist nach Datenblatt beschaltet. Es hat sich gezeigt, daß
durch die Spannungsverdoppler- und -inverterschaltung des MAX3232
relativ starke Störungen (Oberwellen) auf den Betriebsspannungsanschluß
eingekoppelt werden, die den Empfang des RFM12 deutlich beeinträchtigen
(beim MAX232 ist mir das nicht aufgefallen). Eine 150uH-Drossel zwischen
Pin 16 des MAX3232 und der restlichen Betriebsspannungsversorgung
schafft Abhilfe.
Die Betriebsspannung ist mit 100nF Keramik und einigen 100uF Elektrolyt
gepuffert.
Die gesamte Schaltung habe ich auf 4x4cm Lochraster untergebracht.
Die Funktionen der LEDs:
Beim Einschalten leuchtet zunächst kurz LED1, danach gemeinsam kurz LED2
und LED3.
Wurde die Taste gedrückt, verlöschen alle LEDs und der
Konfigurationsmodus wird aktiviert, anderenfalls versucht der Adapter
den Kontakt zu seinem Partner aufzunehmen.
Kann keine Verbindung hergestellt werden, blinkt LED1 deutlich
wahrnehmbar. Wurde die Verbindung aktiviert, blinkt LED1 ebenfalls,
allerdings so schnell (im Rhythmus der Kommunikation der beiden Adapter
miteinander), daß sich ein kontinuierliches Leuchten der LED1 ergibt
(etwas dunkler als Dauerlicht). Leuchtet LED1 gar nicht oder mit voller
Helligkeit, dann hat sich irgend etwas aufgehängt und der Adapter sollte
zurückgesetzt werden.
Die LED2 signalisiert, daß beim Empfang ein korrigierbarer Hammingfehler
(Einbitfehler) festgestellt wurde.
Die LED3 signalisiert, daß beim Empfang ein nicht korrigierbarer
Hammingfehler (Zwei- oder Mehrbitfehler) festgestellt wurde. LED2 und
LED3 leuchten im Fehlerfall ca. 1,5 Sekunden und können zur Beurteilung
der Verbindungsqualität verwendet werden.
Als Übertragungsverfahren habe ich mir folgendes einfallen lassen:
0x2D---0xD4---LI---[Nutzdaten]---0xAA---0xAA
Nach dem Synchronwort 0x2DD4 wird ein Längenindikator (8 Bit)
übertragen. Dieser Längenindikator ist immer (8,4)-hammingcodiert. Sind
keine Nutzdaten zu übertragen, der Längenindikator also 0, werden direkt
zwei Füllbytes 0xAA angehängt (ansonsten folgt nun die Payload - je nach
Konfiguration "nackt" oder hammingcodiert - und am Ende wieder die zwei
Füllbytes) und danach in den Empfangsmodus gewechselt. Der empfangende
Adapter wechselt dann seinerseits in den Sendemodus und so fort. Es
findet also ein fortwährendes Handshaking beider Adapter statt. Dies
erlaubt es, die über die serielle Schnittstelle eintreffenden Nutzdaten
nahezu verzögerungsfrei zum Gegenüber zu übertragen. Empfängt der
Adapter innerhalb einer gewissen Zeit nichts, wechselt er wieder in den
Sendemodus; dadurch ergibt sich dann das Blinken der LED1.
Ich habe während der Tests etliche MBytes übertragen und kann nur immer
wieder mein Erstaunen über die Zuverlässigkeit auch bei höheren Bitraten
zum Ausdruck bringen.
Vielleicht kann der Eine oder Andere auch etwas mit meiner Lösung
anfangen oder eventuell diese oder jene Routine gebrauchen.
Gruß
Horst
Hallo,
habe mal für alle "Erstanwender" des RFM12 mein TV-Messempfänger
in 1m Entfernung mit ca 17cm Drahtantenne positioniert.
Bei Verwendung meines o.g. Codes sollte folgendes passieren.
(wer die Frequenz micht einstellen kann, Kanal 37 )
Beim Senden wird das Bild dunkel bzw der Schnee sollte weg sein und das
Rauschen ist nicht mehr zu hören (kurzzeitig da nur kurz auf Senden) und
das im Sekundentakt.
Gemessen hab ich ein Pegel von knapp 81 bBµV.(obige Ant.+ Entfernung)
Wobei ich der Meinung bin, das der Pegel zu 433,6 Mhz etwas ansteigt.
Wigbert
Hallo ins Forum,
wie ich sehe sind hier ja schon einige mit dem RFM12 beschäftigt.
Leider läuft's bei mir nicht so richtig...
Den Frenquenz Devider kann ich per setting einstellen, sodass ich die
10MHz (oder andere Werte) am CLK pin messen kann. Die SPI Verbindung
scheint also zu gehen. (d.h. bei einem von 3 Modulen geht auch das
nicht)
Beim Senden bekomme ich auf einem 70cm Empfänger auch einen Träger
angezeigt, bei 433.92 (der eingestellten Sendefrequenz) aber ohne
Modulation.
Beim Empfang bekomme ich grundsätzlich eine 0 im MSB, d.h. ich bekomme
gar kein Ready zurück :-(
Hat jemand von euch schon mal den Status ausgelesen?
Bzw. würde mich interessieren, welche Werte bekommt ihr eingelesen, wenn
Ihr die Controllregister beschreibt?
Also bei mir sind das während der initialisierung und dem Senden immer
0xFFFF und beim umschalten auf Empang sieht das wie folgt aus:
Schreibe 0x82C8 (Lese: 0xFFFF)
Schreibe 0xCA81 (Lese: 0x0000)
Schreibe 0xCA83 (Lese: 0x0000)
Warten auf Ready ... aber MSB bleibt auf 0
Kann mir mal jemand seine Werte schicken, die er beim Schreiben auf das
RFM12 im Gegenzug erhält?
Viele Grüße an alle Bastler
Toemi
Ich habe die Werte jetzt nicht ausgelesen, aber ich wette der Fehler
liegt in der Softwareroutine die die 16bit ausgeben/einlesen. Poste mal
den Code, dann kann ich mal drüberschauen. 0x0000 und 0xFFFF sehen sehr
danach aus, dass irgenwas, nur nicht der Status gelesen wird.
Hallo Benedikt,
danke für die schnelle Antwort.
Denke nicht, dass es an der SPI Routine liegt,
weil auch auf dem Oszi (siehe Anhang) sieht man, dass nichts
zurück-gesendet wird,
sondern erst nach dem Kommando 0x82C8 das RFM12 von High->Low wechselt.
Habe auch schon mit dem Timing gespielt, alles ohne Erfolg...
Bzgl. code muss ich mich als NICHT-AVRler outen ;-(
aber der C-Code sieht wie folgt aus:
unsigned int rf12_trans(unsigned int data)
{
unsigned char i;
RFM_nSEL = 0;
delay_1us(10);
for (i=0; i<16; i++)
{
if (data & 0x8000)
RFM_SDI = 1;
else
RFM_SDI = 0;
data<<=1;
if (RFM_SDO == 1)
data|=1;
delay_1us(5);
RFM_SCK = 1;
delay_1us(10);
RFM_SCK = 0;
delay_1us(5);
}
RFM_nSEL = 1;
return data;
}
Also mich würde echt mal interessieren,
was bei dir so zurückkommt, wenn Du ein Kommando sendest,
bzw. ob Du den Status auslesen kannst?
Will aber natürlich auch keine zusätzliche Arbeit bei dir generieren ...
Viele Grüße,
Toemi
Deine Routinen sehen gut aus, das Timing ist auch langsam, daran sollte
es eigentlich nicht liegen.
Wenn ich nur 0xC0E0 sende, kommt u.a. das zurück:
0100000010000000
und danach
0000000010000000
Deutlich zu erkennen: Das POR Flag, das nur beim ersten Lesen gesetzt
ist.
Mit der kompletten Initialisierung kommt das zurück:
0000001000000011
Die hintersten Bits wechseln aber andauernd, je nachdem welchen Müll das
Modul empfängt.
Wenn das Modul ein Signal empfängt, dann das hier:
0000001110100011
Und wenn die Daten gültig sind, (Sync Pattern empfangen), dann das hier:
1010000111111110
Hi Benedikt,
danke für die Messung,
nur damit ich dich richtig verstehe:
Bei jeder SPI-Ausgabe wird ja auch ein Wert eingelesen,
das sind die Werte, die Du angegeben hast, richtig?
Was bekommst Du denn, wenn Du direkt nach dem Einschalten explizit nach
dem Status fragst, also 0x0000 sendest?
Also irgendwie scheinen meine Teilchen anders zu laufen ...
Welche Revision habt ihr denn?
Bei mir auf der Unterseite steht:
RFM12S
Rev:3.0
Gekauft bei Pollin...
Also langsam vergeht mir der Spass ...
Viele Grüße,
Toemi
Direkt nach dem Einschalten der Spannung, wenn das erste mal der Status
gelesen wird, müsste das 2. Bit gesetzt sein (Power on Reset).
Sollte das nicht der Fall sein passt etwas nicht mit der Verdrahtung.
All diese Bits lese ich, während ich 0x0000 sende.
Wartest du mit dem Lesen auch 0,1s bis das Modul bereit ist ?
Laut Datenblatt sollten die Pegel bei der fallenden Flanke wechseln. Bei
dir wechselt der Ausgang des RFM12 mit der steigenden Flanke. Seltsam.
Meine Module sind auch Rev 3 von Pollin.
Hi,
also langsam versteh ich's ... und ich mach fortschritte:
Man muss wohl explizit den Status abfragen (0x0000 senden, und Status
einlesen)
Das, was bei den sonstigen Kommandos ausgegeben wird hat wohl keine
Bedeutung ?!
also jetzt habe ich mal direkt nach dem Einschalten den Status
abgefragt:
Gesendet: 0x0000 Empfangen: 0x4000 ==> POR gesetzt
Nach einem Reset;
Gesendet: 0x0000 Empfangen: 0x0000 ==> Flag gelöscht
Wenn dann irgendwann mal der Receiver enabled war, dann flattern auch
die unteren Bits.
Nur Empfangen tue ich noch nichts ...
Muss jetzt nochmal die Register überprüfen:
Init für Send und Empfangsmodul identisch:
0xC000 ==> 1MHz am CLK output okay !
0x80D7
0xC2AB
0xCA81
0xE000
0xC800
0xC4F7
0xA620
0x948C
0xC610
0x9860
Sender:
0x8238
0xB8AA
0xB8AA
0xB8AA
0xB82D
0xB8D4
some data 0xB8xx
0x8208
Dann nach dem Status gefragt:
gesendet 0x0000 und hier 0xA000 als Antwort,
nochmal 0x0000 und hier 0x8000 als Antwort,
könnte auch passen: TX Register ready, warum beim ersten Status RGUR (TX
register underrun, register overwrite gesetzt ist, keine Ahnung ???
Empfänger:
0x82C8
0xCA81
0xCA83
warten auf Status.MSB <<<=== tja, und hier bekomme ich nie das MSB
gesetzt
Status zeigt mir 0x02?? an, also FIFO empty (FFEM)
Vielleicht liegt das Problem doch am RGUR flag beim Sender ???
Benedikt, kannst Du bitte mal den Status auslesen,
nachdem Du was gesendet hast?
Danke und Gute Nacht,
Toemi
hab ich das bis hier überlesen ?
ich weiss immer noch nicht wie ich das RFM 01 an den Atmel anschliesse,
hat mal jemand ein Bild ?
ich hab mein Modul auf einen gekürzten Eprom Sockel 24-pol gelötet, als
Zwischenlage etwas Lochraster um Abstand Platine Kontakte und Sockel zu
bekommen
bis jetzt weiss ich nur das Miso Mosi benutzt wird ? ist das zwingend ?
wirft wieder meine Planung über den Haufen , da hängen meine Taster dran
, na egal wenn die Ports ausgehen muss ich eh auf Key via I²C Port
PCH8574 oder war das PCF ? beides jedenfalls Röhren :-)))
Wenn du meine Softwareroutinen verwendest, dann kannst du jeden
beliebigen Pin verwenden. Die Belegung steht in der rf01.c und kann dort
auch verändert werden.
@ Benedikt K.
gerne, welchen Takt braucht der Atmel mind ?
sind die downloadlinks up2date ? äh welchem Link soll ich folgen, dem
ersten im Thread oder muss ich nach updates suchen ?
@ Benedikt K.
also brauch ich von den 14 Pins nur
Vcc hier VDD
GND
Antenne
SDI 5 // SDI, -> RF02
SCK 6 // SCK, -> RF02
nSEL 7 // nSEL, -> RF02
SDO 0 // FFIT/SDO, <- RF02
das
http://www.mikrocontroller.net/attachment/22522/rfm01.zip
#define CS in nSEL wäre eleganter ? ich hab mir einen Wolf gesucht was
du mit CS meinst, klaro chip select, aber wenn die den nSEL nennen, na
egal
while (!(RF_PIN&(1<<SDO))); // wait until data in FIFO
macht mir noch Kopfschmerzen, nicht wirklich kooperativ, ich halte doch
meinen atmel nicht solange an ! hat jemand eine bessere Idee ?
lg
jar
Benedikt,
kannst Du bitte mal den Status auslesen,
nachdem Du was gesendet hast?
Bei mir kommt zunächst einaml 0xA000 als Antwort,
und dann bei den nächsten Status 0x8000 als Antwort.
Weisst DU was das RGUR flag beim bedeutet?
Gruss, Holger
1010000111111110 kommt an, wenn ich das Sync Word sende.
RGUR bedeutet, dass der Sender am Senden ist, aber du zu spät Daten
nachgeladen hast, der konstante Bitstrom beim Senden also abgerissen
ist.
Das ist im Prinzip das gleiche wie der Pufferüberlauf beim Empfangen,
daher teilen sich beide auch das selbe Bit.
Eigentlich solltest du erst 0x8000 bekommen (=Daten im Puffer) und kurze
Zeit später 0xA000 (= Puffer übergelaufen), wenn du keine Daten liest.
@ Benedikt
Dann machs doch so:
if (RF_PIN&(1<<SDO))
rx_data();
???
reden wir von verschiedenen Programmen ?
rx_data(); gibt es nicht !
wenn du rf01_rxdata(data, 32); meinst dann sind die inkompatibel weil
rf01_rxdata(data, 32); != rx_data(void); ist
sorry das ich frage aber so schnell blicke ich nicht durch
lg
jar
Ja, diese Funktion mein ich. Die heist bei jeder Version ein wenig
anderst, aber es geht ja nur ums Prinzip:
Schauen ob Daten da sind, falls ja, dann die Funktion aufrufen.
Hallo Leutz,
Ich versuche seit 2 Tagen vergeblich eine Kommunikation mit dem RFM12
aufzubauen, jedoch hapert es schon bei der SPI Kommunikation.
Ich versuche das ganze mit Hardware SPI und Assembler. Der µC ist ein
PIC 18F2550. Da ich über Assembler und RFM12, noch fast nichts gefunden
habe, melde ich mich mal zu meinen Problemen und eventuell kann mir ja
jemand helfen.
Meine Fragen:
- Der µC befindet sich AUSSCHLIEßLICH im Master Mode!?
- Die Verwaltung des nSel Pins muss ich per hand machen? Also keine
Verwaltung durch das Hardware SPI interface?
- Welche Zustände muss der nSel haben und zu welchen Momenten?
- Muss ich auf SLAVE Commnunication umstellen wenn ich Daten Empfangen
möchte?
- Auf meinem SDO pin des Funkmoduls bekomme ich rein garnichts!?
- Die Initialiesierung hab ich gemacht wie in Benedikt's code!
Hab auch schon ein zweites Modul ausprobiert aber ich kann weder
auslesen noch senden, noch sonst irgentwas ich messe die Daten am Oszi
und sehe wie der Controller sie sendet! Doch zurück kommt nix!?
Ich wäre über eure Hilfe echt dankbar!
P.S. Also momentan kommt I²C echt einfacher vor!
Liebe Grüße
Moritz
Hallo Moritz,
ich bin hier auch am Testen und habe so meine Probleme ...
Schau dir doch mal mein Timing Diagramm hier an:
Beitrag "Re: Beispielprogramm für RFM12 433MHz Funk-Module"
nSEL ist im Ruhezustand HIGH, und geht vor der Starten der seriellen
Kommunikation auf LOW. Dann kommen die Daten, das MSB zuerst. Am Ende
der Übertargung, also nach dem LSB geht nSEL wieder auf HIGH.
Dass Du auf dem SDO nichts siehst, hat mich auch verunsichert. Aber der
Status wird nur ausgegeben wenn Du als Kommando 0x0000 schickst, dann
siehst Du parallel zu deinem 0x0000 Wort auch auf SDO Signale vom RFM12.
Am Einfachsten Du schickst einfach mal das Kommando 0xC000:
Also wie folgt:
Power ON
nSEL = High
eine Zeit lang warten
nSEL = LOW
uC => SDI : 1100 0000 0000 0000 (jedes Bit mit SCK low-high-low
übertragen)
nSEL = HIGH
Nun mess mal am CLK, da muessten nun 1MHz anliegen.
So kannst Du erst mal deine serielle Kommunikation testen (vom uc =>
RFM12)
Um die andere Richtung zu testen einfach mal den Status senden 0x0000:
Power ON
nSEL = High
eine Zeit lang warten
nSEL = LOW
uC => SDI : 0000 0000 0000 0000 (jedes Bit mit SCK low-high-low
übertragen)
und gleichzeitig SDO abfragen und die Bits einlesen.
nSEL = HIGH
Du muesstest beim ersten mal 0xA000 einlesen (damit wird der Power On
gekennzeichnet) und beim nächsten mal Status abfragen bekommst Du 0x8000
als Antwort.
Somit ist auch der serielle Empfang getestet.
Die Funkstrecke klappt bei mir aber noch nicht.
Habe aber gerade die Idee, dass ich vielleicht schneller auf dem
seriellen Bus sein muss. Hatte zu Testzwecken mal delays eingebaut ...
Viel Erfolg,
Toemi
Hallo Benedikt,
manchmal ist es gut seine Gedanken einfach mal so auszutauschen ...
Mit Deiner Aussage "...Deine Routinen sehen gut aus, das Timing ist auch
langsam, daran sollte es eigentlich nicht liegen." hattest Du natürlich
recht bezügliche dem SPI an sich,
aber dem Sender gefällt das nicht (wie Du ja auch meintest), wenn er die
Daten nicht schnell genug nachgeschoben bekommt "...aber du zu spät
Daten nachgeladen hast, der konstante Bitstrom beim Senden also
abgerissen ist. ..."
Nachdem ich meine Delays entfernt habe, das SPI nun also schneller
läuft, funzt die Sache hier nun einwandfrei.
DANKE für die Unterstützung!
Moritz, wie sieht's bei dir aus ?
Viele Grüße,
Toemi
Guten Abend,
Freut mich das es bei dir läuft!!!
Ich bin ein ganzes Stück weiter.
Also meine SendeSPI scheint zu funktionieren. Ich kann den Teiler vom
CLKOut beliebig einstellen. Hatte schon 2 Mhz und 10 Mhz am CLK liegen,
jenachdem wie ich es geschrieben hatte! Also von daher denk ich, alles
okay. Nur das Empfangen macht mir noch Schwierigkeiten. Die Timings hab
ich auch schon in verdacht gehabt bin aber jetzt auf Max Speed gegangen
was bei 4,6µS impulse für den RFM12 ja echt langsam ist, wie ich
Datenblatt lesen konnte. Nunja, ich denke für den heutigen Tag/Nacht
reicht es! Und etwas weiter bin ich ja auch schon. ;-)
Aber nun zu meinem Empfangsproblem ich empfange entweder nur 1en oder
nur 0en. In deinem (Toemi) Beitrag weiter oben, hab ich gelesen das es
bei dir auch mal so war? Eventuell weißt du die Lösung? Aber!!!!, Vielen
Dank du hast mir schon viel weitergeholfen!
Liebe Grüße
Moritz
Hi Moritz,
mit den 0-en und 1-en war ein Fehler von mir,
das war immer der Wert, den ich mit den Kommandos zurückerhalten habe,
aber nie in der eigentliche Empgfangsroutine.
Nun werte ich nur noch den Rückgabewert von der Statusabfrage aus (Sende
0x0000 und lese Status parallel dazu ein). Das bringt dann auch mal ein
paar andere Bits.
Der eigentliche Empfang ging bei mir ja zunächst gar nicht, da ich schon
im rf12_ready() hängen blieb, weil das MSB nicht gesetzt war, weil der
Sender gar nicht richtig gesendet hat, weil ich zu langasam die Daten in
den Sender geschoben habe.
Hmmm, so spontan habe ich da keine Idee für Dich,
höchsten nochmal die Frage, was Du auf eine Statusanfrage (Sende 0x0000
und lese parallel dazu die Antwort ein erhälst)
Teste mal gleich nach dem Einschalten, bevor du das erst kommando
schickst.
Damit siehst Du on auch das SPI Empfangen funktioniert.
Du muesstest beim ersten mal 0xA000 einlesen (damit wird der Power On
gekennzeichnet) und beim nächsten mal Status abfragen bekommst Du 0x8000
als Antwort.
Gruss, Toemi
Moin,
Also ich komm hier nicht weiter, ich habe mal mein CLK und den SDO pin
am Oszi dargestellt und abfotographiert. Eventuell siehst du ja was
falsch läuft. Ich habe das komische Gefühl das es mit dem Hardware SPI
nie was wird und wenn ich es von Hand geschrieben hätte schon fertig
wäre!? Die Flanken im SDO bekomme ich auch nur so wie dargestellt wenn
ich den PIN Up-Pulle. Hast du auch Pull-Ups dran? An allen? Könnte die
Pause zwischen den 8 Clocks das Problem sein?!
Wenn ich einschalte und einmal 0x0000 sende kommt 0xFFFF zurück! und
wenn ich das dauer sende bleibt es dabei! aber ist das was ich auf dem
Oszi sehe wirklich 0xFFFF es sieht mir so nach 0x0000 aus? Naja auf
jeden Fall bekomme ich nix zurück ohne Pull-up tut sich an dem Pin
garnichts.
Mmmh so langsam wird es nervig...!
Vielen Dank,
Hoffnungsvolle Grüße
Moritz
Hey!
Ja so wie im Datenblatt verlangt, alles Ausgänge und der SDI wird
automatisch verwaltet, hab aber beides ausprobiert. Ich habe eben
probiert, dass was ich sende gleichzeitig zu empfangen. Kein Erfolg es
kommt auch nur 0xFFFF und 0x0000 an also sehe ich Probleme bei dem
Hardware SPI. Ich werde heut Abend die Routinen selber schreiben, das
ist glaub ich das sinnvollste, oder? denn ich denke das ist hier
verschenkte Zeit und ne SPI Übertragung ist ja nun nicht soooo schwierig
;-).
Ich meld mich! Danke euch allen! Super Support hier!
Grüße Moritz
Die Software bei den Programmen hier verwendet Software SPI, die sollte
mit jedem Controller funktionieren. Bei der RS232 Funkbrücke wird der
Hardware SPI auf einem mega8 verwendet. Beide Routinen funktionieren,
probier diese also mal aus. Damit kannst du einen Softwarefehler
ausschließen.
Meine Assembler-Routine zum Senden von Befehlen sieht so aus:
1
RF12_CMD: ;sendet befehl in r16/r17 und empfängt Daten wieder in r16/17
2
cbi PORT_SPI,SEL ;Chip Select
3
ldi r18,16 ;Schleifenzähler für die einzelnen Bits
4
STloop:
5
cbi PORT_SPI,SCK ;Clock LO
6
clc ;carry löschen
7
sbic PIN_SPI,SDI ;Bit am SPI Eingang =0?
8
sec ;dann carry setzen, an sonsten gelöscht lassen
9
rol r16 ;Carry-Bit hinein schieben
10
rol r17
11
brcc cl ;herausgeschobenes Bit =0?
12
sbi PORT_SPI,SDO ;ja, dann SDO auf HI
13
rjmp cw ;und weiter
14
cl:
15
cbi PORT_SPI,SDO ;SDO LO
16
nop
17
cw:
18
sbi PORT_SPI,SCK ;Clock HI
19
dec r18
20
brne STloop ;weiter mit Schleife
21
cbi PORT_SPI,SCK ;Clock LO
22
sbi PORT_SPI,SEL ;Chip Deselect
23
ret
Diese liefert , nachdem ich die Initialisierungs-Befehle aus dem
Beispielprogramm des Herstellers ($80d7,$8239...) gesendet habe und dann
den "Staus Read"-Befehl gesendet habe den Wert $4080 bei erneutem Senden
$0080. Das heißt, diese Routine müsste funktionieren, da das POR-Bit
nach dem ersten Lesen gelöscht wird.
Allerdings bekomme ich das ganze nicht mit dem Hardware-SPI hin. Ich
habe schon sämtliche kombinationen bezüglich der Bits CPOL und CPHA im
SPI-Control-Register versucht, aber nichts hat funktioniert, ich bekomme
immer nur $ffff zurück. Wenn ich das Datenblatt des ATMega8 richtig
verstanden habe, muss man sich um das setzen und löschen des SS-Pin im
"Master-Modus" selbst kümmern oder wird es doch automatisch gesteuert?
In den Beispiel-Programmen taucht es jedenfalls nicht auf.
@ Johannes
Welche Geschwindigkeit verwendest du ?
Bei mir funktioniert es nur bis max 3MHz SPI Takt (obwohl laut
Datenblatt mehr möglich sein sollten.) Das Modul läuft mit dem SPI Modus
0.
@Benedikt K.
nachdem ich das erste RFM01 zerlötet hatte klappts nun mit dem 2ten,
zumindest sieht es gut aus, aber
warum ist der FiFo nach power on nicht leer ?
ich lese und lese -> while(RF_PIN&(1<<SDO)
und kommt immer 0 raus
ist der FiFo voll mit Nullen auch wenn keiner sendet ?
Benedikt K. wrote:
> Schaltest du den FIFO vorher sauber ein ?
sieht so aus , denke ich jedenfalls aus deine Code Schnipsel
BTW, was erwarte ich denn bei diesen China Sendern ?
reguläre Rx Daten sicher nicht, der Power Commander (IR Verlängerung)
sagt 433 MHz Empfang im China Sender vorhanden
http://www.linkdelight.com/photo/remoteCordControl/R7C.jpg
#ifdef RF_PORT
rf01_init(); // ein paar Register setzen (z.B. CLK auf 10MHz)
void rf01_init(void)
{ unsigned char i;
RF_PORT=(1<<CS);
for (i=0; i<11; i++)
_delay_ms(10); // wait until POR done
rf01_trans(0xC2E0); // AVR CLK: 10MHz
rf01_trans(0xC42B); // Data Filter: internal
rf01_trans(0xCE88); // FIFO mode
rf01_trans(0xC6F7); // AFC settings: autotuning: -10kHz...+7,5kHz
rf01_trans(0xE000); // disable wakeuptimer
rf01_trans(0xCC00); // disable low duty cycle
}
Benedikt K. wrote:
> Schaltest du den FIFO vorher sauber ein ?
ja
aber RF_PORT=(1<<CS);
ist eine böse Falle, 3 Tage Fehlersuche warum nicht RF_PORT|=(1<<CS); ?
@Benedikt K.
Mein Code sieht jetzt folgendermaßen aus:
1
.equ SDI = 3 ;-----> SDO
2
.equ SDO = 4 ;-----> SDI
3
.equ SCK = 5 ;-----> SCK
4
.equ SEL = 2 ;-----> nSEL
5
.equ nIRQ = 1 ;-----> nIRQ
6
.equ PORT_SPI = PORTB
7
.equ DDR_SPI = DDRB
8
9
sbi PORT_SPI,SEL ; SEL auf HI -> nicht selektieren
10
cbi PORT_SPI,SCK ; SPI Clock LO
11
sbi DDR_SPI,SDO
12
sbi DDR_SPI,SCK
13
sbi DDR_SPI,SEL
14
cbi DDR_SPI,nIRQ
15
cbi DDR_SPI,SDI
16
17
// initialisieren als Master mit Prescaler 16
18
ldi r16, (1<<SPE)|(1<<MSTR)|(1<<SPR0)
19
out SPCR,r16
20
21
RF12_CMD: ;sendet befehl in r16/r17 und empfängt Daten wieder in r16/17
22
cbi PORT_SPI,SEL ;Chip Select
23
//***
24
out SPDR,r17 ;Erstes Byte senden
25
t1:
26
sbis SPSR,SPIF ;warten bis Transfer zu Ende
27
rjmp t1
28
in r17,SPDR ;Angekommenes Byte wieder in r17
29
//***
30
out SPDR,r16 ;Zweites Byte senden
31
t2:
32
sbis SPSR,SPIF ;warten bis Transfer zu Ende
33
rjmp t2
34
in r16,SPDR ;Angekommenes Byte wieder in r16
35
//***
36
sbi PORT_SPI,SEL ;Chip Deselect
37
ret
Ich habs auch schon mit einem Vorteiler von 128 versucht und an den mit
//*** Markierten stellen eine warteschleife eingefügt, hat alles nichts
genutzt. eigentlich sollte das Timing ja nicht so kritisch sein, weil
laut Datenblatt höchstens mal 25ns gewartet werden muss (Timing
specification), was aber bei 16Mhz Takt niemals unterschritten wird.
Dem Datenblatt darf man nicht so ganz vertrauen: Bei mir funktioniert
das ganze mit 5MHz SPI Takt nicht, nur mit 2,5MHz, obwohl eigentlich
laut Datenblatt alles schneller sein dürfte.
Kann es sein, dass du SDO und SDI vertauscht hast ?
Na toll! hätte ich mir mal die Mühe gemacht und mir im Datenblatt die
Bedeutung von "MOSI" und "MISO" angeschaut, dann hätte ich mir viel
Ärger gespart! Vielen Dank, Benedikt!
Bei mir funktiert es jetzt sogar mit einer Clock-Frequenz von 8Mhz, also
mit dem kleinsten Vorteiler von 2.
Habe den ganzen Post jetzt mehr überflogen als gelesen, weil er sich
doch schon zu einem Monster entwickelt hat...
Wenn ich eine Funksteurung der einfachsten Art brauche, kann ich doch
den Code im ersten Post mit der NOP Ergänzung nehmen oder gibts es eine
aktuellere Version, die genauso einfach ist?
MfG
Kai
Hallo erstmal,
ich bin am verzweifeln. Ich habe das rfm01 und rfm02 und möchte sie mit
2 mega8 und Bascom laufen lassen. Die Clk-Einstellung kann ich auf
verschieden Takte ändern, drum denke ich, die Spi-Schnittstellen laufen.
Beim Empfänger kommen verschiede Werte an, allerdings ignoriere ich
momentan das sdo-Signal, wenn ich nun den Sender einschalte ändern sich
die Werte es kommt dann konstant z.b ein H3708 und beim nächsten
Senderstart konstant ein H3138. irgendwie Sendet der Sender nicht
richtig. Damit ich überprüfen kann ob die Hardware richtig ist bräuchte
ich ne Software die garantiert läuft. Könnte mir jemand mal eine Sender-
und Empfängersoftware (die halt ein paar Wörter sendet) für die RFM01
und RFM02 als hex zuschicken. Am besten mit den Pinbelegung für einen
atmel mega 8 mit 8 Mhz. Ich weiss das ist viel verlangt,aber vielleicht
hat ja jemand genau diese Konfiguration.
@test
die Programme für den rfm12 habe ich natürlich schon durch geschaut, man
findet sie auch hier im Thread ebenso im anderen grossen Thread in
diesem Forum und in andere foren. Leider sind die Befehlssätze des RFM12
nicht identisch mit denen von RFM01/RFM02 und da hängst vielleicht.
Jetzt versuche ich die C-Beispiele selber zu compilieren, bin
diesbezügl. nicht firm und bekomme immer Warnings wegen delay.h und
Errors wegen 99 C-mode usw.
Jetzt wäre es halt für mich einfacher gewesen wenn ich einen fertig
compilierten Code bekommen hätte. Naja soll wohl nicht sein, da muß ich
halt weiter kämpfen.
hi,
mal ne andere Frage. Es gibt weiter oben von Benedikt unteranderem die
beiden Progs RFM01/RFM02. Im Empfänger gibts die Zeilen:
unsigned char data[32];
for (;;)
{
rf01_rxdata(data, 32); // 32Bytes empfangen
}
Ich habe keine Ahnung von C. Wie kann ich den data auf die rs232
ausgeben? Also ich habe die Funktion
_writeString ("Hallo, Welt!\n"); die z.b funktiniert so.
Wie muss ich data da einsetzen damit ich was senden kann?
Wenn data einen Null terminierten String beinhaltet (oder mit anderen
Worten: Text), dann einfach _writeString (data);
Oder erwartet _writeString() einen String im Flash ?
@bennedikt
Habs noch mal nur mit data probiert,jetzt kommt was allerdings nur wirre
Zeichen aber im Takt und die Anzahl ist auch gleich (glaub ich). In
irgendeinem Thread hatte ich was von timingprobs dies bezgl. gelesen.
Ich habe deinen C-Code angepasst, aber wahrscheinlich nicht richtig.
Habe 2 Mega8 mit 8 Mhz
F_CPU 8000000UL //10000000UL
Hier von 10 Mhz auf 8 Mhz geändert
#define SDI 3 // SDI, -> RF02
#define SCK 5 // SCK, -> RF02
#define CS 2 // nSEL, -> RF02
#define SDO 4 // SDO, <- RF02
Muss ich irgenwas anderes noch ändern?
hi
danke für die vielen und detailierten Antworten. Jetzt habe ich noch
zwei Fragen. Ich kenne mich nur bedingt mit C aus und hieraus werde ich
nicht schlau:
void rf02_shiftout(unsigned char wert)
{ unsigned char j;
for (j=0; j<8; j++)
{ while(RF_PIN&(1<<IRQ)); <-----------
while(!(RF_PIN&(1<<IRQ))); <---------
if (wert&128)
sbi(RF_PORT, SDI);
else
cbi(RF_PORT, SDI);
wert<<=1;
}
}
Was prüfen die beide While-Abfragen? Das erste while prüft ob ein Bit im
Port gesetzt ist und das zweite ob nicht ?!?
Ich habs irgendwann geschafft nach langer Recherche und den
unmöglichsten Einstellungen die C-Programme auf den RFm01 und RFM02 zum
Laufen zu bringen.
Sie funken auch allerdings stimmen nur die ersten beiden Zeichen das
kommen wirre. Woran kann das liegen?
Das RFM02 ist ein wenig dumm anzusteuern, da es kein FIFO hat. Es gibt
aber eine kleine Hilfe: Das Modul erzeugt 1,6µs lange Impulse, sobald
das nächste Bit geladen werden soll. Diese muss man irgendwie erkennen,
und das wird mit diesem Code gemacht: Warten solange der Pin High ist,
dann warten solange der Pin Low ist. Danach wird das nächste Bit
ausgegeben. Damit das ganze fehlerfrei funktioniert, muss der AVR mit
mindestens 4MHz getaktet werden.
Hallo,
Nachdem mein Testaufbau mit den blockierenden Funktionen funktioniert
hat, bin ich auf den Interrupt-gesteuerten C-Code von Jürgen
umgestiegen.
Dabei habe ich jedoch riesige Probleme. Hardwarebasis ist ein
Pollin-Board (mit RFM12, ATMEGA32) sowie ein Breedboard (ATMEGA8) mit
dem selben Modul. Bei mir bleibt beim Sendeboard der Programmablauf in
der txfinished() und beim Empfangsboard in der rxfinish() hängen.
Wer betreibt sein RFM12 mit IRQ-Steuerung? Hat jemand den Code von
Jürgen verwendet?
Danke
Lorenz
Hier zumindest ein zur Hälfte interruptgesteuertes Programm (nur beim
Empfang). Das ganze ist recht universell und leicht im eigenen Programm
verwendbar, da wirklich alles in einer Datei ist.
Die Daten werden Byteweise der Funktion übergeben, die daraus von selbst
die Pakete bildet, diese überträgt, prüft und wieder als einzelne Bytes
zur Verfügung stellt.
Morgen,
5:18 man man man, zu was für einer Gottes unwürdigen Zeit schreibst du
Forenbeiträge? :)
Kein wunder das dein Code auch an der Stelle hängen bleibt:
1
unsignedcharrf12_txfinished(void)
2
{
3
if(RF12_status.Tx)
4
return(255);//not yet finished
5
return(0);
6
}
Nein jetzt mal im Ernst: Er kann da nicht hängen bleiben. Das ist völlig
unmöglich. Es sei den dein Speicher (Stack) ist voll, was aber relativ
unwahrscheinlich ist, sag ich mal.
Beim empfangen kann ich mir das evtl noch einigermassen vorstellen. Wenn
z.B. die Längenangebe länger ist als die eigentlich Pufferlänge. Aber
sonst, KA was du treibst.
Tus mal etwas mehr debugen, oder evtl fehlt auch dieser Hardware
Interrupt Pin bei dir, oder die Pinbelegung ist allg ander?!
Jürgen
Ach, manchmal dauerts halt etwas länger im Bastelkeller, da merkt man
erst, dass man schlafen sollte, wenns hell wird...wer kennt das nicht?!?
Also die Funktion kann schon hängen. Wenn der Status.Tx nicht mehr auf 0
gestellt wird (hab ich nirgens in deinem code gefunden ?!?) dann bleibt
der immer in der Warteschleife. Und irgendwie wechselt bei mir der
Status nicht.
Hardwaremäßig habe ich den FFIT-Pin an Int1 hängen (beim TXer). Der RXer
ist auch mit dem IRQ (Int0) verbunden.
Mein Projekt habe ich mal angehängt. Evtl ist ja jemand so nett und
wirft einen kurzen Blick drauf. Manchmal sieht man ja den Wald vor
lauter Bäumen nicht...
@Benedikt: Deine neuen Routinen habe ich mir gestern auch angeschaut.
Von der IRQ-gesteuerten Programmroutine konnte ich jedoch nichts
abstrahieren, was mich auf mein Problem gebracht hätte.
Aber ansonsten nettes Package. Sobald die IRQ-Steuerung bei mir
funktioniert will ich das mal ausprobieren. Im Endeffekt ist das die
Applikation die ich wollte (Funkbrücke, mit Hardware-Handshaking).
Tja,
ISR()
kenne ich jetzt nicht. Ist das das gleiche wie
SIGNAL()
?
Eigentlich hängt er ja nicht im Methoden aufruf, sondern in der while()
Schleife. Ich würde einfach mal Tippen das der die Async'tät einfach
nicht ausführt. Schon mal geschaut ob der da rein springt, oder ob
überhaupt das HW Signal da ankommt?
Jürgen
Hallo Jürgen,
Ja, ISR ist die neue Variante. Dafür wird dann auch der INT1_vect statt
dem INTERRUPT1 verwendet.
Nach etwas Schlaf habe ich auch den letzten Teil deines Codes
verstanden. Ich bin immer davon ausgegangen, dass das Senden ohne IRQ
von statten geht. Aber ist wohl nicht so!
Mit dem HW-Signal ist so eine Sache. Habe leider kein Oszi hier,
triggerbar schon gar nicht... Und mit dem Multimeter wirds schnell
eng... Werds wohl in Software prüfen müssen.
Andere Frage. Wie steht es denn mit den Signalpegeln bei dem Modul?
Soweit ich weiß ist das Ding active-high. Die Interrupt-Kontrollregister
hast du ja nicht verändert. Von dem her sollte das ja OK sein (default
ist ja steigender Pegel).
Benedikt hat in einen Post (anderer Thread, Funkbrücke...) mal geäußert
dass er einen Inverter davor hat???
Naja, werde die Nacht heute mal wieder mit Debuggen verbringen. Dauert
ohne vernünftiges Equipment etwas länger :-)
Ach ja, was ich noch loswerden wollte:
DANKE AN ALLE, OHNE DEN THREAD WÜRDE HEUTE NICHT MAL DIE EINFACHE
ÜBERTRAGUNG BEI MIR FUNKTIONIEREN.
Ich hab keinen inverter drinnen. Und es geht.
Aber der Proz muss >1Mhz laufen. Hab es eben mit einer Low Power
variante getestet (1Mhz) und da lief es ned. :)
Ich werde heute noch den Treiber etwas erweitern um das Energier
Management anzusteuern.
Jürgen
Hallo Benedikt
>Ich nutze einen TV PLL-Tuner um zu sehen ob das Ding sendet
hab mir von Pollin auch ein paar solcher Dinger besorgt.
Hast Du da mal was veröffentlicht?
Wigbert
Zu dem Tuner habe ich bisher noch nichts geschrieben, da die Lösung
bisher wirklich nur eine Bastellösung ist: Es funktioniert halt so
einigermaßen, damit ich was messen kann.
Einen Schaltplan usw. habe ich bisher nicht gezeichnet, da sich die
Schaltung eigentlich kontinuierlich in einer Weiterentwicklung befindet.
Wenn du am Code zur Ansteuerung für den Tuner interessiert bist, dann
schick mir mal eine Nachricht. Allerdings macht der Code nicht viel mehr
als eine Frequenz an den Tuner senden (mehr kann der Tuner ja auch
nicht, als eine Frequenz zu empfangen).
Hi folks!
Ich bin seit tagen dabei, diesen Beitrag zu lesen und das vorhandene
KnowHow anzuwenden auf meinen ATmega8 (12MHz Quarz).
Ich hab das Modul (RFM12S) wie folgt verbunden
Mega8 rfm12s sonstiges
MISO (PB4) SDO
MOSI (PB3) SDI
SS (PB2) nSEL
SCK (PB5) SCK
FSK über 5k an bat+
nINT/VDI offen
nIRQ offen
DCLK offen
CLK offen
nRES offen
PD5 LED gn
PD6 LED gb
Hier nun die Frage:
was muss ich minimal in meinem Code haben, um ein 434Mhz Signal zu
empfangen und wenn ein signal kam, die gelbe les leuchten zu lassen?
Ich komm mit den komplexen codes hier einfach nicht zu recht.
Zum beispiel bringt mir mein compiler bei der fnktion
unsigned short rf12_trans(unsigned short wert)
fehler aus. Irgendwas mit cbi und sdi. aber an den Ports ist doch
garkein Int???? Oder seh ich das falsch?
Wär cool, wenn mir jemand weiter helfen könnte.
f.y.i.: Das Signal, das ich empfangen will, ist von einer
fernsteuerbaren Steckdose, die auf 434MHz sendet. (von REV, Mod.
008341).
Grüßle
Steffen
Du hast vermutlich die global.h nicht eingebunden.
Das was du vorhast wird vermutlich nicht, bzw. nur mit etwas Umweg
funktionieren: Die Funksteckdose ist ein AM Sender, der RFM12 dagegen
ein FM Empfänger.
ok, dann war des halt nix mit der fernbedienung, aber das ist nict so
schlim, weil das nicht der entgültige zweck ist. wollte blos damit
überprüfen, ob der empfänger überhaupt was bekommt.
das mit der Lib werde ich gleich testen.
Nun zu meinem eigentlichen problem: Wozu die interrupt geschichte beim
initialisieren des moduls???
Ich brauch nen code, wer einfach nur (ambesten 8) bits sendet. diese
bits sind immer die gleichen (bit0 -> zustand von pin_x, bit1 -> Zustand
von pin_y u.s.w.). somit brauch ich blos einen sehr rudimentären code,
den sogar ich als spi-newbe verstehe.
Ich habe 2 rfm12 module, wobei ich eines nur zum senden und eines nur
zum empfangen verwenden will. früher oder später wird vielleicht
erweitert auf bidirektional, aber im moment nicht von nöten.
desshalb bin ich auf der suche nach jemandem, der mir sagen kann, was
ich alles aus den bibliotheken wirklich brauche. im prinzip ein zwischen
schritt von den projekten, die ihr alle gecoded habt.
Grüßle
Steffen
noch ne frage:
gibt es irgendeinen zwingenden grund, die 10MHz vom modul anzubinden?
Oder kann ich den ATmega auch einfach mit den internen 8MHz oder einem
externen quarz mit 12 MHz betreiben?
Grüßle
Steffen K. wrote:
> gibt es irgendeinen zwingenden grund, die 10MHz vom modul anzubinden?
Nein, der µC kann im Prinzip beliebig getaktet werden, solange er die
Daten nur schnell genug an das Modul liefern bzw. vom Modul abholen
kann.
hattest recht, die comile-fehler sind mit der global.h weg.
hätte man(n) drauf kommen können douhg
aber verstanden habe ich den code trotzdem nicht ganz:
void rf01_trans(unsigned short wert) // was ist ein short?
{ unsigned char i;
cbi(RF_PORT, CS); // was macht (_SFR_BYTE(sfr) &= ~_BV(bit))
for (i=0; i<16; i++)
{ if (wert&32768) // wenn wert und 8000h??? wo kommen
die 8000h her?
sbi(RF_PORT, SDI); // was macht (_SFR_BYTE(sfr) |= _BV(bit))
else
cbi(RF_PORT, SDI);
sbi(RF_PORT, SCK);
wert<<=1; //???
_delay_us(0.2);
cbi(RF_PORT, SCK);
}
sbi(RF_PORT, CS);
}
Ja, ok, das sind viele fragen, aber unsere lehrer sind nicht die
hellsten, denen muss ich sogar was zeigen im unterricht, wie will man(n)
denn da zum uC-crack werden..... :-/
Grüßle
ok,
wer lesen kann ist eindeutig im vorteil.
16 bit -> uint16
>typedef unsigned short uint16_t;
d.h.
>uint16_t steht für einen 16-Bit Integer ohne Vorzeichen (unsigned int) mit einem
Wertebereich von 0 bis 65536.
aber die clear bit und set bit geschichte hab ich noch ned raus :-(
moment mal, ist cbi und sbi 100% das gleiche wie |=(1<<x) und
&=~(1<<y)????
falls ja, bleibt blos noch die frage nach dem (wert&32768) konstrukt?!
Grüßle
Gegenfrage: Wenn du das RFM12 hast, wiso verwendest du dann die Routinen
für das RFM01 ?
Welche Software verwendest du ?
Nimm am besten diese hier, und betrachte diese zunächst als fertiges
Modul.
Mit rf12_putc() kannst du einzelne Bytes verschicken, die werden mit
Fehlerkorrektur usw. übertragen und der Empfänger kann diese mit
rf12_getchar() abrufen.
http://www.mikrocontroller.net/attachment/24996/rfm12_rs232_rxtx_check_int.zip
moin jungs (und mädels???)
hat mir gestern keine ruhe gelassen, dass das modul nicht funktioniert.
Bin deßhalb noch kurz in gschäft und hab mir mein oszi geholt.
zur SW: ich mach keine init vom RF-Modul sondern sende dauernd im
while(1)
rf01_trans(0x893B); // |low_bat_det, |wk_up, crystal_mode, 10pf
crystal_c, base_bw134kHz, clk_out
wenn das modul dies bekommt, müsste doch am clk-pin 10Mhz anstatt 1MHz
auskommen, oder ned???
signale kommen auch alle am jeweiligen pin an (SCK, SDI, nSEL), aber es
tut sich nichts am CLK-Ausgang.
Hab auch mal ti/tp-Verhältnis vom SCK verändert (bis auf 50/50), hat
aber auch nichts geholfen.
Hat jemand ne ahnung, woran das liegen kann?
Verdrahtet sind SDO (MISO), SDI (MOSI), nSEL (SS), SCK (SCK). VDD
schalte ich per uC über einen Port (bringt ja 40mA, %V bleiben stabil,
also null problem), FSK liegt per 5k an 5V. alles andere liegt offen.
Grüßle
Steffen K. wrote:
> wenn das modul dies bekommt, müsste doch am clk-pin 10Mhz anstatt 1MHz> auskommen, oder ned???
Nein, mit dem Befehl kann man den Takt nur abschalten. 0xC0E0 schaltet
auf 10MHz.
Hallo Leute,
ich hab mir eine schaltung aufgebaut mit rfm12. Nun meine frage zu der
Eagle schaltung: Kann ich die CLK pin mit dem XTAL pin des µC so
einbinden? Es sollte dann für die Externe Quarz gelten oder habe ich da
was falsch gemacht
Lg,
Timo
Hallo Leute,
da ich jetzt alles aufgebaut habe und die Fusebits auf extern
eingestellt habe und seitdem ich kein programm in den µC
reinprogrammieren kann, bleibt mir nur eins euch zu fragen. Ich schicke
im Anhang einen für ATMEGA8 und ATTiny2313 µC fusebits einstellungen für
externe quarz. Was mache ich falsch. Ich benutze ATTiny2313 für sender
und ATMEGA8 für empfanger mit RFM12. Programmieren tue ich mit isp
schnittstelle. Bitte um einen Feedback.
lg
Timo
Ich habe jetzt mal zwei Funkmodule mit dem ATmega8 aufgebaut und es hat
von Anfang an funktioniert!
Schade finde ich nur, dass alle Ports belegt sind und man dadurch
beispielsweise kein LCD mehr anschließen kann. Ich werde jetzt wohl
zusätzlich noch einen mega8 brauchen um ein LCD anzuschließen und
beispielsweise ein Tastenfeld für die Sachen, die ich senden will.
Aber auf jeden Fall ein großes Lob an Benedikt! Sogar ich habs
hinbekommen :D
Alle Ports belegt ? Lass die Status LEDs weg, dann hast du PortC und
PortD komplett frei und an PortB ist auch noch ein wenig frei (je
nachdem welche Version du verwendest, kann es ein wenig anderst sein).
Hallo Benedikt,
>Ja, das sollte so funktionieren.
Timo hat eine Resetverbindung vom RFM12 zum m8.
Haben wir nicht .Könnte das zu Problemen führen?
Die Fusebits sind meiner Meinung nur teilweise richtig.
Wurde aber richtiggestellt.
Wigbert
Resetpin vom RFM12 ist mit Reset vom meg8 verbunden ?
Der Pin ist an sich Open Collector, er dürfte also nicht stören. Wobei
man nie weiß, was das das RFM12 genau mit Reset macht: Es kann sein,
dass ein Reset Impuls künstlich verlängert wird.
Ist an nSEL vom Modul ein Pullup ?
Bei mir klappte es meistens, aber nicht immer:
Wenn die Isolation gut ist, reicht die parasitäre Kapazität aus, um nSEL
während des Programmierens auf high zu halten. Wenn nicht, geht SDO auf
Low -> Programmieren geht schief.
Ähnliches passiert, wenn nSEL Low war, während der Programmiervorgang
anfing.
Hallo,
Für meine zukünftige Master-Slave Kommunikation wurden für die
Erstellung und Übertragung von Datenpaketen 2 Testcode in Bascom
entworfen.
Ziel wird es sein eine Master gesteuerte Kommunikation aufzubauen.
Prinzip:
Master ruft Slave
Slave sendet Daten an Master
Master sendet Befehle an Slave
Master:
eingegebenen String (Adresse oder Datenpaket) mit Stringlänge und Check
vervollständigen. So das folgendes Paket gesendet wird:
Längenbyte- Stringbyte-Stringbyte-…………-Checkbyte
Das Längenbyte bestimmt die Sendedatenlänge.
Slave:
interruptgesteuertes Auslesen des Datenpaketes und zwischenspeichern.
Dabei wird wiederum aus dem ersten Byte die Empfangsdatenlänge
errechnet.
In einer Sub wird der Check durchgeführt und der gewonnene Textstring
ausgegeben
Eine weitere Sub dient zur Erkennung der hinterlegten Adresse.
Der Textstring wird ordnungsgemäss verarbeitet. Kommt immer richtig an.
Seltsamerweise werden aber verschiedene Werte der Checksumme empfangen.
Nicht falsche sondern unterschiedliche (letzte Ziffer).
Kann es sein, das irgendein Müll mit übertragen wird?
Ein "sinnloses"Byte einfach anzuhängen wär auch kein Problem
Die Software wurde auf Pollinboard getestet(10 Mhz von RFM12)
Wigbert
Es gibt auch ein Testboard für den RFM12 Modul für ATMEGA 8
--> http://www.comwebnet.de/seite48.html
Die Zuleitungen sind über Jumper Konfigurierbar
Das Testboard ist "Schaltung Pollinboard kompertibel"
Vielleicht hilft es den einen oder anderen beim Experimentieren.
Freie PINs vom M8 sind rausgeführt.
http://www.comwebnet.de
Hallo Leute,
habe das Problem mit dem Checksum-Fehler gefunden.
Einfach im Master ein String zuviel senden.
Also
Lean = Laenge + 3 'Länge um 1 erhöhen
Text = Text + " " 'wird im Slave nicht ausgewertet
1
'##########################
2
Sub Sendetext 'Aufbereitung des Text="Teststring"
3
Sendedata = Rufzeichen 'welcher String gebraucht wird
Also das nenne ich "Perfekten Code" von Benedikt !!!!
Ich habe mit Begeisterung diesen thread gelesen. 4x RFM12 gekauft und 2
Stück davon in 15 Minuten an meine existierenden ATmega32 angeschlossen.
Den C-Code von Benedikt vom 22. Mai in die ATmega's geworfen und läuft
!!
Also hier nochmals vielen Dank an Benedikt für diese tolle Arbeit !!!
Denn diese Datenübertragung fehlte mir noch in meiner Sammlung, da ich
mit den schrulligen Dingern von Con.. nix anfangen konnte (nach der
ersten Wand war Funkstille und das mit 1 Kbit).
Gruß
Manni
Hallo allerseits,
Na da tut sich ja einiges in diesem Thread!
Hab da noch eine andere Frage/Problem:
Und zwar verwende ich das RFM12 als Leuchtensteuerung. Das Modul
empfängt Daten, die dann im µC ausgewertet werden - dieser erzeugt dann
PWM-Signale für das Leuchtmittel.
Das funktioniert alles wunderbar, bis auf eine Kleinigkeit. Und zwar,
wenn ich das ganze eine Zeit lang laufen lasse, reagiert das RFM12 nicht
mehr auf meine Befehle, die ich von einem anderen RFM sende. Erst wenn
ich das Board in der Leuchte resete, dann spricht es wieder an.
Was kann da sein? Der µC ist es glaub ich nicht, weil die PWM-Signale
weiter erzeugt werden. Nur der Empfang wird "stumm". Auch den Sender
kann ich ausschließen.
Es könnte irgendwo im Code liegen, weil diese Problem bei all meinen
Leuchten vorkommt. Ich glaube vielleicht, dass das RFM irgendwelche
Störsignale empfängt und sich dann "aufhängt".
Ich weiß, dass das ganze ohne Code von mir nur ein Raten ist, aber
vielleicht kennt jemand das Problem. (Ich darf den Code nicht
bekanntgeben).
Vielen Dank für eure Unterstützung!
mfg
Andy
Andy wrote:
> @Trigger Schmitt:> Was soll das?
Das ist schon der 3. Eintrag dieser Art von dem Spammer.
Hat er in anderen Threads auch schon veranstaltet.
Meldung an webmaster habe ich schon geschickt.
Hallo nochmal!
Bin meinen Code nochmal durchgegangen! Ich schalte direkt nach dem
Empfang von Daten wieder in den "Bereitschaftsmodus". Das mach ich mit
folgenden Befehlen:
rf12_trans(0xCA81); // set FIFO mode
rf12_trans(0xCA83); // enable FIFO
Stimmt das? Oder muss ich da sonst noch was berücksichtigen?
Außerdem habe ich einen TimeOut programmiert. Falls das Stop-Byte nicht
empfangen wird, setzt der Timer alle Empfangsvariablen zurück und
schaltet das RFM12 mit den obigen Befehlen wieder in den
Bereitschaftsmodus?
Habe ich da irgendwo einen Denkfehler, oder könnte das so funktionieren?
Vielen Dank für eure Hilfe!!
mfg
Andy
Nachdem hier einige "Zwischenfälle" vorgekommen sind, wollte ich nur mal
nachfragen, ob vielleicht wer eine Lösung für mein Problem hätte. :-)
Vielen Dank
mfg
Andy
hallo,
weiß jemand, wie genau man die Signalstärke abfragen kann?
Kann ich zum Beispiel eine Funkfernbedienung mit dem RFM12 Modul bauen
und danach den Empfänger software seitig so zu konfigurieren, dass ich
nur Signale aus einem Meter Entfernung empfange?
Weiß das jemand?
Hallo Leute,
Ich bins wieder, habe in der Mitte schon mal gepostet, und bin immernoch
nicht weiter, ich habe inzwischen auch schon andere RFM12's ausprobiert.
NIX.
Ich vermute das ich irgentwas Hardware mäßig falsch mache. Wenn ich am
SLK takte und den SDI am modul auf "0" lasse muss ich doch an dem SD0 am
Scope irgentwas sehen?? Den Takt hab ich auch schon verändert. Ich sehe
da nix, garnichts. Wie soll ich anfangen zu suchen? Habe die Belegung
wie folgt gemacht. Habe auch schon mit pull ups und pull downs rum
gespielt aber kein ergebnis.
nSel --> SS (µC) (auch mit pullup)
SCK --> SCK (µC)
SDI --> SDO (µC)
SDO --> SDI (µC)
FSK --> Pullup (10k) an 5V
beide GND an Masse
VDD an 5 V
Ich wäre euch zu tiefst Dankbar wenn ihr mir sagen würdet was ich falsch
mache!!!
Moritz
Also habe es so gemacht:
MISO ->SDO
MOSI ->SDI
SS -> nSEL
SCK -> SCK
FSK/DATA -> 10k ->VCC
INT1 -> DCLK/FFIT ( nur wenn Interrupt Betrieb )
http://www.comwebnet.de
Ich habe noch etwas beobachtet. Wenn ich 3 mal hintereinander 0xC0E0
sende schaltet er den Clock ausgang auf 10 Mhz um. Sonst nicht NUR WENN
ICH 3 MAL sende!!!!???? Da muss doch was grundlegendes Falsch sein? Oh
man ich dreh noch durch hier, sorry.
Hoffnungsvolle grüße Moritz
Hallo,
weiß niemand ob das mit der Signalqualität so genau möglich ist?
Noch eine Frage: wie sollte ich die Antenne gestallten, wenn ich nur
eine Reichweite von 2m brauche?
megafreak wrote:
> weiß niemand ob das mit der Signalqualität so genau möglich ist?
Such mal, das habe ich schon ein paarmal erklärt, wo man das Signal
abgreifen kann.
> Noch eine Frage: wie sollte ich die Antenne gestallten, wenn ich nur> eine Reichweite von 2m brauche?
Garkeine. Bzw. Wenn du eine Antenne dranmachst, dann nimm einen 17cm
langen Kupferdraht mit etwa 0,5-1mm² und wickel den zu einer etwa 5cm
langen, etwa 5mm dicken Spule auf. Dann kannst du noch die Sendeleistung
am Modul selbst reduzieren.
Auf 2m Entfernung hat bei mir schon Sender mit 15cm Draht und Empfänger
ganz ohne Antenne, nur Steckbrett-Kontaktreihe, ausgereicht. Den Sender
hab ich dabei nie ohne Antenne getestet, weil die fest eingelötet ist.
Wieso willst du denn die Reichweite so stark begrenzen? Mehrere Sender
in der Nähe? Dann lieber die Frequenz wechseln.
Der Pin für die analoge Empfangsanzeige ist leider nicht auf die
Anschlussleisten gelegt. Irgendwo hat mal jemand gepostet, an welchem
der SMD-Teile auf dem Modul man das Signal anzapfen könnte. Ansonsten
gibt es noch die digitale RSSI-Abfrage. Da muss man anscheinend einen
Grenzwert vorgeben und bekommt dann die Rückmeldung ob der Wert drüber
oder drunter liegt.
Hi,
kann jemand der das Modul mit IRQs benutzt bitte kurz eine Pinbelegung
vom Atmel zum RFM12 posten? Ich verzweifle hier noch bei der Umsetzung
des IRQ-Betriebs mit dem Code von Jürgen.
Interessant wäre auch noch der genutzte Compiler, da ich mit GCC einige
Anpassungen am bestehenden Code vornehmen musste. Nicht dass der
Originalcode von Jürgen auf seinem Compiler ein volatile einfügt und
GCC nicht...
Danke vielmals
Lorenz
Hey,
@benedikt das wars danke!!! Jetzt funktioniert wenigstens die
Umschaltung auf 10MHz bei jedem mal senden! Vielen dank. Jetzt bleibt
nur noch das problem wenn ich 0x00 sende das nix zurück kommt! Haste
dazu noch ne idee?
Grüße
Moritz
Hallo Moritz,
ich habe auch das Problem, dass ich zwei RFM12 nicht zum laufen kriege
und ich baue das auch mit PIC's auf(16F876) .
Bei mir läuft der Empfänger schon (getestet mit einem RFM02 als Sender),
leider geht mein RFM12 als Sender nicht. Wie weit hast Du Deine Teile
schon am Laufen? Hier mein Quellcode:
Mit freundlichen Grüßen
Kalli
Ja...ääää ..richtig das ist Register 0x98xx, kannst Du mich eventuell
aufklären, was da eingestellt wird. Aus dem Datenblatt werde ich nicht
schlau :-(
Welches ist auf der Empfängerseite das dazugehörige Register (was dann
ja auch eingestellt werden muss, oder)?
Damit stellst du ein, welche Frequenzen bei einer 0 bzw 1 erzeugt werden
soll. Je größer die Frequenz, desto mehr Bandbreite benötigt man.
Allerdings ist dann natürlich auch der Abstand größer, so dass sich das
ganze leichter unterscheiden lässt. Ich stelle meist etwa 100kHz ein.
Beim Empfänger muss die Bandbreite entsprechend eingestellt werden. Dort
stelle ich meist 200kHz ein (etwa das doppelte wie beim Sender.) Ob das
die ideale Einstellung ist, weiß ich nicht, aber die Reichweite ist auf
jedenfall größer, als bei der im Datenblatt empfohlenen.