RFM69 wie fertige Library nutzen

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 :-)

Sorry, aber nun hat es auch mich voll erwischt und die Grippeerfahrung 
der Kollegen sagt "1 Woche unfähig zu irgendwas".