Ich habe mal eine Grundsatzfrage (also die Details sind nicht so relevant, nur gerade für mich aktuell): Es gibt ja jede Menge fertige und auch gute Libraries, nur sind die immer schon auf einen konkreten Einzelfall zugeschnitten. Ich habe jetzt das LPC845-BRK (btw.: Wo bekomme ich das draufgeflashte "Ursprungsprogramm" wieder her?) und will da ein RFM69 anschließen. Gegenstelle erstmal ein Raspi oder ESP32 oder ESP8266 zum Spielen. Da habe ich zugeschnittene Lösungen gefunden. Für den LPC845 nun aber nicht. Da ja sehr viele Sachen auf der gleichen Basis von LowPowerLabs aufbauen, wollte ich die auf den LPC845 "portieren". Aber da weiß ich irgendwie gar nicht, wie ich strukturiert anfangen soll. Das geht ja schon mit #include <Arduino.h> los. Da wird so viel Zeug inkludiert und ich weiß nicht, was für mich/meine Plattform davon relevant ist. Muß ich jetzt in den ganzen Dateien "nur" die Teile raussuchen, die wirklich RFM-relevant sind und den Rest mit meiner Plattform ersetzen? Dazu müßte ich ja den kompletten Chip verstanden haben und dann wäre ein kompletter Neuschrieb ja schon fast einfacher (würde ich natürlich nicht hinkriegen, meine aber das Prinzip und man hätte auch gleich seinen eigenen Stil drin).
" Aber da weiß ich irgendwie gar nicht, wie ich strukturiert anfangen soll." Wenn die Vorlagen zu verwirrend sind, könnte das Schreiben eigener Software die Lösung sein. Zu Beginn genügt es, wenn mit dem RFM69 die SPI-Kommunikation klappt, dann die Statusregister gelesen werden können und Du die Betriebsarten umschalten kannst. Später geht es an das Reagieren auf Ereignisse mit Hilfe der Flags der Statusregister. Das Datenblatt ist nicht überall wirklich exakt. Du wirst es "lieben" lernen. Ein RFM12 ist da wesentlich einfacher zu bedienen, die Steigerung wäre ein RFM70. MfG
:
Bearbeitet durch User
N'Abend schrieb: > Das geht ja > schon mit > #include <Arduino.h> > los. Da wird so viel Zeug inkludiert und ich weiß nicht, was für > mich/meine Plattform davon relevant ist. Das Arduino Include weglassen und sehen wo der Compiler meckert, die Funktionen muss man sich dann nachbauen. Es sind im wesentlichen Digital I/O, SPI 8-Bit read/write, Interrupthandling für einen Input und eine Timerfunktion um Zeitdifferenzen in ms messen zu können. Ich benutze den RFM69 Code von Lowpowerlabs mit einem LPC812/824 und mbed2, nur der 845 ist zu neu und es gibt keine fertigen Code für dieses Target. Den LPC845 möchte ich auch noch in mbed2 einbauen, aber im Moment komme ich nicht dazu. Christian S. schrieb: > Ein RFM12 ist da wesentlich einfacher zu bedienen, die Steigerung wäre > ein RFM70. sehe ich anders, der RFM69 hat einen grösseren Fifo und das macht einiges einfacher. Die Initialiserung und das Senden/Empfangen ist auch alles in der LPL Lib drin. Das kann man in Details noch verbessern aber man hat einen funktionierenden Anfang.
Ich habe es befürchtet. Also werde ich es am Wochenende mal mit Fleißarbeit versuchen. Also mal mit RFM69.h und RFM69.cpp anfangen und "fremden" Code verfolgen. Das geht mit Eclipse (F3) ja meistens ganz gut. In der Tat scheinen es auf den ersten Blick genau die von Johannes genannten Eckdaten zu sein. Ich werde mal versuchen, dann eine interfaces.h und interfaces.c o.ä. zu schreiben und dort die "fehlenden" Sachen (Funktionen, macros und defines) für meine Architektur unterzubringen. Es fallen ja auch viele Sachen weg wie flash, OTA usw..
Versuch 1, nun ja, hat nicht so gefruchtet. Ich bin da von einem define und ifdef zum nächsten gehüpft und weiß so langsam gar nichts mehr. Was gehört zu Arduino, was gehört zur RFM-Lib usw.. Dann noch C++ dazu, wo ich doch gerade mal mit C so halbwegs unfallfrei über die Straße komme. Bischen viel auf einmal. Also Strategiewechsel. Ich glaube herausgefunden zu haben, daß die Libs (Arduino und RFM) so ziemlich jede Variante abdecken (mit #ifdef satt usw.) und ich daher nicht durchblicke. Da ich nur eine Plattform (im Moment LPC845) umsetzen will wird mein nächster Versuch sein, alles aus den RFM-Libs rauszuschmeißen und nur den Teil nachzubilden, den ich jetzt brauche. Das wird allerdings dazu führen, daß bei einem Update der Lib die Diffs in "meiner" Version nachgepflegt werden müssen. Also keine Kapselung aller Änderungen in einer interfaces .h und .c. Spricht da grundsätzlich was gegen? Wenn ich später mehr Durchblick habe, kann ich das ja wieder rückgängig machen. Denn vom RFM will ich auch langsam etwas verstehen und nicht einfach irgendwas kopieren. Zusammenhänge Frequenzhub, Bitrate usw. kenne ich so ungefähr, nur nicht bei diesem Chip. Und ein paar Erfolgsergebnisse fördern halt die Motivation :-)
Hallo, konntest Du anhand der vorhandenen Libs so etwas wie einen Ablaufplan erstellen, unter welchem Betriebszustand was nacheinander eingestellt oder gelesen werden muß? MfG
Sorry, aber nun hat es auch mich voll erwischt und die Grippeerfahrung der Kollegen sagt "1 Woche unfähig zu irgendwas".
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.