Hallo Leute, versuche nun seit Tagen ein RFM12 Modul mit einem Atmega32 zu verheiraten. Geplant ist es, vom Computer Daten über Funk an einen Controller zu verschicken und zurück, also bidirektional. Bin leider Anfänger auf diesem Gebiet. Mein Problem ist, dass zu diesem Thema in diesem Forum schon unzähliges Material exisitert. Aber glaubt mir, das macht die Sache eher schwerer (zu unterscheiden was für mich in Frage kommt und was nicht). Meistens wid lediglich ein Code gepostet, sodass ich nicht weiß welcher Controller verwendet wurde, geschweige wie dieser am RFM12 angeschlossen wird. Eigentlich alle für mich verständlichen Beiträge (Code + Schaltplan) basieren auf einem Atmega8 und der ist soweit ich das beurteilen kann nicht Pinkompatibel, sodass ich Schalplan und Code selbst abändern müsste. Könnte mir vielleicht jemand einen Schaltplan posten, wie man das RFM12 an einen Atmega32 anschließt und den dafür funktionierenden Code? Das wäre echt super :) Gruss
Hallo! ' Atmega32 ' VDD -> VCC ' GND -> GND ' SDI -> MOSI (PB5, Pin 6) ' SDO -> MISO (PB6, Pin 7) ' SCK -> SCK (PB7, Pin 8) ' nSel -> SS (PB4, Pin 5) ' Fsk - > R 10k nach VDD Das sollte hoffentlich reichen. Gruß
Hey, danke das ist schon mal ein Anfang :) So wie ich das sehe ist das die Variante ohne dem externen Takt des RFM12. Also kann ich den Atmega32 mit internem Takt laufen lassen? Welchen Code kann ich dafür benutzen? Gruß
Ich hab mal zwei Fragen zu genau diesem Thema: Warum müssen MISO, MOSI, SCK und SS beim Mikrocontroller verwendet werden? wenn ich das in dem Code richtig sehe wird keine evtl. im Mikrocontroller vorhandene Hardware verwendet, sondern alles per Software nachgebildet. Warum dann die Bindung an diese 4 Pins? Ich kann doch jeden beliebigen Ein-/Ausgang dafür nutzen oder etwa nicht???? Und als zweites frage ich mich ob es denn möglich ist über ein so angeschlossenes Modul auch zu empfangen und wenn ja wie? woher weiß ich wann neue Daten empfangen wurden?
Du hast aber schon mal ins Datenblatt des Moduls und in das des Controllers geschaut? Und du hast dich auch informiert was SPI ist? Dann hast Du auch schon rausgefunden, dass das RFM12-Modul darüber z.B. seine Parameter bekommt. Ob Du das dann in Software-SPI oder gleich die eingebaute Hardware-SPI des Controllers nimmst, hängt von Deiner Anwendung und vom Controller ab. Nehmen wir mal an, Du hast einen Webserver mit dem ENC28J60, eine SD-Karte und ein RFM12-Modul. Z.B. weil Du Daten über das Netz übeträgst, sie auf der SD-Karte speicherst (also Datenlogger) und wenn etwas bestimmtes passiert, ein Signal via Funk sendest. Dann würde ich Dir empfehlen, das RFM12-Modul in Software-SPI zu machen, da es zwar seltener in Betrieb ist, aber auch genau dann sabbeln könnte, wenn gerade wichtige Daten reinkommen und der Zwischenpuffer deines Controllers eventuell nicht reicht alles zwischenzuspeichern. Kommunizieren tust Du immer über MISO (Master In - Slave Out), MOSI (Master Out - Slave In), Takt mit SCK (Clock) und mit wem Du reden möchtest sagst über ein Select-Pin (muß nicht unbedingt SS sein).
Ach verdammt. Ich hab immer in den Datenblättern meiner kleinen uCs gesucht. Und der Tiny2313 und Tiny13 haben scheinbar kein voll nutzbares SPI. Nur zum Programmieren. Jetzt verstehe ich das auch. Da macht dann eine bindung an die einzelnen Pins schon sinn. Nur den Vorteil von Software-SPI habe ich jetzt nicht verstanden. Eine Frage ist mir aber noch untergekommen. Alle Befehe an das RFM12-Modul und auch alle Befehele an andere Geräte die ich mir jetz angeschaut habe (z.B. ISP von uC) haben eine länge von 4 Byte. Ist das Standard oder Zufall?
Äh 4 Byte? Aus dem Kopf meine ich, es sind 16 Bits beim RFM12. Und das auch nicht für alle, beim Read-Status Befehl kann man auch ein paar mehr Bits senden um dann einen Teil der FIFO auszulesen.
>Nur den Vorteil von Software-SPI habe ich jetzt nicht verstanden. Die kannst Du mit 4 wahlfreien Pins machen, während die Hardware-SPI an die spezifischen Pins des Controllers gebunden ist. Oder wenn der Controller keine Hardware-SPI-Schnittstelle hat, dann kann man sie in Software nachbauen. http://www.uni-koblenz.de/~physik/informatik/MCU/SPI.pdf
Ich danke dir/euch vielmals. Damit dürften dann erst mal wieder alle Fragen bezüglich SPI geklärt sein. Zum Thema RFM12 habe ich allerdings wieder 1, 2 Fragen. Und zwar bei der Pin Definition im Datenblatt werde ich aus einigen Pins nicht schlau: 1. nINT - Interrupt input / VDI - Valid data indicator wozu dient dieser pin? ich finde nirgends eine antwort?! 2. nIRQ wird vom RFM12 auf low-pegel (0V) gezogen sobald daten im FIFO liegen richtig? und wann ist wieder high pegel? 3. der pin FSK/DATA/nFFS hat scheinbar mehrere Funktionen? a) was ist "FSK"? (google sagt Freiwillige Selbstkontrolle ^^) b) DATA: warum kommt hier recieved Data output? ich denke dafür gibts den FIFO und SDI(=MISO) c) nFFS: FIFO select?! gibts mehr als nur einen FIFO speicher? ich dachte das wäre ein 8bit langer speicher?! 4. DCLK/CFIL/FFIT verstehe ich gar nicht?! 5. CLK: hab ich kleine schwierigkeiten: ich habe das so verstanden, dass ich diesen Takt als Arbeitstakt für meinen uC nehmen kann. Andererseits aber muss der uC das Modul erst initialisieren. Wie kann dann also ein System starten, wenn beides sein gegenüber voraussetzt?! ich danke jedem der sich überhaupt die arbeit macht meine vermutlich doch sehr dummen Fragen durchzulesen.
Hallo, RFM12-infosuchender wrote: > 1. nINT - Interrupt input / VDI - Valid data indicator > wozu dient dieser pin? ich finde nirgends eine antwort?! > > 2. nIRQ wird vom RFM12 auf low-pegel (0V) gezogen sobald daten im FIFO > liegen richtig? und wann ist wieder high pegel? Es wird nur ein relativ kurzer Impuls ausgegeben, in irgendeinem der Datenblätter stand auch was zur Länge (1µs ???). > > 3. der pin FSK/DATA/nFFS hat scheinbar mehrere Funktionen? > a) was ist "FSK"? (google sagt Freiwillige Selbstkontrolle ^^) frequency shift keying -> modulation durch Frequenzumtastung Ist für die üblichen Anwendungen erstmal egal, muß dann aber über 10k an Betriebsspannung. > b) DATA: warum kommt hier recieved Data output? ich denke dafür gibts > den FIFO und SDI(=MISO) Es gibt mehrere Versionen, die Daten aus dem RFM12 zu bekommen, für auslesen per Kommando über SPI egal, bleibt frei. > c) nFFS: FIFO select?! gibts mehr als nur einen FIFO speicher? ich > dachte das wäre ein 8bit langer speicher?! > > 4. DCLK/CFIL/FFIT verstehe ich gar nicht?! Ignoriere sie vorerst. ;) > 5. CLK: hab ich kleine schwierigkeiten: ich habe das so verstanden, dass > ich diesen Takt als Arbeitstakt für meinen uC nehmen kann. Andererseits > aber muss der uC das Modul erst initialisieren. Wie kann dann also ein > System starten, wenn beides sein gegenüber voraussetzt?! Standardeinstellung der RFM ist 1MHz extern Clock und CLK aktiv. Damit kann es also erstmal losgehen. Gruß aus Berlin Michael
Die RFM Module kannste in die Tonne kicken - funktionieren oft nicht gescheit. Nimm doch einfach ein Bluetooth Class 1 Modul (kost ca 12 euro). Wenn du den µC mit dem Rechner kommunizieren lassen willst, brauchst du noch nichtmal einen zweiten Empfänger, da die meisten PCs eh schon bluetooth drinn haben. Die Reichweite ist auch größer und die Ansteuerung ist viel einfacher, da sich das Modul um die ganze Protokollkacke selber kümmert ;))
Hallo, naja, das kommt wohl a) auf die geplante Anwendung und b) auf die Erwartungen an. Beitrag "Sensoren mit RFM02/12, FOST02, HP03S (ASM)" Die 6 Sebsoren laufen jetzt seit einem Monat in der Gegend verteilt. Balkon, Keller und Gefrierfach sind die Extreme dabei. Kein der Module hat sich seitdem irgendwie daneben benommen. Welches Bluetooth-Modul empfiehlt Du, um z.B. mit einer CR2025 ein paar Monate lang Temperartur/feuchte aus dem Keller zu schicken (Batteriebetrieb, z.Z. 3,5µA Ruhestrom, ca. alle Minute für ca. 15ms 12mA beim Senden der Daten? Gruß aus Berlin Michael
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.