Hallo... weiterhin ein Frohes Weihnachtsfest !!! ich habe jetzt angefangen mit den Funkmodulen RFM12 und RFM12BP zu arbeiten. Alle programmieren die Dinger in C und keiner in Assembler, oder gibt es doch jemanden ? Ansonsten muss ich mich halt alleine durchkämpfen und hab gleich mal ein paar Fragen. 1. die Pins: SDI , SDO , SCK , nSEL und nRES sind Pflicht, alle anderen sind optional. Ist das richtig ? 2. Initialisierung: laut Datenblatt können 17 verschieden Einstellungen vorgenommen werden, welche davon müssen gemacht werden ? Und gibt es eine Reihenfolge in der sie gemacht werden sollten ? 3. RFM12BP hat einen 50-Ohm-Antennenanschluss (ist klar), aber was ist eine Differentialantenne (RFM 1, 2 und 12) ? 4. welche Flags enthält das Status-Register ? 5. was ist der crystal load capacitor ? Gruss Uwe
Ich habe das hier als Basis verwendet, die Einstellung dort funktionieren prima: http://www.das-labor.org/wiki/RFM12_library Poste doch dann auch Deinen Code in ASM, ich bräuchte das Ganze nämlich auch im Assembler...
Uwe O. schrieb: > Alle programmieren die Dinger in C und keiner in Assembler, > oder gibt es doch jemanden ? Ich habe hier ein Projekt rumfliegen, wo ich den RFM12 verwende. Da ich die Atmels idR in Assembler programmiere, ist das Projekt in Assembler geschrieben. Falls Interesse besteht, sehe ich mal nach, was ich davon finde. Gruss aus Berlin Elux
Servus! Du hast Glück, vor einigen Jahren habe ich mich mal daran gemacht die bidirektionale RS232 Funkbrücke mit RFM12 von Benedikt K. "händisch" nach AVR-Assembler zu "compilieren". Danke an dieser Stelle nochmals an ihn! Als kleine aber feine Erweiterung hab ich einen Bootloader dazuprogrammiert, welcher aber durch einen bis jetzt nicht gefundenen(/gesuchten :)) Fehler nicht richtig funktioniert. Würde mich unheimlich freuen, wenn da jemand draufkommt! Die Kommentarzeilen mit ;--------------- sind verdächtig. ;) Ansonsten sollte das ganze mit einer Gegenstelle nach den Bauplänen: Beitrag "bidirektionale RS232 Funkbrücke mit RFM12" gut funktionieren. Viel Spaß damit, läuft sogar auf einem kleinen ATTiny13. lG & schöne Feiertage, Daniel A. Maierhofer
Danke für die Antworten. Hallo "elux" es besteht Interesse. Verschiedene Programmbeispiele sind immer gut für Neueinsteiger, wenn sie gut kommentiert sind. Grüsse aus Göteborg Uwe
Uwe O. schrieb: > Hallo... weiterhin ein Frohes Weihnachtsfest !!! > > ich habe jetzt angefangen mit den Funkmodulen RFM12 und RFM12BP zu > arbeiten. Alle programmieren die Dinger in C und keiner in Assembler, > oder gibt es doch jemanden ? Ansonsten muss ich mich halt alleine > durchkämpfen und hab gleich mal ein paar Fragen. > 1. > 2. > 3. > 4. > 5. welche der 5 Fragen sind denn assembler-spezifisch bzw. können nicht aus bestehenden Datenblättern etc. herausgelesen werden?
Hallo Buchstaben Verwechsler... ich habe deshalb auf Assembler hingewiesen, in der Hoffnung, dass jemand ein einfaches "Einsteigerprogramm" liegen hat. Die Fragen selber haben nichts damit zu tun. Datenblätter können fehlerhaft sein (z.B. das von Pollin). Dass ist für einen Anfänger wie mich sehr irritierend. Woher soll ich wissen was richtig ist. Ich frage da lieber Leute die es wissen. Das RFM12BP hat eine Sendeleistung von 27dBm = 500mW, aber in welchen Stufen ist die einstellbar, steht nicht im Datenblatt (auch nicht bei HopeRF). Gruss Uwe
Uwe O. schrieb: > Hallo "elux" es besteht Interesse. Verschiedene > Programmbeispiele sind immer gut für Neueinsteiger, wenn sie gut > kommentiert sind. Hallo Uwe, ich habe gesucht und bin fündig geworden...Anbei die Files (wie gewünscht in Assembler) aus einem Projekt in einem frühen Stadium (Fernbedienung einer Standheizung in meinem Audi mit einer TI Chronos - von daher der Name der Files...). In den angehängten Files geht es um Tests der Kommunikation Chronos <-> RFM12; mit Ausgabe der empfangenen Strings über eine UART-seriell Brücke (PL2303) auf einen PC zwecks Abgleich der Register im CC430 und RFM. Ich hatte damit auch Reichweitentests gemacht. Zunächst hatte ich einen Mega8 am Wickel wg. Hardware - SPI, das funktionierte aber nicht so hipp (lange gesucht: offenbar macht der SPI beim RFM Mist), so habe ich einen Tiny44 genommen (weil ich die da hatte...) und auf Soft-SPI umgebaut. Funktionierte ganz gut. Die verwendete Schaltung/Portbelegungen/Quarzfrequenzen/Baudraten und so ergeben sich aus der Datei "definitionen.inc". Vielleicht hilfts Dir ja...;-) "kommentiert": Naja, ich hoffe, Du kommst mit meinem Stil klar ;-) Gruss aus Berlin Elux
Hallo Elux, ich habe mich ein paar Tage ausführlich mit Deinem Programm beschäftigt. Es ist sehr übersichtlich, gut kommentiert und gut zu "verstehen". SUPER gemacht, gefällt mir und hilft mir auch beim Einstieg ! DANKE nach Berlin. Zwei Fragen habe ich da noch. 1. Das mit dem "Soft-SPI", bringt das Vorteile gegenüber dem "normalen SPI" ? 2. Den Ziehkondensator gibst Du mit 11,5 pF an. Ist dass nur geschätzt, oder hast Du da was gemessen ? Gruss Uwe
Uwe O. schrieb: > Zwei Fragen habe ich da noch. > 1. Das mit dem "Soft-SPI", bringt das Vorteile gegenüber dem "normalen > SPI" ? > > 2. Den Ziehkondensator gibst Du mit 11,5 pF an. Ist dass nur geschätzt, > oder hast Du da was gemessen ? Zunächst: Aber bitte doch ;-) zu 1. Ja, ich hatte (wie oben schon geschrieben) zunächst einen Mega 8 oder 88 (weiss ich nicht mehr so genau) mit Hard-SPI im Einsatz und hatte das Problem, das nach dem ersten empfangenen Byte (also ab dem 2.Byte) Bits verschoben/invertiert/gelöscht waren. Ich habe lange nach dem Problem gesucht, mit den Einstellungen gespielt etc. ohne einen wirklichen Erfolg. Viele haben ja seinerzeit mit dem RFM gespielt und KEINER hatte dieses Problem, von daher habe ich erst einmal "vor der eigenen Haustür gefegt"... Zumal ich ja nicht wußte, wer hier den Mist baut: die Chronos oder der RFM...Eine Zeit lang hatte ich die Chronos im Verdacht (da es auf dem SPI eigendlich OK aussah [mit dem LA von Michael_U]), war es aber letztlich nicht. Irgendwann ist mir aufgefallen, das aber auch wirklich ALLE den Code von Benedikt K. hier benutzt hatten -> und er benutzte Soft-SPI wg. Kompatibilität. Offenbar ist das Timing bei Soft-SPI unkritischer oder/und ich hatte einen "Sch..."-RFM erwischt. Nachdem ich von Hard-SPI auf Soft-SPI umgebaut hatte, ging es problemlos. Von daher blieb es also bei Soft-SPI und da ich so viele PINs wie beim '88 für den vorgesehenen Zweck nicht brauchte, zog Alles auf einen Tiny 44 um, der reichte auch und war auch vorhanden... zu 2. Ehrlich? Ich weiss es nicht mehr. Ich glaube mich zu erinnern, daß es seinerzeit eine Diskusion hier im Forum darüber gab und nach dem üblichen Blahblah habe ich aufgrund für mich nachvollziehbarer Argumente und nach den Empfehlungen des eigendlichen Datenblattes (der Chip im RFM ist bekannt...) diesen Wert gewählt. Gemessen habe ich da Nichts. Gruss aus Berlin Elux
:
Bearbeitet durch User
Auch von mir herzlichen Dank an Daniel und Rainer. Ich hatte auch schon eine Weile nach Assembler Beispielen gesucht. herrmueller
Moment..... STOP.... HALT... In jedem 3. Beitrag jedes zweiten Threads hier im Forum wird doch gelehrt, dass selbst kleine µC in C programmiert werden sollen, weil "die Compiler so gut sind, dass man es händisch in ASM nicht besser machen kann"! Also, warum macht ihr es extra schlecht ;-) SCNR Danke für die Beispiele.
Ich schrieb: > Also, warum macht ihr es extra schlecht ;-) vermutlich aus 3 Gründen: 1. könnten dann die selbsternannten Scholaren ja den moralischen Zeigefinger nicht erheben und wären somit höchst unzufrieden. 2. weil ich ein schlechter Mensch bin (Wie der Herre...). 3. Wer sofort perfekt ist, kann sich nicht mehr verbessern. Wenn keine Verbesserung erkennbar ist, ist eine schlechte Bewertung die Folge. Wer schlecht bewertet wurde, fliegt raus. OK? Gruss aus Berlin Elux
Extra schlecht mache ich nichts. Ich habe ein paar Platinen (Module) machen lassen, die neben dem RFM12 einen ATMega8/168/328 beherbergen. Ich habe nur die Idee für ein etwas intelligenteres Modul umgesetzt. Prinzipiell kann ein RFM70 wahrscheinlich alles besser; nur: Hier bei mir laufen die RFM12 ganz gut. Mit so einem Modul kann man über UART auch die nächste Instanz (irgendeinen AVR, der am RFM12-Modul hängt) flashen, ohne das man dazu aufstehen muß. AUCH die vorherige Instanz, das Modul selbst läßt sich natürlich auch selbst mit der neuesten ( g ) Firmware versehen. Mir war die Kombination: Universal-Modul, das in Assembler beschrieben ist, und echtem Arbeitstier AVR, das an einem UART des Universal-Moduls hängt, um auch diesen "externen AVR" programmieren zu können, immer wichtig. Was man dazu braucht, ist ein RFM12-Funk-Bootloader, der fähig ist, zu responsen, also zu sagen, ob er einen Command oder eine Programpage kapiert hat oder nicht. Das alles paßt incl. UART-Treiber in die THIRDBOOTPAGE eines ATMega168. Ohne Response kann man mittels broadcast bis zu 32 Module (und mehr) gleichzeitig flashen. Ohne Response kann man das auch auf 512 Byte hinkriegen, und da ist noch nicht viel optimiert. Paßt also in die meisten AVR-Kisten. "Mit" Response muß man noch TX beim RFM12 machen, da wird es eng. Noch zu machen, aber man muß dann C und Assembler sehr schlau verquicken. Warum also nicht gleich in Assembler machen. Fehlprogrammierungen (über Funk bei AVR Mega8, Mega168,Mega168P,Mega328) gibt es seit der Response-Funktion in meinem Universalmodul und dem nachgeschalteten AVR (der natürlich auch noch seine Zeit zum Response bracuht) keine einzige mehr. Ich verfolge übrigens vorerst keine kommerziellen Interessen, keine Sorge g. Bin noch mit dem STM32-Scheiß beschäftigt; aber das Netz aus 2 unabhängigen RFM12-Netzen läuft auch auf dem inzwischen, und zwar schnell ächz Also, es gibt Leute, die RFM12-Zeug in Assembler programmieren, keine Sorge ;)
Hi ruepel, Ich habe auch schon übers Avr Programmieren per Rfm12 nachgedacht. Aber per EEPROM und EEPROM-Bootloader im AVR. Funke die Daten in kleinen Paketen mit Crc und (N)ACK rüber, die werden im EEPROM abgelegt, dann Reset und Bootloader flasht.
Ich würde ganz gerne noch mal auf das ursprüngliche Thema zurückkommen. Es gibt da eine Zeile im Programm, die lautet: .equ RFM_PW_SET = (0x9800|(RFM12_POWER&7)|((RFM_SHIFT&15)<<4)) <<4 - bedeutet, dass der Wert ab dem bit4 dazu addiert wird, aber wie ist die korrekte Definition dieser Operation ? was bedeuten &7 bzw. &15 - ich habe die Werte geändert und auch ganz weggelassen, aber das Ergebnis ist immer das selbe ? Und letzte Frage, wann genau beginnt das Modul mit dem Senden und wie schnell ist da die Übertragungsrate ? Gruss Uwe
Vielleicht hilft der Beitrag weiter: http://www.mikrocontroller-elektronik.de/funkmodul-programmierung-rfm12b-rn-mikrofunk/ Die Beispiele sind zwar in Bascom geschrieben, aber läßt sich leicht in C umsetzen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.