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.
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)
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?
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"?
