wie im Threadtitel beschrieben hab ich einen Mega2560 und ein Ethernetshield. So eins vom Chinamann mit SD-Slot.
Ich hab da eine größere Software am Laufen, und bin jetzt hoffentlich am Ende einer 2-tägigen Fehlersuche.
Ich nutze das Shield nur im Ethernet-Modus. SD ist nicht programmiert.
Irgendwann hat das ganze System angefangen zu spinnen: undefinierter Neustart des Arduino, dann kamen über die EthernetSchnittstelle (TCP-Telegramme) nur noch wirre Zeichen rein.
Aber alles nicht reproduzierbar und nur sporadisch.
Irgendwann ist mir eingefallen, dass ich Anfangs eine SD-Karte im Slot hatte. Aber die hab ich gezogen, weil ich sie ja eh nicht verwende. Und das war dann genau der Zeitpunkt, ab dem die Probleme anfingen. OK..... was hat die SD-Karte mit den Ethernet-problemen und den Neustarts zu tun?? Keine Ahnung. Aber mit Karte: alles OK und ohne Karte: Probleme.
IDEE:
Da beide Module (Ethernet und SD) auf dem selben Shield sind, hab ich dann in meiner Software den CS vom Ethernet als Ausgang definiert und dauerhaft auf Low gezogen.
Damit läufts jetzt auch ohne SD-Karte. Momentan...
Ich hoffe ich hab den Fehler auch wirklich gefunden.
So viel zur Geschichte.
Ich wollte jetzt nur mal die Profis fragen, ob das alles nachvollziehbar und logisch ist? Oder seit ihr da selber schon mal drüber gestolpert?
Eigentlich dachte ich immer, dass sich die Ethernet-lib auch um das CS-Signal kümmert.
Hallo hk007.
Ich habe auch so ein China Ethernetshield, meines funktioniert aber tadellos.
Bevor ich das Ding bestellt habe, habe ich informiert ob es damit Probleme gibt.
Also ob ich doch lieber ein Orginal kaufen soll.
Bei dieser recherche habe ich gelesen, das es bei machen China Clones ein Lötproblem am SPI Verbinder gibt.
Schau dir mal den 6 Poligen Stecker an ob der sauber verlötet ist.
Hallo Ihr,
das Problem ist nicht die Lötung sondern die zu kurzen Pins welche beim Original länger sind.
Den Effekt der undefinierten Fehler ohne SD Karte kenne ich auch. Meiner Vermutung: Wenn beide CS aktiv sind durch undefinierte Leitungen (offen) werden zeitweilig vom "falschen" Teilnehmer Daten zurückgesendet und der SPI funzt nicht mehr richtig.
Ich habe ausserdem festgestellt, dass die chinaclones trotz selbem chip unzuverlässiger laufen.
Ausserdem funktioniert auch der Orginale schlechter (langsamer) ohne SD Karte trotz korrektem CS handling. Das sieht man besonders bei den Antwortzeiten bei Nutzung als Webserver.
das Problem ist nicht die Lötung sondern die zu kurzen Pins welche beim Original länger sind.
Ok - die Pins sind kürzer - Bzw. sind diese vor dem Löten nicht weit genug in die Platine gesteckt worden.
Meist reicht es aus, die Pin nachzulöten oder wenn sie wirklich nicht weit genug drinstecken das ganze mit einer Lötsaugpumpe zu lösen und ausreichend weit in die Platine zu stecken.
Im Endeffekt ist es ein Kontaktproblem, ich denke wenn der Fragesteller hier einen Blick draufwirft ist er schon mal weiter.
Das Problem mit CS der SD Karte und SS Pin W5100 sollte die Lib regeln, evtl. wurde eine alte Version benutzt
danke für eure Antworten.
Thema kurze Pins: Das Problem schliesse ich immer von vornherein aus, da ich bei den Ethernet-Shields die Buchsenleisten auslöte und gegen etwas längere tausche. Damit die Ethernet-Buchse garantiert nicht auf der USB-Buchse klebt. Dabei tausche ich auch immer den ISCP-Header.
Irgendwie war auch die "Lösung" mit der SD-Karte, bzw. das Aktivieren der CS-Leitung nicht der Weisheit letzter Schluss.
Ich schäm mich fast, aber es war ein Programmierfehler. Ich hab in einer Subroutine noch Daten von der seriellen Schnittstelle in ein Bytearray (>1500 Byte) geschrieben, und vergessen den Pointer nach einem Zyklus wieder auf "0" zu stellen. Das hat dann die unverständlichen Aktionen, irgendwann einen Überlauf ausgelöst, und den Arduino neu gestartet. Das Unterprogramm hatte ich nie in Verdacht, da ich es aus einem alten bewährten Projekt kopiert hatte. Leider war ich beim Kopieren des Aufrufs etwas schlampig =(
Ja, wär aber schön, wenn man solche Fehler irgendwie "debuggen" könnte.
Wenn ein Pointer nicht dorthin zeigt wo er zeigen soll, ist das debuggen immer schwierig.
Auch beim Entwickeln z.b unter Windows:
Meist kackt die Anwendung einfach ab, oder wie hier die ganze "Maschine" (Arduino).
Deshalb finde ich Pascal/Delphi gar nicht so schlecht, man kann dort mit Pointer arbeiten, man muss es aber nicht.
In C geht es nicht ohne Pointer, was ja auch kein Problem ist - aber die Gefahr hier Bugs einzubauen ist einfach größer.