Hallo, ich versuche schon seit Tagen meine erste Funkstrecke mithilfe zweier NRF24L01+ Modulen zum laufen zu kriegen und bin mittlerweile sehr frustiert. Ich habe mich dabei an dem Tutorial hier aus dem Forum orientiert (https://www.mikrocontroller.net/articles/NRF24L01_Tutorial) bzw. habe diese eigentlich mehr oder minder zunächst komplett übernommen und lediglich an den Atmega328P sowie meine 8 MHz angepasst. Und dennoch läuft nichts. Was mich vor allem verwundert: In der Zusammenfassung des Tutorial steht, dass Enhanced Shockburst verwendet wird und dementsprechend nur ein Interrupt ausleöst wird, wenn ein ACK empfangen wird. Wenn ich die Beispieldateien jedoch richtig interpretiere, ist dieses ACK (was ich für auto acknowledgmet halte) gar nicht aktiviert. Ich habe dieses also aktiviert in der Hoffnung, dass es weiterhilft. Hat es leider nicht. Meine verwendete Pinbelegung steht ganz oben in den beiden Main Datein und ist gefüllt tausend mal kontrolliert. Die Tests (Auslesen des Status Registers und der RXpayload Länge) funktionieren auch. Aber mein Sender geht niemals in den Interrupt, was bedeutet, dass das TX_DS bit nie gesetzt wird und mein Empfänger bekommt auch nie was. Kann einer, der sich mit den Modulen vielleicht schon auskennt mal über meine Dateien drüberschauen oder mit sonst Tipps geben, wie ich den Fehler fidnen kann. Vielen Dank und schönen Abend, M.W.
Ich habe nun noch etwas weiter experimentiert. Und ich bin nur noch frustrierter :( Ich habe das Auto Acknowlegdment nun durch
1 | wl_module_config_register(EN_AA,EN_AA_ENAA_ALL); //Auto Acknowledgment bei allen |
aktiviert. Das Auto retransmit ist auch eingeschaltet, aber frage ich beim Sender ab, wie häufig er schon versucht hat, das Datenpaket neu zu senden, bekomme ich immer nur eine 0, obwohl gar kein Empfänger an ist, er müsste also durchgehend neu versuchen die Daten los zu werden. Im Anhang meine neue Sender-Main
So ich habe meine Module jetzt eeeendlich zum laufen bekommen. Für Interessiert hier nochmal die Probleme: Die im oben genannten Link (https://www.mikrocontroller.net/articles/NRF24L01_Tutorial) beschriebenen Bibliotheken sind wie es aussieht nicht aktuell !!! Bzw. Enthalten Fehler !!! Im Anhang ist nun meine geänderte Bibliothek, vielleicht hilft sie jemandem. Ansonsten kann ich noch darauf hinweisen: Solltet ihr einen Arduino benutzen, um die Funkmodule zu betreiben, so achtet auf ausreichende Stützkondensatoren bei der Versorgung. Ich habe hier ein original Arduino (Sender) und einen "Funduino" (Empfänger). Nachdem der Sender lief, hab ich beim Empfänger lediglich einen 100uF Kondensator in der Versorgung gebraucht, damit dieser auch empfängt. 100uF Kondi weg, Signal weg !
M. W. schrieb: > Nachdem der Sender lief, hab ich beim Empfänger lediglich einen 100uF > Kondensator in der Versorgung gebraucht, damit dieser auch empfängt. > 100uF Kondi weg, Signal weg ! 100µF hört sich nach ernsten Problemen mit der Stromversorgung an. Womit betreibst du denn den Empfänger und wie sieht, ohne den Kondensator, die Versorgung am Modul aus?
W.A. schrieb: > M. W. schrieb: >> Nachdem der Sender lief, hab ich beim Empfänger lediglich einen 100uF >> Kondensator in der Versorgung gebraucht, damit dieser auch empfängt. >> 100uF Kondi weg, Signal weg ! > > 100µF hört sich nach ernsten Problemen mit der Stromversorgung an. Womit > betreibst du denn den Empfänger und wie sieht, ohne den Kondensator, die > Versorgung am Modul aus? Die beiden Module werden direkt aus einem Arduino (Sender) bzw einem "Funduino" [Empfänger] (billig Nachbau schätze ich) betrieben. Beim Billig Nachbau scheinen die 3,3 V nicht ordentlich gestützt. Ich hab einfach einen 100uF Kondensator genommen, weil ich den gerade da hatte, vermutlich reicht aber auch ein kleinerer. Wie sie "aussieht" kann ich leider nicht sagen, kann bis jetzt noch kein Oszilloskop mein eigenen nennen
M. W. schrieb: > Ich hab einfach einen 100uF Kondensator genommen Der Empfänger sollte die geringsten Schwierigkeiten haben da seine Stromaufnahme gering(er) ist. Ein 100uF Elko ist auch sicherlich schlecht geeignet als Abblock-C für höherfrequente Störungen. Eher würde ich beim Empfänger auf ein paar wenige 100nF keramische Kondensatoren setzen. Falls natürlich der xxxduino schon eine schlechte Stabilisierung hat muss man den vielleicht mit extra Elkos unterstützen. Der Sender dagegen zieht (beim Senden natürlich kurzzeitig) viel Strom da er die HF-Ausgangsleistung liefern muss. Dass der Sende-xxxduino nicht ausfällt spricht dafür dass beim Empfangs-xxxduino was nicht stimmt. In all meinen Aufbauten verwende ich unaghängig davon immer am Modul-Anschluss selbst nochmal einen keramischen Kondensator und oft auch noch einen Tantal-Kondensator 5-10uF um die "Gleichstromkomponente" besser zu stabilisieren. Wenn man sich die Gleichspannung im Betrieb mal mit dem Oszilloskop anschaut dann weiss man warum man dieses "unnütze 100nF Zeugs" gerne dazubaut.
M. W. schrieb: > Die beiden Module werden direkt aus einem Arduino (Sender) bzw einem > "Funduino" [Empfänger] (billig Nachbau schätze ich) betrieben. Die werden den Strom nicht erfunden haben, sondern von irgendwoher bekommen und vielleicht noch auf 3V3 runter regeln. Ohne Oszi ist das natürlich schwierig zu beurteilen. Wenn auf dem µC-Board ein Spannungsregler für die 3V3 zuständig ist, kannst du dich glücklich schätzen, wenn der noch vernünftig arbeitet. Viele Spannungsregler mögen es gar nicht gerne, wenn an ihrem Ausgang ein dicker Kondensator hängt.
W.A. schrieb: > Viele Spannungsregler mögen es gar nicht gerne, wenn an ihrem Ausgang > ein dicker Kondensator hängt. Yes. Zumindest leiden die Regeleigenschaften.
Frickelfritze schrieb: > Der Sender dagegen zieht (...) viel Strom da er die HF-Ausgangsleistung > liefern muss. Was vermutest du denn für dicke Ströme? Nordic Semiconductor gibt im Datenblatt bei einer Sendeleistung von 0dBm eine Stromaufnahme von 11.3mA an.
W.A. schrieb: > Nordic Semiconductor gibt im Datenblatt bei einer Sendeleistung von 0dBm > eine Stromaufnahme von 11.3mA an. Kann mich täuschen, hatte andere Ströme (vielleicht von anderen Modulen) in Erinnerung.
Ich würd gern anküpfen, da ich jetzt auch schon seit 4 Tagen versuche eine Funkstrecke mit 2 Stk. nRF24L01+, gesteuert mit ATMEGA328P, herzustellen. Es ist zum Verzweifeln... M. W. (rallini94), vielleicht liest du das. Ich hab auch versucht deine Applikation zu rekonstruieren, jedoch ohne Erfolg. Bitte um Hilfe!!! Technisch ist alles bestens...die Spannungsversorgungen sind OK. Auch die beiden Funkmodule sind bei bester Gesundheit, in Arduino Applikation funktionieren beide fabelhaft, kann und will ich aber nicht adaptieren, weil schon eine Aufwendige "Embedded" Anlage existiert. Das angesprochene Tutorial ist wahrlich fehlerhaft, schön dass es außer mir auch noch jemanden aufgefallen ist. Der Stand der Dinge, der Sender bekommt kein ACK! warum? Deswegen löst auch kein Interrupt aus, der den PTX auf 0 setzten soll. Vermutlich bekommt der Empfänger nicht mit, dass er angesprochen ist..... Der Empfänger schreibt über UART: Beginne Initialisierung... Status: 1110 RX_payload: 32 rf_setup: 110 rf_ch: 2 rx_addr: e7, e7, e7, e7, e7, Warte_auf Empfang...(RX_FIFO_DATA_READY_FLAG) Der sender schreibt: Beginne Initialisierungen... Status: 1110 RX_payload: 32 rf_setup: 110 rf_ch: 2 tx_addr: e7, e7, e7, e7, e7, Sende: ... Package lost: 0 Status: 1110 Retransmitted Count: 15 Package lost: 0 Status: 1110 Retransmitted Count: 15 Package lost: 0 Status: 1110 Retransmitted Count: 15 . . . Anbei noch die Dateien...
Thomas B. schrieb: > Der Stand der Dinge, der Sender bekommt kein ACK! warum? Deswegen löst > auch kein Interrupt aus, der den PTX auf 0 setzten soll. Vermutlich > bekommt der Empfänger nicht mit, dass er angesprochen ist..... Beim Studium der "erfolgreich" gemeldeten Sourcen ist mir eines aufgefallen: die Variable PTX ist zweimal definiert, und das kann je nach Compiler-Verhalten und Header-Definitionen vielleicht zu zwei unabhängigen Variablen führen obwohl nur eine gemeint ist. Dann funktioniert das ganze on/off Wechselspiel nicht. Also ich meine diese Variable gehört ins Modul <wl_module.c> einmal (volatile) definiert und durch Setz-Funktion von aussen gesteuert. Alternativ dazu global extern bekannt gemacht damit es vom Hauptprogramm gesteuert werden kann.
WOW schnelle Antwort. Compilieren tut bei mit WinAVR-GCC, AVR/GNU C Compiler : 4.8.1 im Atmel Studio 6.2 Ich hab dein Rat beherzigt, die globale Variable steht jetzt nur mehr in der Datei <wl_modul.c>. Das compilieren war erfolgreich, jedoch leider keine Veränderung...
Hoppala. hatte vorhin den falschen Code für den Empfänger hochgeladen...
Thomas B. schrieb: > Hoppala. hatte vorhin den falschen Code für den Empfänger hochgeladen... Kann da die Variable PTX immer noch deutlich erkennen ....
Nach 5 Tagen Verzweiflung hab ich beschlossen, auf die Interrupt-Lösung zu verzichten und die Daten am Empfänger regelmäßig abzufragen. Dazu habe ich auch einen passenden Code auf Github gefunden, der auch mit ATMEGA 328P funktioniert. Den Software UART und Software SPI habe ich gegen die HW_Variante getauscht und den SYS-Takt auf 16MHz eingestellt. Noch ein Tipp. Ich habe für den Sender einen Arduino-Nano Nachbau verwendet, weil der alles drauf hat, was man benötigt und fast nichts kostet. Um HEX-Files aus C-Sourcecode komfortabel über USB mittels Bootloader programmieren zu können, verwende ich XLoader v1.00. Im Anhang die Files. Vielleicht hilft es jemanden...
Hallo, ich habe auch die Funkmodule bekommen und möchte damit daten übertragen. Auch ich habe Schwierigkeiten mit den dingern und werde mir mal deine datein angucken, ob das damit besser klappt. Eine Frage habe ich vorher noch (bevor ich das Projekt doch fallen lasse). Du erstellst jetzt einen als Transmitter (A) und den anderen als Receiver (B). Kann der Receiver (B) denn eine Antwort senden? und kann der Transmitter (A) die Antwort erhalten und auswerten? Also, kann der Receiver zum Transmitter werden und umgekehrt? Ich möchte gerne meine Teile überwachen. Dazu möchte ich vom der Station eine Abfrage senden, die alle anderen bekommen. Diese sollen sich dann natürlich mit entsprechenden Werten zurückmelden, sodass ich die Daten in der Station verarbeiten kann. Ist das überhaupt möglich? Überall lese ich nämlich, dass die entweder als Sender oder als empfänger konfiguriert werden. Frank
Ja, das geht, der Receicer kannn auch zurück-senden. Im Beispiel geht der Sender nach dem senden auf Empfang und wartet kurz. Im Multiceiverbetrieb ist es so, deine Station ist der Empfänger und du hast mehrere Sender. Die Sender würden alle ihre Daten senden und der Empfänger fragt eine Adresse nach der anderen ab. Im Datenblatt sind die Modis beschrieben, wie man mit Multipipes umgeht. Ich kann leider nicht alles im Detail beantworten, da ich ja selber noch im Studium bin. Viel Erfolg wünsch ich dir mit deinem Projekt.
M. W. schrieb: > Ansonsten kann ich noch darauf hinweisen: Solltet ihr einen Arduino > benutzen, um die Funkmodule zu betreiben, so achtet auf ausreichende > Stützkondensatoren bei der Versorgung. Ich habe hier ein original > Arduino (Sender) und einen "Funduino" (Empfänger). Nachdem der Sender > lief, hab ich beim Empfänger lediglich einen 100uF Kondensator in der > Versorgung gebraucht, damit dieser auch empfängt. 100uF Kondi weg, > Signal weg ! Das liest man aber immer wieder... Kondensatoren für eine stabile Versorgung sind das A und O.
Verwendet man den 3V3 Ausgang des Arduinos, ist man mit stabilisieren gut beraten. Ich verwende spezielle nRF24-Adapter mit intigrierten 3.3V Regler und Versorge dann das Modul mit den stabilen 5V. Noch ein Tipp. Die Version mit LNA PA, also mit Antennenanschluss, funktionieren erst ab ein paar Meter fehlerfrei. Ich funke über eine leichte Kuppel mit hilfe einer Richtfunkantenne auf eine Distanz von 250m ohne Probleme. Mit 2 RFA sind die angegebenen 1000m kein Thema (1Mbps). Mit den Stabantennen bei freier Sicht, freies Gelende, 250kbps und 30% Datenverluste, immerhin noch 800m, wobei einer der beiden auf mind. 4m über Grund sein sollte.
Hallo, erst einmal vielen dank für deine Überarbeitung der Dateien. Die im Tutorial sind mir auch schon aufgefallen, dass dort Fehler drinne waren. Ich benutze einmal einen Atmega328p und einen ATtiny2313. Wenn ich den ATtiny als Sender benutze, funktioniert dsa ganze noch nicht so wirklich. es wird mir zwar gesagt, dass die Transmission OK war, aber am Atmega kommt nichts an. Auch wenn ich das Funk-Modul rausnheme, bekomme ich die Info, dass die Übertragung funktioniert hat. Könntet ihr drüber gucken, was dort fehlerhaft ist? Frank
Frank schrieb: > Atmega kommt nichts an. Auch wenn ich das Funk-Modul rausnheme, bekomme > ich die Info, dass die Übertragung funktioniert hat. Gibt's da vill einen Prüfmodus der das was zum Sender geht gleich wieder zum Empfänger leitet, also intern vor der HF? Oder steht das was gesendet wurde bzw. zu senden ist in einem Puffer drin und wird dann da rausgelesen? Oder ist die Quittungsprozedur abgeschaltet. Kurt
hallo zusammen, ich habe die gleichen Probleme bzw. komme gar nicht soweit. TX_modul löst keinen Interrupt aus... ich habe die wl_module.c datei abgeändert (war das wirklich nur statt dem define-Wert der 0b00000111?) und trotzdem funktioniert nix. Zur Zeit debugge ich, indem ich die Register des NFR24l01 auslese von der Adresse 0 bis 20(Bild code). Hierzu bediene ich mich der funktion: wl_module_read_register(0,registerwerte,20) Die gelesenen Werte gebe ich dann per UartTerminal an meinen PC weiter. Allerdings sind die Werte aller Register immer gleich(BILD terminal) ... das kann doch nicht sein oder? Ich denke mein SPI funktioniert nicht richtig. wenn ich das Modul abstecke sind alle gelesenen Werte NULL wie erwartet. Also irgendwas tut das Modul doch! Ich habe den Verdacht, dass das Modul den Readbefehl nicht annimmt und deshalb immer den STATUS zurückgibt und deshalb alle Werte gleich sind. Wie lest ihr die register aus ? Muss ich das Modul abziehen wenn ich den atmega neu programmiere(Programmerpins gehen auf Spi-pins)? PS: ich verwende: ATmega8a, Atmel Studio, HTerm, MK2 entwicklungsboard
Florian R. schrieb: > Muss ich das Modul abziehen wenn ich den atmega neu > programmiere(Programmerpins gehen auf Spi-pins)? Das verstehe ich nicht, das klingt so als ob du voll im Nebel herumtappst. Du musst doch im Programmierprozess merken ob der Controller erfolgreich seine Daten bekommen hat oder nicht! Das Verify sollte diese Rückmeldung geben?
Florian R. schrieb: > ich habe die gleichen Probleme Durch Doppelposting wirst du es nicht besser lösen ... Beitrag "NRF24L01 SPI immer Selber wert gelesen"
ja bei wem geht das ding den ? und wo ist der Code der auch wirklich funktioniert?
Hallo Florian. Damit Das Ding das macht was du von dem verlangst, musst du es verstehen. Das Datenblatt und die vielen Codbeispiele helfen dir dabei. Das ist kein Shoppingcenter wo du einfach nur nen fertigen Code abholst. Wenn du sowas suchst, lade dir Arduino IDE auf den Computer. Die Anforderungen und die Umgebung sind jeweils zu verschieden, um dass es DEN einen funktionierenden Code geben kann.
Hallo, leider habe ich immer noch große schwierigkeiten, Daten mittels nrf24l01 zu übertragen. Besser gesagt, es funktioniert gar nicht. Probleme habe ich auch noch mit dem Datenblatt. Dort ist ein State-Diagramm eingezeichnet, wie ich in die einzelnen States kommen kann. In der nrf24.c-Datei steht unter nrf24_config():
1 | void nrf24_config(uint8_t channel, uint8_t pay_length)//(2,4) |
2 | { |
3 | /* Use static payload length ... */ |
4 | payload_len = pay_length; |
5 | |
6 | // Set RF channel |
7 | nrf24_configRegister(RF_CH,channel); |
8 | |
9 | // Set length of incoming payload |
10 | nrf24_configRegister(RX_PW_P0, 0x00); // Auto-ACK pipe ... |
11 | nrf24_configRegister(RX_PW_P1, payload_len); // Data payload pipe |
12 | nrf24_configRegister(RX_PW_P2, 0x00); // Pipe not used |
13 | nrf24_configRegister(RX_PW_P3, 0x00); // Pipe not used |
14 | nrf24_configRegister(RX_PW_P4, 0x00); // Pipe not used |
15 | nrf24_configRegister(RX_PW_P5, 0x00); // Pipe not used |
16 | |
17 | // 1 Mbps, TX gain: 0dbm |
18 | nrf24_configRegister(RF_SETUP, (0<<RF_DR)|((0x03)<<RF_PWR)); |
19 | |
20 | // CRC enable, 1 byte CRC length |
21 | nrf24_configRegister(CONFIG,nrf24_CONFIG); |
22 | |
23 | // Auto Acknowledgment |
24 | nrf24_configRegister(EN_AA,(1<<ENAA_P0)|(1<<ENAA_P1)|(0<<ENAA_P2)|(0<<ENAA_P3)|(0<<ENAA_P4)|(0<<ENAA_P5)); |
25 | |
26 | // Enable RX addresses |
27 | nrf24_configRegister(EN_RXADDR,(1<<ERX_P0)|(1<<ERX_P1)|(0<<ERX_P2)|(0<<ERX_P3)|(0<<ERX_P4)|(0<<ERX_P5)); |
28 | |
29 | // Auto retransmit delay: 1000 us and Up to 15 retransmit trials |
30 | nrf24_configRegister(SETUP_RETR,(0x04<<ARD)|(0x0F<<ARC)); |
31 | |
32 | // Dynamic length configurations: No dynamic length |
33 | nrf24_configRegister(DYNPD,(0<<DPL_P0)|(0<<DPL_P1)|(0<<DPL_P2)|(0<<DPL_P3)|(0<<DPL_P4)|(0<<DPL_P5)); |
34 | |
35 | // Start listening |
36 | nrf24_powerUpRx(); |
37 | } |
Aber im Datenblatt finde ich nichts, wie die Register beschrieben werden müssen um die jeweiligen einstellungen zu erhalten. Auch z.B. die Funktion um in den RX-Mode zu gelangen
1 | void nrf24_powerUpRx() |
2 | { |
3 | wl_module_CSN_lo; |
4 | spi_fast_shift(FLUSH_RX); |
5 | wl_module_CSN_hi; |
6 | |
7 | nrf24_configRegister(STATUS,(1<<RX_DR)|(1<<TX_DS)|(1<<MAX_RT)); |
8 | |
9 | wl_module_CE_lo; |
10 | nrf24_configRegister(CONFIG,nrf24_CONFIG|((1<<PWR_UP)|(1<<PRIM_RX))); |
11 | wl_module_CE_hi |
12 | } |
Was wird da gemacht? Eigentlich muss ich nach dem STate-Diagramm doch nur CE auf high setzen wl_module_CE_hi und PRIM_RX=1 senden? Wäre super, wenn mir da jemand einen Denkanstoß geben könnte. Solangsam lassen mich die dinger verzweifeln. Frank
Hallo Frank Die Dinger funktionieren erst, wenn man ihnen aus Verzweiflung droht... :-) Ich möchte dir einen Anstoß geben, über ein Thema das wesentlich ist und verstanden werden sollte. Versuche etwas herauszufinden über die Betriebsarten PTX, ACK und vor allem Interrupt. Als nächstes sollte man sich überlegen, welche Anforderung man ganz genau an der Funkstrecke hat! Frank schrieb: > void nrf24_powerUpRx() > { > wl_module_CSN_lo; > spi_fast_shift(FLUSH_RX); > wl_module_CSN_hi; > > nrf24_configRegister(STATUS,(1<<RX_DR)|(1<<TX_DS)|(1<<MAX_RT)); > > wl_module_CE_lo; > nrf24_configRegister(CONFIG,nrf24_CONFIG|((1<<PWR_UP)|(1<<PRIM_RX))); > wl_module_CE_hi > } Das ist aus der Variante ohne angeschlossenen IRQ Pin..... Die Rotinen machen das, was sonst in der ISR passieren würde: FLUSH_RX - löscht den FIFO RX, (STATUS,(1<<RX_DR)|(1<<TX_DS)|(1<<MAX_RT)) - setzt die drei IRQ Auslöse Flags zurück. Man könnte sagen es wird eine neue Ausgangssituation geschaffen, um neue Daten empfangen zu können.
ich habe mich heute mal wieder dran gemacht und komm wieder nicht weiter. Da ich nur die NRF24L01 module besitze(und nicht die NRF24L01+) habe ich nen das Beispiel aus dem Datenblatt auf Seite 29 programmiert. Aber es wurde keine Übertragung bestätigt. Wäre nett wenn jemand auch diesen Ansatz mal durchschaut und sagt woran es liegen kann. Fürs erste reicht mir eine einfach Testübertragung, wie sie im Code zu sehen ist.(NRF_EIGEN soll NRF_EIGEN_RX heißen) SPI funktioniert sicher. IRQ auch(ich frage nur die IRQ bits im STATUS_reg ab) Folgendes passiert: Sender: Sendet und bricht ab, weil die maximale Anzahl an Retransmits erreicht wurde. Empfänger: wartet auf IRQ_bit, das nicht kommt. einen 100nF Kondensator hab jeweils zwischen VSS und VCC der Module gelötet. Die 3V bekomme ich aus 5V mit der Schaltung her(bild). Gruß FLo
Das Timing ist ganz wesentlich. Bei mir war für eine Funkübertragung in beiden Richtungen ein Delay von bis zu 1ms am Receiver, zwischen Daten empfangen und Senden notwendig, weil der Tranmitter Zeit braucht, bis er wieder empfangsbereit ist. Was ich so gesehen habe ist das ganz oft nicht bedacht.
Thomas B. schrieb: > Was ich so gesehen habe ist das ganz oft nicht bedacht. Das spielt jedoch beim primären Aufbau einer Verbindung (ein Paket senden und eine Rückmeldung, ein Ack, dafür bekommen) erst einmal keinerlei Rolle da die beteiligten Controller (und damit der Programmierer) dafür keine zeitliche Verantwortung tragen ("AutoAck").
Ich sprich auch nicht von Ack., sondern von Datenübertragung in beiden Richtungen.
Thomas B. schrieb: > Ich sprich auch nicht von Ack., sondern von Datenübertragung in beiden > Richtungen. .... und daher sind deine Ratschläge für die Leute die es noch nicht geschafft haben überhaupt ein Datenpaket zu übertragen, nicht von Bedeutung.
Ist da einer frustriert? Die Ratschläge sind gut gemeint und sollen helfen. Das Thema ist ""NRF24L01 und Atmega328P"" weiter oben habe ich den gesamten Code zur Verfügung gestellt, wie diese Konfiguration zumindest mit Atmel Studio ab V6.2 auf jeden Fall funktionieren sollte.
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.