SoftSPI Problem ATmega2560 nRF24L01+

[L. N. (derneumann)]

Hallo zusammen!

Ich kaue nun schon seit einiger Zeit an einem Problem rum und bekomme es 
nicht gebacken.

Meiner Meinung nach ist es kein Soft- sondern ein Hardwareproblem.

Ich habe in Eagle eine Experimentierplatine für den ATmega2560 erstellt 
(und fertigen lassen) die alle möglichen Ausgänge, LEDs, Schalter und 
Pin Header hat. Im Endeffekt sind fast alle Pins in Verwendung.

Das zu Routen, mit meiner geringen Erfahrung, war kein großer Spaß. Vor 
allem da ich aus Kostengründen nur 10x10cm Platz auf zwei Layern hatte. 
Die Groundplane ist ziemlich zerfetzt und mit ein paar Vias wieder 
geflickt. Vielleicht ist ja da schon das Problem.

Nun zum Problem: Ich habe zwei Pinheader (2x4) für die typischen 
nRF24L01+ Breakout Boards 
(https://www.google.at/search?q=nrf24l01&source=lnms&tbm=isch&sa=X&ved=0ahUKEwii0fGt74TVAhXQaVAKHRR0CKgQ_AUIBigB&biw=1207&bih=755#imgrc=QT1IrzzFRTRxYM:) 
ausgeführt. Einmal an Hardware SPI und einmal an irgendwelchen I/O Pins 
die dann per Bitbang Software SPI mit der DigitalIO Library genutzt 
werden. Hintergrund ist, dass ich (ihr werdet es euch schon gedacht 
haben) den Arduino Core und die diversen Libraries nutze und da gibts 
Konflikte zwischen der SD Karten Lib und der nRF Lib die ich nutze 
(https://github.com/nRF24/RF24) betreffend den SPI Bus.

Auf der SoftSPI MISO Line (möglicherweise auch noch wo anders) dürfte 
ich eine Menge Störungen haben, denn die nRF Library glaubt ständig, das 
nRF Modul hätte Daten empfangen. radio.available() ergibt ständig true, 
womit das Programm dort aus dieser Schleife auch nicht mehr rauskommt.

Ich habe denselben Aufbau schon am Steckbrett und auch auf einer 
Lochrasterplatine gehabt und da ging alles einwandfrei (bzw. geht auch 
jetzt noch einwandfrei). Ich habe dieselben I/O Pins bei der gefertigten 
Platine genutzt wie am Steckbrett und auf der Lochrasterplatine.

Leider habe ich kein Oszi (könnte auch nicht damit umgehen). Habe mir 
nur von Salae so einen Logic Analyzer gekauft (https://www.saleae.com/) 
um da mal den Einstieg zu schaffen.

Ergänzend: radio.available() ist auch true, wenn das NRF Modul gar nicht 
am Pinheader angesteckt ist. Wenn ich die Finger auf den Pinheader lege, 
scheine ich mit der eigenen Kapazität irgendetwas zu bewirken und das 
Programm läuft weiter. Wenn das Modul drinsteckt, muss ich die Platine 
am Pinheader berühren und noch an einem anderen (Hardware) SPI 
Pinheader, damit das Programm weiter läuft.

Weiter geht es mit dem gekauften Logic Analyzer, der verfälscht mir 
leider die Messung. In dem Moment, wo ich den Logic Analyzer an der 
Software MISO Leitung anschließe (es steckt kein NRF Modul dran), 
verschwinden die Störungen komplett und das Programm läuft als ob nichts 
wäre. Wenn das nRF Modul auch drinsteckt, funktioniert das nicht, da 
bleiben die Störungen erhalten. Ich wollte eigentlich mal ohne Modul am 
Software SPI Bus nachschauen, was da abgeht.

Ich habe natürlich schon andere NRF Module probiert, auch höherwertige 
von Sparkfun (10€ das Stück, statt unter 1€ von Aliexpress).

Habe auch schon Source Termination probiert, indem ich einen 68 Ohm 
Widerstand zwischen Microcontroller Pin von Software MISO und dem Rest 
der Leiterbahn gelötet habe (Leiterbahn vorher durchtrennt). Hat auch 
nichts gebracht.

10n oder 100n am nRF Modul zwischen 3.3V und Masse ändern auch nichts. 
Die nRF Module die ich hier habe brauchen diesen Decoupler eigentlich 
nicht, hatte früher ganz billige von Aliexpress, die funktionierten 
teilweise nichtmal MIT diesem Decoupler.

Ich weiß, es handelt sich hierbei um ein sehr spezielles Problem welches 
von Hunderten Faktoren die so nur bei mir existieren beeinflusst wird 
aber ich dachte, dass hier vielleicht jemand eine Idee hat, was ich noch 
probieren könnte da mir langsam echt nichts mehr einfällt.
Soll ich alle SPI Pins an der Quelle terminieren (~68R in Serie direkt 
am |µC) oder soll ich RC Low Pass Filter einbauen, soll ich euch mal das 
Routing zeigen und das Zeug alles neu machen, ...?

Der Punkt ist ja, dass es am Steckbrett funktioniert und jeder Versuch 
mit neuer Platine erstens Geld und zweitens Zeit kostet da Platinen ja 
erstmal gefertigt und geliefert werden müssen.

Dies ist bereits die zweite Platine, die erste hatte das gleiche 
Problem. Einen defekten µC würde ich damit also ausschließen. Habe die 
Platine nach dem Löten auch vom Flussmittel befreit (mit 
Leiterplattenreiniger und Isopropylalkohol). Kalte Lötstellen kann ich 
ausschließen, alles mit Uhrmachermonokel hundert mal genauestens 
begutachtet.

Welche Informationen würden euch noch fehlen, um den einen oder anderen 
Tipp abgeben zu können?

Es handelt sich hier übrigens rein um eine Hobbyaktion aus Spaß an der 
Freude. Ich will damit kein Geld verdienen oder sonstwas und ich habe 
das (wie man merkt) auch nicht gelernt, interessiere mich aber sehr für 
Elektronik.

Danke für eure Zeit und Mühe!

Gruß
DerNeumann


edit: ich habe mich ans Datasheet von Atmel/Microchip gehalten und an 
allen VCC/GND Pins so nah wie möglich Decoupling Caps eingesetzt (0805 
100n).
16MHz Quarz mit 22pF Kondensatoren, Linearregler (7805 und LD33V). Der 
7805 ist mit 2200µF davor und 1000µF sowie 100n geglättet bzw. 
entkoppelt, der LD33V hängt dahinter und hat 100n und 330µF (den Elko 
nur am Ausgang). Jeder IC hat einen 100n Decoupling Kondensator. Die 
Elkos sind von Würth und Nichicon. Beim Testen hängt keine last drauf, 
damit sind sie hoffnungslos überdimensioniert.

[Anal Ysator (Gast)]

Lucas N. schrieb:
> Welche Informationen würden euch noch fehlen, um den einen oder anderen
> Tipp abgeben zu können?

Ganz klar: den Schaltplan und zwei detaillierte Fotos (beide
Seiten) von deinem Aufbau. Der Schaltplan muss auch vollständig
authentisch sein.

Prosa-Schaltpläne und Prosa-Aufbauten sind hier nicht erwünscht.

Da Prosa-Software auch nicht erwünscht ist wird man sich ggf
später auch noch deine Sketch-Kreation anschauen müssen.

[L. N. (derneumann)]

Anal Ysator schrieb:
> Ganz klar: den Schaltplan und zwei detaillierte Fotos (beide
> Seiten) von deinem Aufbau. Der Schaltplan muss auch vollständig
> authentisch sein.

meinst du mit Aufbau nun die Platine wo ich das Problem habe oder die 
Lochrasterkatastrophe wo alles funktioniert?

>
> Prosa-Schaltpläne und Prosa-Aufbauten sind hier nicht erwünscht.

Sorry, wat is Prosa?

>
> Da Prosa-Software auch nicht erwünscht ist wird man sich ggf
> später auch noch deine Sketch-Kreation anschauen müssen.

Nochmal Prosa...? Sketch Kreation? Du meinst den 3007 Zeilen Moloch 
(ohne Libraries)? ;-) Kann mir nicht vorstellen, dass da jemand Lust 
haben wird das zu debuggen. Eigentlich funktioniert auch das simpelste 
nRF Rcv/Snd Example nicht (mit dem gleichen Fehler), da tut meine 
Software dann eigentlich nicht viel zur Sache.

Habe die Bilder angehängt. Achtung, beim Board2.png bitte das File 
runterladen und nicht im Browser öffnen. Die Auflösung ist extrem hoch, 
damit man schön reinzoomen kann.

[Bastian W. (jackfrost)]

Hi,

Reduzier dein Programm auf das nötigste für beide NRFs ubd schau ob der 
Fehler noch da ist.

Du hast beide IRQ Leitungen zusammengefasst ? Das ist bei Push-Pull 
Ausgängen schlecht.

Solange kein Clock vom Master kommt macht der NRF nichts mit der MISO 
Leitung.

Wie äußern sich deine Störungen ? Lade eine Screenshot mal hoch.


Gruß JackFrost

[Bastian W. (jackfrost)]

Ich hatte mich getäuscht, immer wenn CS auf low geht legt der NRF das 
MSB vom Statusregister auf MISO.

Da beide auf dem selben CS liegen reagieren immer beide.

Ist das im LA sichtbar ?

Gruß JackFrost

[Arduinoquäler (Gast)]

Bastian W. schrieb:
> Du hast beide IRQ Leitungen zusammengefasst ? Das ist bei Push-Pull
> Ausgängen schlecht.

Das ist richtig! Der NRF hat keinen Open Drain Ausgang am
IRQ sondern zieht die Leitung runter und rauf. Das kann
schwierig werden....

Dann fällt mir auf die Schnelle noch auf dass ein 1000uF
Elko am Ausgang eines Spannungsreglers garantiert nichts
zu suchen hat, der Regler kann nämlich das nicht mehr gut
ausregeln. Richte dich nach den Empfehlungen des Herstellers.

[Arduinoquäler (Gast)]

Arduinoquäler schrieb:
> dass ein 1000uF
> Elko am Ausgang eines Spannungsreglers garantiert nichts
> zu suchen hat

Gilt auch für den 3.3V Regler der mit 330uF belastet ist.

[L. N. (derneumann)]

Hallo!

ich hatte vergessen zu erwähnen, dass es nicht vorgesehen ist zwei NRFs 
zu nutzen, es ist also immer nur einer der beiden NRF Header besetzt.

Das mit dem Spannungsregler wusste ich nicht, ich mwusste nur dass eine 
Schutzdiode hingehört und dass der Elko vorm Regler größer sein sollte 
als der dahinter, wobei das mit der Diode dann auch obsolet wäre.

Gruß

[Einer K. (Gast)]

Lucas N. schrieb:
> und da gibts
> Konflikte zwischen der SD Karten Lib und der nRF Lib die ich nutze
> (https://github.com/nRF24/RF24) betreffend den SPI Bus.

No!
Oder doch?

Bei mir spielen SD KArte und nRF super im Team.

Welche Konflikte plagen dich da?
Warum räumst du sie nicht aus?

[spess53 (Gast)]

Hi

Ich frage mich, warum du dieses Soft-Spi-Gedödel benutzt. Der ATMega2560 
hat im Extremfall 5 getrennte Hardware SPI, nämlich SPI und 4 mal USART 
im SPI-Mode. Von diesen vier USART-SPIs sind bei dir zwei komplett frei 
und bei der dritten müsste nur ein INT-Anschluss verschoben werden. Und 
bei den USART-SPIs hast du im Gegensatz zur SPI auch noch beim Lesen 
einen 3fach- und beim Schreiben einen 2fach-Puffer.

MfG Spess

[L. N. (derneumann)]

Arduino F. schrieb:
> Lucas N. schrieb:
>> und da gibts
>> Konflikte zwischen der SD Karten Lib und der nRF Lib die ich nutze
>> (https://github.com/nRF24/RF24) betreffend den SPI Bus.
>
> No!
> Oder doch?
>
> Bei mir spielen SD KArte und nRF super im Team.
>
> Welche Konflikte plagen dich da?
> Warum räumst du sie nicht aus?

Erwischt. Ich muss ehrlich zugeben, ich habe die Software vor ca. einem 
Jahr geschrieben und habe keine Ahnung mehr, was genau der Grund war. Ob 
es jetzt die NRF Lib in Verbindung mit dem Ethernet Modul, der SD Karte 
oder dem OLED war, weiß ich ehrlich nicht mehr. Damals habe ich auch auf 
einer Lochrasterplatine alles zusammengelötet und verwende das Ding 
seither als 10 Kanal LED Streifen Dimmer (2x RGBW/WW (links/rechts)) mit 
OLED Display, Buttons, SD Karte/Ethernet Modul für Webseite und NRF 
Modul für Funkfernbedienung sowie Raumtemparatur/Luftfeuchtigkeitssensor 
und Uhr mit RTC. Außerdem holt sich das Ding noch aus dem Internet 
aktuelle Wetterdaten und zeigt die am Display an.
Die Eierlegende Wollmilchsau also.

Ich wollte das nur mal in eine Platine gießen und bei der Gelegenheit 
gleich ein paar LEDs und USB Upload sowie einen ISP Header hinzufügen um 
das Teil auch als Entwicklungsplatine nutzbar zu machen.

Damals hatte ich bei Weitem weniger Ahnung als heute (steile Lernkurve 
und so), evtl. könnte ich das Problem heute ausräumen oder der Bug wurde 
sowieso schon in aktuelleren Lib Versionen ausgemerzt.

spess53 schrieb:
> Ich frage mich, warum du dieses Soft-Spi-Gedödel benutzt. Der ATMega2560
> hat im Extremfall 5 getrennte Hardware SPI, nämlich SPI und 4 mal USART
> im SPI-Mode. Von diesen vier USART-SPIs sind bei dir zwei komplett frei
> und bei der dritten müsste nur ein INT-Anschluss verschoben werden. Und
> bei den USART-SPIs hast du im Gegensatz zur SPI auch noch beim Lesen
> einen 3fach- und beim Schreiben einen 2fach-Puffer.

Weißt du zufällig, ob das auch mit dem Arduino Core geht? Wenn nicht, 
schau ich selber nach. Im Endeffekt muss ich mir das Gegebenenfalls 
sowieso genau anschauen.

Gut, ich denke wenn ich auf Software SPI verzichte und das mit einem der 
HW SPIs löse (oder auch alles auf einen SPI Bus packen kann), löst sich 
dieses Problem von selbst.

Allerdings hätte ich mir trotzdem von dem Thread erhofft, einige Tipps 
zu bekommen was die Störungen betrifft da ich doch theoretisch auch bei 
HW SPI über solche Probleme stolpern könnte und einfach gerne möglichst 
viel besser machen würde in meiner nächsten Revision dieser Platine, 
bevor ich sie wieder fertigen lasse.
Zum Beispiel die Widerstände in Serie direkt beim µC erscheinen mir 
sinnvoll?!

Nochmal zum Spannungsregler: Trifft das mit dem Elko am Ausgang auch 
dann zu, wenn da doch immer eine Last dranhängt? Kann dieser 1000µF Elko 
am Ausgang mit eine Rolle bei diesem Problem spielen oder war das ein 
genereller Hinweis auf einen Fehler?

Zumindest laut Multimeter ist die Spannung immer dort wo sie sein soll, 
mag daran liegen, dass der Regler wohl nicht viel nachzuregeln hat, da 
sich die Last und die Versorgungsspannung nur wenig ändern.

Ich weiß, das sind sehr viele Fragen und wenn ich in der Zeit 
zurückreisen könnte, hätte ich eine entsprechende Ausbildung gewählt. 
Leider ist es dafür heute zu spät und ich muss mich so durchboxen.

Danke für eure Zeit!

[Arduinoquäler (Gast)]

Lucas N. schrieb:
> Nochmal zum Spannungsregler:

Das klingt schon stark nach Beratungsresistenz.
Beim Abblocken des NRF24 fällt das auch schon auf.

Bei soviel Selbstüberzeugung bin ich dann raus.

[L. N. (derneumann)]

Arduinoquäler schrieb:
> Lucas N. schrieb:
>> Nochmal zum Spannungsregler:
>
> Das klingt schon stark nach Beratungsresistenz.
> Beim Abblocken des NRF24 fällt das auch schon auf.
>
> Bei soviel Selbstüberzeugung bin ich dann raus.

sorry wenn das so rüberkommt, ich versuche nur zu fragen und zu lernen 
und hinterfrage halt sehr viel weil ich es genau wissen will.

[spess53 (Gast)]

Hi

>Weißt du zufällig, ob das auch mit dem Arduino Core geht?

Weis ich nicht, da ich mit den Arduino-Gedödel nichts anfangen kann. 
Dieses Arduino-Mega-dings-bums mit dem ATMega2560 ist jedenfalls von 
dieser Möglichkeit komplett befreit, da die XCK Anschlüsse der USARTs 
nicht beschaltet sind. In dieser Beziehung eine komplette 
Fehlkonstruktion.

MfG Spess

[L. N. (derneumann)]

spess53 schrieb:
> Hi
>
>>Weißt du zufällig, ob das auch mit dem Arduino Core geht?
>
> Weis ich nicht, da ich mit den Arduino-Gedödel nichts anfangen kann.
> Dieses Arduino-Mega-dings-bums mit dem ATMega2560 ist jedenfalls von
> dieser Möglichkeit komplett befreit, da die XCK Anschlüsse der USARTs
> nicht beschaltet sind. In dieser Beziehung eine komplette
> Fehlkonstruktion.
>
> MfG Spess

Ja, habe in der Zwischenzeit auch schon ein bisschen recherchiert, das 
scheint mit dem Arduino Core so von Haus aus mal nicht zu gehen 
(abgesehen davon, dass die Pins gar nicht ausgeführt sind). Es spricht 
aber nichts dagegen, die benötigten Pins auf meiner Platine auszuführen 
und dann mal zu versuchen das in Software zu implementieren.
Danke jedenfalls für den Tipp.

Wenn ich das Problem mit den SPI Konflikten, wenn alles an einem SPI 
hängt,
 durch Nutzung aktueller Library Versionen (oder durch eigenständige 
Fehlersuche) beheben kann, erübrigt sich der zweite SPI ja. Wenn aber 
nicht, dann werde ich das auf jeden Fall probieren.

[Stephan (Gast)]

spess53 schrieb:
> Ich frage mich, warum du dieses Soft-Spi-Gedödel benutzt.

die par Bits im Gänsemarsch zu schubbsen, macht nicht mehr Mühe als 
irgendwelche Konfigregister erst mal zu konfigurieren und mit Daten zu 
füttern bis der µC die Daten dann "allein" senden kann.

[Peter D. (peda)]

Lucas N. schrieb:
> Kann dieser 1000µF Elko
> am Ausgang mit eine Rolle bei diesem Problem spielen

Nein.
Ich habe es noch nie erlebt, daß ein Spannungsregler wegen zu großem 
Elko Probleme macht.
Aber ich habe es schon oft erlebt, wenn man nur die Minimalwerte nimmt, 
daß dann Störspitzen einfach über den Spannungsregler springen und die 
nachfolgende Schaltung killen.
Insbesondere im KFZ ist ein dicker Elko überlebenswichtig, wenn man 
nicht riesen Drosseln am Eingang hat.
Spannungsregler sind nämlich nicht gerade schnell, das Ausregeln von 
Transienten ist daher nicht ihr Ding.

[spess53 (Gast)]

Hi

>die par Bits im Gänsemarsch zu schubbsen, macht nicht mehr Mühe als
>irgendwelche Konfigregister erst mal zu konfigurieren und mit Daten zu
>füttern bis der µC die Daten dann "allein" senden kann.

Die Konfiguration ist einmalig (in C genau fünf Register zu 
beschreiben). Beim Bitschubsen hast du bei jedem Byte mindestens 24 
Zugriffe auf die beteiligten Register. Die Zugriffe für das Timing gar 
nicht mit gerechnet. Da dürfte bei der bekannten Arduino-Performance ein 
Verhältnis von 1:100 oder größer herauskommen.

MfG Spess