Hallo allerseits ! Aus reinem Zeitvertreib habe ich mich einmal etwas mit dem RFM02-Modul befasst. Dabei ist nebenbei ein - wie ich denke - recht brauchbares Beispiel für eine Software in C für einen MSP430 heraus gekommen. Das Modul ist recht schlecht dokumentiert, aber ich denke dass aus meinem Beispiel viele Fragen beantwortet werden. Als ehemaliger professioneller Hard- und Softwareentwickler biete ich auch gerne einen eMail-Support an. Wie Ihr alle wisst, ist die Bastelei im Mikrocontrollerbereich sehr anspruchsvoll und kostet auch u.a. viel Zeit. Leider scheint meine Zeit als Entwickler an der 1. Front tatsächlich vorbei zu sein. Gerne bin ich aber bereit, nachfolgende Generationen zu unterstützen. Wer mich im Gegenzug dafür bezüglich meiner Kosten unterstützen möchte, dem sei gerne die Möglichkeit angeboten, dies durch eine freiwillige Spende nach eigenem Ermessen zu tun: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=S2ZGS4SSU8VU6 Ich habe heute das Beispiel nochmals gesichtet und einige Diskrepanzen zwischen Kommentierung und tatsächlicher Programmierung korrigiert. Der Grund dafür besteht darin, dass ich zunächst einen MSP430F2013 verwendete, wegen Befehlsproblemen des Moduls aber dann auf mein größeres EVA-Board mit einem MSP430F169 portieren musste, um dort erst mal die Probleme in den Griff zu bekommen. Für Fragen zur Software oder den (Profi-)Tools bin ich jederzeit per eMail kontaktierbar. Hoffe ich konnte helfen. Gruß
Hallo, nicht schlecht!! Aber wie sieht es mit Hardware-SPI aus? Gibt es Erfahrungen. Ich bin grad dabei mit einem ATMEL ATMEGA16 via Hardware-SPI das Modul zu steuern. Das umfasst auch das senden von Daten über die Hardware-SPI Schnittstelle, was ja laut Datenblatt möglich sein soll. Einzig das lesen des Status-Registers erfolgt mit Soft-SPI. Die Toggelei über den FSK-Pin wollte ich vermeiden. Gruß Karsten
Warum ein RFM02 extern anbinden? Den MSP gibt es als CC Version, da ist schon alles on chip. TI bietet auch reichlich gute app-notes für die eigenen ISM chips und µCs.
Karsten Brandt schrieb: > Hallo, > > nicht schlecht!! > > Aber wie sieht es mit Hardware-SPI aus? Gibt es Erfahrungen. > Ich bin grad dabei mit einem ATMEL ATMEGA16 via Hardware-SPI das Modul > zu steuern. Das umfasst auch das senden von Daten über die Hardware-SPI > Schnittstelle, was ja laut Datenblatt möglich sein soll. Einzig das > lesen des Status-Registers erfolgt mit Soft-SPI. Die Toggelei über den > FSK-Pin wollte ich vermeiden. Hallo Karsten ! Geh mal davon aus, dass in der Herstellerfirma dieses Moduls, die Abteilung, die die Doku schreibt nichts mit der Abteilung zu tun hat, die das Modul entwickelt. Daraus folgt, dass die Doku-Abteilung mehr oder weniger nach eigenem Gutdünken eine Dokumentation schreibt. Bei General Motors in Rüsselsheim läuft das nämlich auch nicht anders. Die Programmierer schreiben die Diagnosesoftware und die Prüfanleitungsabteilung schreibt die Prüfanleitungen dazu. Funktioniert die Schnittstelle ( Kommunikation ) zwischen den Abteilungen nicht, macht jeder einfach wie er denkt. In der Doku steht: "This command indicate that the following data on SDI pin is to be transmitted, the transmission stops if nSel return to hi." Das hat sich vielleicht die Doku-Abteilung so vorgestellt, das muss aber nicht so sein bzw. ist sehr zweifelhaft, dass das so ist. Zum einen ist das Kommando zu kurz, d.h. nur 8 Bit lang. Alle anderen Kommandos an die SPI-Schnittstelle sind 16-Bit-Kommandos, außer das PowerSetting-Kommando. Dieses muss ich aber so behandeln, als wäre es ein 16Bit-Kommando... siehe rfm02_trans_init.h ... #define CONFIG_RF_PWR_CMD 0x00B0 #define RF_PWR_8DBM 0x00 // Pmax // ... // ... #define RF_PWR_1DBM 0x07 // Pmin Ich schätze mal, dass das Modul über die SPI-Schnittstelle konfiguriert wird und Sendedaten über den FSK-Port zugeführt werden müssen. Deshalb hat das Ding 2 Schnittstellen, ansonsten könnte man sich eine ersparen. Das Transmit-Command könnte möglicherweise auch nur dafür gedacht sein, das Modul aus dem Sleep-Mode in Sendebereitschaft zu bringen ... ? Dafür spräche nämlich auch die Erläuterung zu den beiden Bits a0 und a1 im PowerMangementCommand: a1: Crystal oscillator and synthesizer are enabled by Data transmit Command and disable by Sleep command. a0: Power amplifier is enabled by Data transmit Command and disable by Sleep command. Also würde ich mich nicht darauf versteifen, über die SPI-Schnittstelle Sendedaten zuführen zu können. Das hat sich vielleicht die chinesische Dokuabteilung einfach nur so vorgestellt.
> Einzig das lesen des Status-Registers erfolgt mit Soft-SPI. Die Toggelei > über den FSK-Pin wollte ich vermeiden. > Hallo Karsten, so, nun zu Deiner 2. Frage/Aussage. Das Lesen des Status-Registers ... hmmmm, sehr interessant .... Von wo willst Du das denn lesen ? Das Modul hat keinen SDO ( Serial Data Out der SPI (Serial Peripheral Interface) ) Port ... Als Ausgänge gibt es lediglich den nIRQ, der kein nIRQ ist, sondern ein high-aktiver DATACLK, und dann halt noch den optional aktivierbaren CLK-Ausgang um die angeschlossene MCU zu takten, sofern die ihren Takt nicht selbst erzeugen kann oder noch einen zusätzlichen Quarz bräuchte. Falls Du es schaffst irgendwie von irgendwo an diesem Modul ein Statusregister zu lesen, sag mir auf jeden Fall Bescheid.... ;-))) Und bei der Gelegenheit, kannst Du mich dann auch bitte darüber aufklären, welche Informationen in diesem Statusregister enthalten sind. Die Doku-Abteilung der Chinesen schweigt sich nämlich auch darüber aus ... Oder das ist vielleicht chinesischer Humor, wer weiß ... Oder vielleicht eine Zermürbungsstrategie für die westliche Welt, um deren Entwickler in den Wahnsinn zu treiben ... Was ist denn an dem FSK Pin so schlimm ? Das Funktiönchen, um dort Daten rein zu schieben, hast Du mit meinem Beispiel-Code und die Übertragungsgeschwindigkeit stellste in der Funktion für die Modulinitialisierung über das entsprechende Define ein.... und fertig is. Brauchste halt nur noch die Funktion RFM02_CMD_Transmit_DataByte(char); aufzurufen und die gewünschten Daten als Byte an diese zu übergeben... Fragen ? Gruß Jochen
Hallo Funky, ja, Texas Instruments ist schon der Maßstab. Sehe ich auch so. Zum einen was die Doku betrifft, und zum anderen das den Support betrifft. Und dann natürlich die ganzen Application-Notes und Code-Beispiele. Die geben sich wirklich Mühe. Das muss man schon anerkennen. Ich habe einmal ein 2-jähriges Projekt auf einem MSP programmiert, damals ... vor langer langer Zeit ... Da Texas Instruments auch schon extrem bemüht uns alle erdenkliche Unterstützung zu angedeihen zu lassen. Das Gerät ist von Roche Diagnostics und erst vor wenigen Jahren auf den Markt gekommen: CoaguCheck XS, kannst ja mal nachschauen. Herzstück ist dort ein MSP430F149. Gruß
Karsten Brandt schrieb: > Super Tipp, Danke!!! > > Habe gleich das ez430 chronos kit bestellt. Hallo Karsten ! ???? Versteh ich nicht ... ???? ??? Was für ein Tipp ? Von wem ???? Oder meinst Du die Erwähnung meines sog. "EVA-Boards" ? Das ist natürlich selbst gebastelt, mit einem MSP430F169-Header-Board von Olimex. Die Software für das rfm02-Modul ändert sich dadurch aber nicht wirklich. Mit welchem Entwicklungs-Setup arbeites Du denn (bis jetzt) ??? Gruß
Hallo Jungs ! Ach ja, bevor ich es vergesse ... Dafür, dass ich der Branche noch etwas schuldig bin, verrate ich jedem auf eMail-Anfrage ( --> Quellcode ) wie man an wirkliche Profi-Tools kommt .... als Vollversion !!!! ... also nicht so ein IAR EWB-Light-Teil mit 4k-Begrenzung, das so ein paar gerissene Bayern um den ansonsten freigen gcc-Compiler als Oberfläche drumrum gestrickt haben .... ... und dann 10.000 Euro pro Lizens dafür haben wollen ... nee, nee, neeeeeeeee .... so soll das noch enden .... ;-)))))))))))
>Hallo Karsten ! >???? Versteh ich nicht ... ???? >??? Was für ein Tipp ? Von wem ???? Das bezieht sich auf den beitrag von funky weiter oben. dort macht er einen hinweis zu der MSP-Serie mit integriertem RF-Modul. Das Kit ez430 chronos ist von TI und enthält einen CC430 MSP(der mit funk on board). >Hallo Karsten, >so, nun zu Deiner 2. Frage/Aussage. Der auf dem RFM02 verbaute Chip ist von Silicon Labs und hört auf den Namen Si4021. Im RFM02 ist der Si4420 verbaut. In dem Datenblatt zum Si4021 findest du die beschreibung zum auslesen des statusregisters. Insgesamt ist die Dokumentation von Silicon Labs sehr hilfreich, insbesondere weil alles vernünftig lesbar ist. vergleichst du die Datenblätter vin silicon labs mit denen von HopeRF so werden doch ähnlichkeiten sichtbar :-) > Mit welchem Entwicklungs-Setup arbeites Du denn (bis jetzt) ??? Ich habe das RFM EVAL-Board (Best.Nr. 810 046)und dem RFM-Adapter (Best.Nr. 810 056) von Pollin. Beides ist durch ein langes 40-poliges Kabel über den Expansionsport verbunden, so dass ein Abstand von ca. 20-30cm zwischen Sender und Empfänger erreicht wird. RFM02 und RFM12 sind an einem SPI-Bus. Die anderen Signale sind natürlich an verschiedene Pins des ATMEGA16 gelegt. Programmierumgebung ist das AVR-Studio in Version 5. Bin froh, wenn überhaupt mal was übertragen wird. Deine Software ist sehr gut strukturiert und kommentiert. Das macht das Verständnis einfacher. Gruß Karsten Karsten
Karsten Brandt schrieb: > In dem Datenblatt zum Si4021 findest du die beschreibung zum auslesen > des statusregisters. Insgesamt ist die Dokumentation von Silicon Labs > sehr hilfreich, insbesondere weil alles vernünftig lesbar ist. Hallo Karsten ! Ahhhh, ja, das sieht schon anders aus !!!!! Das muss ich dann morgen einmal genau studieren. Dort steht dann auch, dass das Statusregister über den nIRQ-Pin ausgelesen werden kann. Ok, keine Frage, dann macht dieser Befehl auch Sinn. Was die Entwicklungs-Tool-Chain betrifft arbeite ich mit dem marktführenden Tool von Rowley Crossworks, for MSP430, sowie for AVR !!! (Vollversion 2.03) (Wie man an die ran kommt, kann ich hier natürlich nicht offen posten...) Die in Verbindung mit einem Olimex JTAG-Programmer und einen MSP430 hinten dran bzw. einen AVR-Controller, und dann flutscht das ... Meinen Code betreffend, ist das das Mindeste, was ich codemäßig so vom Stapel lasse. Ich habe einige Projekte für große Firmen programmiert, da werden ganz andere Maßstäbe angelegt. Und, wenn man selbst mal ein halbes Jahr später auf die Idee kommt, irgendwie nochmal etwas dazu oder umzuprogrammieren versteht man ohne ausführliche Kommentierung den eigenen Quellcode nicht mehr. Da schreib ich doch besser gleich einen vernünftigen Kommentar nebendran, bevor ich an meinen eigenen Programmier-Orgasmen dann irgendwann scheitere. Gut, das hier ist nich wirklich wild, da gibt es noch ganz andere Sachen, wie z.B. das CoaguCheck XS von Roche Diagnostics .... ( ohne RTOS programmiert bzw. eigenes OS dazu geschrieben... mei war das ein Ding ...) ABER: Hat um eine Dezimalstelle genauere Messwerte als sonstige auf dem Markt befindliche Blutgerinnungsmessgeräte geliefert ... Gruß J.
Das avr-studio mit dragon funktioniert super. Das Problem mit den rfm-modulen ist,dass man nicht messen kann, ob und was gesendet wird. Scope an die Antenne halten geht eben nicht. Da ist ein vernünftiges code- Beispiel schon besser. Die signalleitungen funktionieren soweit. Eigentlich wollte ich mit den Modulen nicht so tiefgreifend beschäftigen. Es wurde nur eine lösunggesucht um Sensordaten drahtlos von a nach b zu übertragen. Bin nur zufällig über diese Module gestolpert. Eigentlich sind diese schon kompliziert, zumal der Support zu wünschen lässt.die Module habe ich nun mal. Also verwende ich diese auch. Der Vorschlag mit den cc430 von Texas Instruments scheint vielversrechend zu sein. Es gibt bei ti auch jede menge app notes. Sind zwar etwas teuerer als die avrs, aber es ist alles integriert. Sensor dran und fertig. Platz wird auch noch gespart, da ein Controller entfällt.
Jochen Schröder schrieb: > Als ehemaliger professioneller Hard- und Softwareentwickler biete ich > auch gerne einen eMail-Support an. Was soll das denn heissen? Jmd der sowas hinbekommt
Hallo Karsten, Karsten Brandt schrieb: > Das Problem mit den rfm-modulen ist,dass man nicht messen kann, ob und > was gesendet wird. Scope an die Antenne halten geht eben nicht. Da ist > ein vernünftiges code- Beispiel schon besser. Doch, das geht... mit einem Frequenzzähler. Sendest Du dann nämlich permanent ein 0xFF ist die Sendefrequenz die eingestellte Frequenz + dem eingestellten Hub ( deviation ). Sendest Du permanent 0x00 ... genauso ... nur ... - dem Hub. Bei mir funktioniert das einwandfrei... > ..die Module habe ich nun mal. Also verwende ich diese auch. So ist richtig ! Musst nicht meinen, bei dem CC430 würde alles viel einfacher sein. Da kannste schon am Setup scheitern bzw. Dich tiefer mit der Materie befassen. Sensor dran und fertig läuft auf keinen Fall. Schau Dir nur mal in meinem Beispiel die Ini-Fkt. für die SPI-Schnittstelle eines ..F2013 an. Glücklicherweise braucht man die nicht unbedingt, könnte sie wohl aber auch verwenden, sofern man das Setup passend hinbekommt.
Was für einen Frequenzzähler mit welchen Spezifikationen benötige ich? Wie wird die Messung genau durchgeführt ? Einfach nur am Antennenausgang oder an welcher Stelle? Gruß Karsten
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.