Lib für NTF24L01+, SE8R01, RFM70 usw.

[Torsten C. (torsten_c)]

Hallo zusammen,

für Schüler-AGs auf ATMega328p und für mich auf STM32 möchte ich gern 
eine schlanke Lib (Beispiel siehe Gist[2]) erstellen. Welche ICs bzw. 
Module - außer der im Betreff genannten - haben ähnliche Register, so 
dass eine gemeinsame Lib lohnt?

Welche weiteren ICs gehören also in diese weitgehend Register-kompatible 
Kategorie?
Z.B. XN297, LT8900, Si24R1? Gibt es schon irgendwo eine Übersicht?

Falls nein: Wollen wir eine Wiki-Seite dazu anlegen?

Es gibt nur wenige Unterschiede, siehe Bild. Sind die vollständig?

In den Datenblättern[1] des BK2421 (RFM70) und des BK2423 ist eine 
"Registerbank 1" beschrieben (Kapitel "7.2 Register Bank 1").

Es ist nirgens beschrieben, dass diese Registerbank beim SE8R01 
vorhanden ist, oder gar initialisiert werden muss. Allerdings ist laut 
SE8R01-Datenblatt im MSBit des STATUS-Registers (Adresse 07h) die 
ausgewählte Registerbank auslesbar.

Sofonov Evgeniy initialisiert in "void se8r01_calibration()"
ab Zeile 164 trotzdem die "Registerbank 1":
https://github.com/Sofcom/NRF24Lmodule-SE8R01/blob/master/funktioner.ino#L164

Ist beim SE8R01 eine Initialisierung der "Registerbank 1" nötig?
Oder nicht?

Links zu den Datenblättern und zum Gist:
[1] https://github.com/TorstenC/Notizblog/wiki/RF24-Remote-Control-Lib
[2] https://gist.github.com/TorstenC/7c02b06953d4382648d4ecbc03997076

VG Torsten

[Mehmet K. (mkmk)]

Meine Kenntnisse beschraenken sich nur auf den nRF24L01, weshalb ich zum 
Projekt nicht viel beisteuern könnte. Aber Deine Idee finde ich gut.

Nur: Ich habe Deinen Code auf Gist studiert und hatte damit etwas Mühe.
Das Ganze waere viel leserlicher, wenn Du Konstanden oder Defines 
benutzen würdest, anstelle jede kryptische Zeile nachtraeglich zu 
kommentieren.

SPI_SendSync((uint8_t*)"\x21\x00", 2); // EN_AA = 0 (Disable ‘Auto Acknowledgment’ )

// besser waere:
SPI_SendSync(EN_AA, 0);

Kommentare könnte man dann im Header-File einfliessen lassen.
Aber nicht übertreiben :)

SPDR = *bytes++; // Sende Daten und erhöhe Pointer

Jemand der weiss, was ein Pointer ist, bedarf nicht dieses Kommentares. 
Jemandem, der nicht weiss, was ein Pointer ist, wird auch dieser 
Kommentar nichts nützen.

[Zweifler (Gast)]

Kennst Du das hier:

http://www.airspayce.com/mikem/arduino/RadioHead/

[Torsten C. (torsten_c)]

Zweifler schrieb:
> Kennst Du das hier:
Die Suche sagt:
> Es wurden keine mit deiner Suchanfrage
> - SE8R01 site:airspayce.com - bzw.
> - XN297 site:airspayce.com -
> übereinstimmenden Dokumente gefunden

Der Link hat mir leider nicht weiter geholfen. Trotzdem danke.

Mehmet K. schrieb:
> Das Ganze wäre viel leserlicher, wenn Du Konstanten oder Defines
> benutzen würdest, anstelle jede kryptische Zeile nachtraeglich zu
> kommentieren.

An einigen Stellen bin ich genau diesen Weg gegangen.

Defines sind in C weit verbreitet, wobei ich den AG-Teilnehmern lieber 
enums statt #defines nahelegen würde. In C++ werden die enums dann sogar 
Typ-sicher.

Der Gedanke war: Die AG-Teilnehmer sollen sich ein Datenblatt daneben 
legen und anhand des Datenblatts den Code verstehen und nicht noch 
verstehen müssen, dass in einem dritten oder vierten Dokumant irgendwas 
'magisches' passiert, was erklärt werden muss.

Wie man es macht, man macht es falsch. Hmmm …
Danke jedenfalls für Deinen Kommentar, Mehmet! :-)

#defines oder enums machen Sinn, wenn "Zahlen" an vielen Stellen im 
Programm vorkommen.
Der Gedanke war, dass nicht erklärt werden werden muss, wie man vom 
Datenblatt über eine Header-Datei zu dem Befehl kommt. Also: Jede "Zahl" 
möglichst nur einmal in genau einer Lib-Funktion benutzen und dort 
einmal erklären.

Ob der Gedanke aber gut war? Eine essentielle Frage.
Ich bespreche die Frage mal mit dem AG-Leiter, was er pädagogisch für 
sinnvoller hält. Es sind ja Beispiele für beide Varianten vorhanden.

SPDR = *bytes++; // Sende Daten und erhöhe Pointer

> Jemand der weiss, was ein Pointer ist, bedarf nicht dieses Kommentares.

Stell Dir vor, der Code wird per Beamer / Overhead-Projektor Zeile für 
Zeile erklärt. Der AG-Leiter erklärt an dieser Stelle genau das, was im 
Kommentar steht, vielleicht noch zusätzlich mit Kreide an der Tafel.

[Mehmet K. (mkmk)]

Okay, wenn der paedagogische Aspekt im Vordergrund steht, dann waere es 
vielleicht besser, zu der Pointer-Geschichte entsprechende Klammern zu 
setzen.
Weil, ist ja ein Unterschied, ob man nun

SPDR = (*bytes)++; 
// oder
SPDR = *(bytes++); 
// schreibt

Zumindest versuche ich stets daran zu denken, an solchen Stellen 
Klammern zu setzen.