Hallo, eventuell bin ich zu blöd aber man kann doch mehrere "Module" am SPI betreiben oder? Ich habe den Programmer und NRF24L01 dran. Sobald beide dran hängen kann ich den µC nicht programmieren. Fehlermeldung: Kommunikation nicht möglich. "Ziehe" ich den NRF24L01 klappt es. Umgekehrt funktioniert meine Funkverbindung nicht. Ich nehme an aufgrund des gleichen Problems. Den Programmer kann ich leider nicht abziehen momentan, da er meine Stromversorgung über USB darstellt. Ist dieses Verhalten normal?
> Umgekehrt funktioniert meine Funkverbindung nicht.
Verkabelung richtig?
Dem SlaveSelect des NRF Moduls könntest du evtl. einen (externen) Pullup
verpassen.
Dann kann es nicht dazwischen quatschen.
Wäre auch mein erster Ansatz. Beim programmieren sind die Pins vom Avr hochohmig, da kann der Chipselect vom nRF schon mal auf low zappeln und der nRF dir die Kommunikation zwischen uC und Programmieradapter versauen
Hi, verkabelung habe ich eben noch einmal geprüft. Alles okay. So angeschlossen wie hier im Funk-Tutorial angegeben. Den externen Pull-Up werde ich mal ausprobieren. Wie genau muss der angeschlossen werden? Kenne das nur von Tastern bisher. Vcc 5V | R 1k | PB1 AVR ----- | | CSN des NRF So?
Ja so ist es richtig. Ich hoffe du betreibst den nRF aber nicht mit 5V. Die Inputs sind ja 5V tolerant, aber es wurde auch schon berichtet, dass es da Probleme gegeben hat (vielleicht auch nur bei den gefälschten Chips, die ja auch kein 250 kpbs können): http://hackaday.com/2015/02/23/nordic-nrf24l01-real-vs-fake/
Schade funktioniert dennoch nicht. Habt ihr eine Idee wie man jetzt am besten vorgeht um den Fehler zu finden? Angeschlossen ist der NRF wie im Tutorial beschrieben. Zudem habe ich ein LCD am C-Port hängen. Das funktioniert einwandfrei. Auswirkungen des Fehlers: - Programmierung mit angeschlossenem NRF über SPI nicht möglich - Sender funkt nicht: Auf dem LCD sehe ich, dass er wartet, dass das Paket versendet wird. Betrieben wird die Schaltung mittels des Programers am USB.
Es gibt bei Atmel Hinweise zur Entkopplung des ISP Programmierers von den restlichen Teilnehmern. Dr. Gurgel liefert bei "avr isp spi resistors" auch viele Hinweise. http://www.kanda.com/avr-isp-circuits.html&h=177&w=274&tbnid=U4uMuDXuo0RImM:&zoom=1&tbnh=90&tbnw=139&usg=__iTEc9_ef_X60E5m2I7fCDF5MabQ=&docid=AGGJf83fI99mHM https://forum.sparkfun.com/viewtopic.php?t=11380 www.atmel.com/images/doc0943.pdf
Also... Du könntest mal einen Link zu dem Tutorial posten, welches du verwendest. (ich kann zwar raten, welches du verwendest, aber nicht wissen) Du könntest verraten welchen µC du einsetzt. (manche haben SS Pins, welche unbedingt auf Output gestellt werden müssen, um in den Master Modus zu gehen) Meine NRF24L01+ Module benötigen einen Kondensator an den Versorgungspins. 10µF reichen da, sonst sind sie sehr unzuverlässig. ICSP ist bei mir möglich, mit eingestecktem NRF24L01+, und ohne Pullup auf SS Ich betreibe die Module mit 3,3V (aber 3V sollten auch reichen)
Du hast aber schon eine eigene Leitung für CSN genommen?
Hallo, das Tut habe ich von: http://www.mikrocontroller.net/articles/NRF24L01_Tutorial Anbei auch noch der Schaltplan. An den 3V VCC für den NRF habe ich einen 10µF Elko und einen 100nF dran. VG
Also habe jetzt mal ein 12V ran gehangen (mit 7805 zwischen) und die Schaltung nicht mehr über USB (ISP) betrieben. Bzgl. meines Funksenders kein Unterschied. D.h. also es ist (unabhängig vom parallelen Betrieb von ISM und NRF) auch noch etwas am Sender faul. Die Software hängt beim Senden des Paketes fest. Die Software habe ich eigentlich 1:1 vom Tut übernommen. Des µC auf 8Mhz gestellt und losgelegt. Außer dem LCD ist am µC auch nichts weiter dran.
Und nochmal: Das Datenblatt des ATMega8 P sagt recht klar: > If SS is configured as an input, it must be held high > to ensure Master SPI operation. If the SS pin > is driven low by peripheral circuitry when the SPI is > configured as a Master with the SS pin > defined as an input, the SPI system interprets > this as another Master selecting the SPI as a > Slave and starting to send data to it. Also SS(PB2) auf Output stellen oder einen Pullup setezn. Auch noch aus dem Datenblatt: > • Bit 4 – MSTR: Master/Slave Select > This bit selects Master SPI mode when written to one, > and Slave SPI mode when written logic > zero. If SS is configured as an input and is driven > low while MSTR is set, MSTR will be cleared, > and SPIF in SPSR will become set. The user will then > have to set MSTR to re-enable SPI Master > mode. Beim kleinsten Low Impuls auf PB2 wird der ATMega von Master in den Slave Modus wechseln. Und jegliche Kommunikation mit deinem NRF Modul stirbt damit ab.
Es ist auch möglich das sein NRF24L01+ defekt ist. Bei meinem war das auch ein paar mal der Fall, erst als ich auf der Unterseite der Platine, genau unter dem Chip etwas Flussmittel in das/die Vias laufen lassen habe und dann mit Lötzinn den unteren Bereich ordentlich erwärmt hatte lief das Modul. Bei einem Modul war unten eine freie Fläche die auch verzinnt war, so ging das sehr problemlos. Bei einem neueren Modul war dann nur noch ein Via unten drunter und ich musste erst etwas Lötstopplack unter dem Chip wegkratzen. So habe ich alle Module die ich mir bestellt hatte wieder zum laufen gebracht. Scheinbar war das große Centerpad des Chips nicht richtig mit der Platine verbunden.
PB2 mit DDRB |= (1 << DDB2); auf Ausgang gestellt. Keine Veränderung. NRF klappt nicht (auch nicht mit Netzteil statt USB). Kommunikation mit ISP obwohl NRF dran ist geht auch leider nicht.
Muss ich denn am Tutorial Quellcode noch etwas anderes umstellen außer PB2 auf Ausgang zu stellen? Der µC hängt in der While-Schleife fest: void wl_module_send(uint8_t * value, uint8_t len) // Sends a data package to the default address. Be sure to send the correct // amount of bytes as configured as payload on the receiver. { while (PTX) {} // Wait until last paket is send wl_module_CE_lo; PTX = 1; // Set to transmitter mode TX_POWERUP; // Power up wl_module_CSN_lo; // Pull down chip select spi_fast_shift( FLUSH_TX ); // Write cmd to flush tx fifo wl_module_CSN_hi; // Pull up chip select wl_module_CSN_lo; // Pull down chip select spi_fast_shift( W_TX_PAYLOAD ); // Write cmd to write payload spi_transmit_sync(value,len); // Write payload wl_module_CSN_hi; // Pull up chip select wl_module_CE_hi; // Start transmission _delay_us(10); // Grünes Modul funktioniert nicht mit 10µs delay wl_module_CE_lo; } Ich vermute das ist, weil der NRF nicht richtig funktioniert. Habe noch ein zweites NRF Modul ausprobiert. Klappt leider auch nicht. Mh... Was könnte man denn noch prüfen außer, ob alles richitg angeschlossen ist?
Hallo, kann mir eventuell jemand sagen, wo PTX denn wieder auf 0 gesetzt wird? Ich finde die Stelle im Code gar nicht. (http://www.mikrocontroller.net/articles/NRF24L01_Tutorial) Bin blind.
Das passiert in der ISR. Interrupts hast du hoffentlich an?!
Phillip schrieb: > Kommunikation mit ISP obwohl NRF dran ist geht auch leider nicht. 240R in die MISO vom NRF legen. Den Link hat Georg ja schon aufgezeigt, nur ansehen müsstest das eigentlich selbst. Wenn es sauber sein soll, dann CE/CSN per externen PullUp noch auf +UB vom NRF legen.
@Toralf: Werde das gleich mal einbauen @Timmo: Was meinst du damit? Der Atmega zählt fleißig hoch und würde eigentlich jede Sekunde ein Paket senden. Beim ersten Senden hängt er aber bereits da er das Paket nicht versenden kann. Wenn ich den Aufruf der Sende-Prozedur auskommentiere läuft der Atmega und gibt mir fleißig im Sekundentakt Rückmeldung am LCD. Interrupts sollten also funktionieren sofern du den Timer-Interrupt meintest.
zwei Tipps noch von mir Steck die Module im laufenden Betrieb mal ab und wieder an. Wenn du mehrere hast rotiere sie mal durch - war bei mir die Lösung, seit dem arbeiten die Module. hast du 2 wirklich indentische Module? schau dir dir Beschriftung der Chips an - ich habe aus China 4 Module erhalten die gefaked sind sowie ein Modul das wie von NRF beschriftet ist. Die Gefälschten arbeiten zusammen, der eine Originale arbeitet allerdings nicht mit den Gefakten zusammen.
Schreibe doch erstmal ein Progrämmchen, welches die Register des NRF ausließt. Wenn das klappt, steht dein SPI Verbindung gut da. Wenn nicht, dann wirds mit dem Funken ganz sicher nichts.
Phillip schrieb: > @Toralf: Werde das gleich mal einbauen > > @Timmo: Was meinst du damit? Der Atmega zählt fleißig hoch und würde > eigentlich jede Sekunde ein Paket senden. Beim ersten Senden hängt er > aber bereits da er das Paket nicht versenden kann. Wenn ich den Aufruf > der Sende-Prozedur auskommentiere läuft der Atmega und gibt mir fleißig > im Sekundentakt Rückmeldung am LCD. Interrupts sollten also > funktionieren sofern du den Timer-Interrupt meintest. Naja du hast gefragt wo PTX zurückgesetzt wird. Und in dem Beispiel passiert das eben in der ISR(INT0_vect) und zwar dann wenn nach einem Interrupt vom nRF das TX_DS Bit im Status register gesetzt ist. PTX wird also nur dann auf 0 gesetzt wenn deine Daten auch weg ist. Das setzt natürlich voraus, dass die grundlegende Funktionalität vom nRF gegeben ist. Du könntest dir nach der Initialisierung mal ein paar Register vom nRF auswerfen lassen und deren Inhalt auf richtigkeit zu prüfen um zu sehen ob die Kommunikation überhaupt richtig läuft.
Okay also werde dann mal ein paar Dinge umsetzen. ToDo: - Anschlüsse verbessern (von Toralf) - generelle Funktionalität prüfen von ISP und NRF (Ulrich und Timmo) Zudem habe ich mir vier neue NRF gekauft. Sind aber noch nicht da. Nur um sicherzustellen, dass meine derzeitigen nicht schon defekt sind (China-Import billig billig).
Phillip schrieb: > Nur > um sicherzustellen, dass meine derzeitigen nicht schon defekt sind > (China-Import billig billig). Nicht alles, was aus China kommt, ist Müll. Ich hatte bisher bei etwa 20 Bestellungen nur einmal Pech (und das Geld innerhalb Stunden zurück bekommen). Die Chance ist hoch, dass deine Soft noch einen kleine suboptimale Ecke hat.
Hallo, also habe nun PullUp an CE/CSE und 270R am MISO. Weiterhin habe ich versucht erst einmal einfach nur ein Register des nRF24L01+ auszulsesen. Ohne Erfolg. uint8_t data_buf = 3; uint8_t data_buf1; ... (while / spi_init etc.) ... wl_module_CSN_lo; data_buf1 = 0x05; data_buf = spi_fast_shift(data_buf1); wl_module_CSN_hi; char Buffer2[20]; itoa( data_buf, Buffer2, 10 ); lcd_string( Buffer2 ); Am LCD kommt leider nur "0" an obwohl durch die NRF24L01-init-Prozedur das Register 0x05 auf 2 setzt. Irgendetwas passiert aber, sonst wäre eine "3" zu sehen (siehe deklaration oben). Wie könnte ich denn bei der Fehlersuche vorgehen?
Hi, also habe noch etwas weiter getestet und es ist wohl so, dass der NRF einige Male einen IRQ sendet (ziemlich viele bis zu 100 in 2 Sekunden). Nach diesen 80 oder 100 hört der NRF dann auf einmal aus. Beim Auslesen des STATUS registers scheint es so, als ob ich immer versuche ein Paket zu senden aber im STATUS steht, dass das Senden fehlgeschlagen ist. Danach wird ja versucht erneut zu senden. Das passiert die 80 bis 100 mal in den 2 Sekunden, danach ist Schluss und es bewegt sich nichts mehr, weil kein IRQ mehr ausgelöst wird. Ich halte euch auf dem laufenden. Ich habe momentan noch keine Ahnung, wieso das Paket nicht gesendet wurde. Habe aber auch keinen Empfänger momentan dran, eventuell heißt der Status ja auch: gesendet ja, empfangen nein. Ich glaube aber, dass diese Funktionalität im Tutorial hier auf der Seite nicht der Fall ist .
Ist ja auch ziemlich optimistisch zu glauben dass jeder Transfer funktioniert. Besser wäre es zu warten bis ein von dir definierter timeout abgelaufen ist und ggf das Paket nochmal zu senden. Die Beispiel-Codes sollen ja nur zeigen wie etwas prinzipiell funktioniert und sind nicht unbedingt für den operationellen Gebrauch gedacht
Phillip schrieb: > Das passiert die 80 bis 100 > mal in den 2 Sekunden, danach ist Schluss Hast du eventuell Auto-Ack aktiviert? Machst du vor jedem Sendeversuch ein "flush_tx"?
Ich habe an dem Tutorial-Code nichts geändert. Lediglich die LCD-Routinen eingebaut.
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.