mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Lib für NTF24L01+, SE8R01, RFM70 usw.


Autor: Torsten C. (torsten_c) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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...

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-Re...
[2] https://gist.github.com/TorstenC/7c02b06953d438264...

VG Torsten

: Bearbeitet durch User
Autor: Mehmet K. (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Zweifler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Torsten C. (torsten_c) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Mehmet K. (mkmk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.