Guten Tag,
gestern Abend funktionierte die Serial.println() methode noch ohne Probleme.
Als ich heute aber an ein einem Projekt weiter arbeiten wollte war die Serial.println methode ohne funktion, das Board wurde aber richtig erkannt.
Daraufhin wollte ich dies mit einem einfachen code testen (s.h. unten) was allerdings eben so erfolglos blieb.
Danach habe ich im Internet noch was zu einem Loopback-Test gefunden welchen ich dann durchführte und so zu einem Positiven Ergebniss kam ( sprich : was ich dann in den Serial Monitor eingab wurde mir so auch von ihm wieder gegeben).
Baudraten passen auch.
Hinzuzufügen währe noch dass sporadisch zwar eine ausgabe im Serial Monitor kommt, diese allerdings Kryptisch sind und zeitlich (a.h. des gesetzen delays) nichtpassen.
Vielleicht kann mir Hier ja jmd. Helfen
Eckdaten :
Board: Elegoo MEGA 2560 (erst ein paar tage alt)
über COM3
OS : Windows 10
IDE: Arduino2.2.1
Baudraten in : Sketch , Serial Monitor und ltd. Gerätemanager alle bei 9600baud ( s.h. Sketch)
Hier der einfache code welchen ich zum Testen verwende:
Bau dir eine Portable IDE 1.8.19, und wenn bei der funktioniert ist das die xx Macke der 2.2.1 IDE unter Windows 10.
Die Portable kollidiert nicht mit deine 2xx IDE, kann auch auf USB Stick gebaut werden.
Ich schätze mal am Arduino
Als gestern noch alles ok war : 1x Arduino MEGA Prototype Shield v3; 1x 74HC595 Schieberegister an welches 8 LED´s samt Widerstände angeschlossen waren & ein knopf zum Starten
Wenn der Loopback geht und Deine Eingabe 1:1 auch eine Ausgabe erzeugt, aber alle eingebauten Ausgaben nicht auf dem SerMon erscheinen, dann ist was richtig faul.
Ich würde ja auf ein Problem mit der Schnittstelle tippen, aber das wird alles nur stochern im Nebel.
Hast Du einen anderen Rechner/Laptop, an dem Du den mal anstecken kannst und entweder eine (portable) IDE oder ein Terminalprogramm nutzen kannst?
Dann würde ich den da anstecken, terminalprogramm starten, alles richtig einstellen, am Mega reset drücken udn abwarten, was passiert...
Wen bei der 1.8.9 IDE das gleiche dann nur Vermutung, wenn dir das jedoch öfter passiert dann das Board tauschen, kalt Lötstelle oder ähnlich, merkt man erst später.
Bei Hersteller Board kurz getestet, Blink Sketch drauf, funktioniert ab in Verkauf. bei CN Leuten ist jede Sekunde Teuer. Bei Fehler tauschen ist für die billiger als ausgiebig testen
Du machst mich sprachlos mit Deinem Problem.
Ich habe da keine logische Lösung.
Also etwas herumgesucht. Der Elegoo Mega 2560hat als USB Adapter einen ATmega16U2
Also ist das TX RX Led nicht auf den Pins D0 und D1 sondern wird von 16U2 über Ausgänge angesteuert.
Versuch mal an D0 und D1 je eine LED mit 1 kOhm Vorwiderstand zu hängen. Wenn die Komunikation zwischen ATmega 2560 Controller und Atmega16U2 funktioniert, dann müßten diese LED flackern. Ich gleube das müßte funktionieren da sonst der Loopback test nicht funktioniert.
Hast Du mal versucht im Terminal was zu schreiben und auf den MEGA zu senden? Flackert da das RX LED?
Ich nehme mal an daß der schaltplan weitgehend dem Orginal Arduino Mega 2560 R3 entspricht.
Ich würde gerne mal den ATmega16U2 resetieren. Die einzige Möglichkeit dazu ist der ICSP Header des ATmega16U2 (die 3x2 pins neben der USB Buchse). Da sind Pin 5 und 6 (die beiden linken Pins) kurz mit etwas Metallischem kurzzuschließen. Auf dem MEGA sollten die Pins gleich wie auf dem UNO auf dem Foto sein.
Ja, wenn da aber kein Programmiere dranhängt, der antwortet, wird nach einer kurzen Wartezeit auf die normale Frimware-Routine für die USB Komunikation gewechselt. Das passiert ja (normalerweise) beim "Einschalten" des MEGA2560.
Fehlendes RX/TX-LED-aufblinken und das Nichtversenden von Daten an den PC über USB könnte an einen blockierten ATmega16U2 denken lassen, der durch einen nicht richtigt erfolgten Power on Reset irgendwo in der Firmware stecken geblieben ist. Ein manueller Reset würde da helfen. Der Resettaster des MEGA2560 resetiert nur den ATmega2560, aber nicht den ATmega16U2. Darum der Vorschlag für den ICSP. Header.
aber würde dies nicht auch automatisch dann geschehen, wenn man das Board mal kurz (1-2 Minuten, damit sich evt. kondensatoren am 16u2 entladen) vom Strom (auch vom USB) nimmt? Dann sollte der 16u2 doch auch ein Power on Reset machen? Oder behällt dieser Controler seinen vorhrigen Status im stromlosen Zustand bei?
Wenn es da einen Timeout gibt, dann ist der mir noch nicht aufgefallen.
Und gerade mal einen Test gemacht.
ca 5 Minuten, und kein Rücksturz in die Anwendung.
(das Datenblatt sollte das final beantworten können)
Nach einem Power on Reset wird die Anwendung auf dem 16U2 gestartet.
Bei einem Hardwarereset wird der HardwareBootloader gestartet
Ist auch problemlos zu überprüfen!
Power on
COM Port erscheint im Gerätemanager.
Reset betätigen
COM verschwindet
ATMEL16U2 erscheint im Gerätemanager
Auch ein weiterer Reset kann daran nichts ändern
COM bleibt verschwunden, bis man per FLIP ein Programm hochgeladen hat, oder einen PoweronReset macht
Ein Programmer ist nicht nötig, Flip ist eine Software (ehemals Atmel Flip) welche einige AVR direkt über USB oder CAN beschreiben kann. Der 16U2 gehört dazu.
Habe ich etwas drüber schon beantwortet.
Klar, behält er Flash, EEPROM und Fuses, aber sonst auch nix.
Es müßte ein automatischer RESET bei Aktivierung der Spannungsversorgung ausgeführt werden. Nach dem Ausschalten ( zb abklemmen von der USB-Buchse uder ander Spannungsfrei machen) müßte jeder Controller spannungsfrei werden. Nach dem Wiederherstellen der Versorgungsspannung müßte ein Power on Reset ausgeführt werden. Der Conroller hat keine Gedächtnisfunktion, um dort weiterzumachen wo er vor dem Sapnnungsausfall war.
Ich hab es aber schon wiederholbar erreicht, daß wenn die Versorgungsspannung sehr langsam steigt, daß der Reset nicht richtig ausgeführt wird.
Meine Vorschläge sind dazu da, zu verstehen was da nicht funktioniert.
erstmal Danke für die ausführliche erklärung
also, hänge ich nun je eine LED (samt vorwiderstand) an RX0(Pin 0) & TX0(Pin 1) flackern die zum einem beim starten des Arduinos, beim aufspielen eines neuen Sketches und beim manuellen eingeben in den SM.
Blockzitat
ich würde gerne mal den ATmega16U2 resetieren. Die einzige Möglichkeit dazu ist der ICSP Header des ATmega16U2 (die 3x2 pins neben der USB Buchse). Da sind Pin 5 und 6 (die beiden linken Pins) kurz mit etwas Metallischem kurzzuschließen. Auf dem MEGA sollten die Pins gleich wie auf dem UNO auf dem Foto sein.Mach das mal bei dem MEGA 2560 der am USB des PCs hängt. Öffne das Terminal und machst dann ein Reset.
Brücke ich nun diese beiden Pins bei angeschlossenem MEGA und geöffnetem SM, so disconnected sich der MEAG , wird allerdings gleich darauf als "Unbekanntes Gerät" im Gerätemanager erkannt. Ziehe ich nun den USb ab und hänge ihn danach gleich wieder dran so wird das MEGA wieder als solches erkannt.
Daraufhin habe ich den code einmal um eine if-schleife mit der bedingung des zur verfügung stehendem Serial.begin und einer Test LED erweitert (s.h. code). Die LED blieb allerdings auch aus, was meines erachtens nach darauf schließen lässt dass die Serielle kommunikation garnicht erst aufgebaut wird.
int testLED = 6;
void setup(){
pinMode(testLED, OUTPUT);
Serial.begin(9600);
delay(250);
if(Serial.available() > 0){
Serial.println("setup");
digitalWrite(testLED, HIGH); // Test LED an
delay(500);
digitalWrite(testLED, LOW); // Test LED aus
}
}
void loop(){
Serial.println("Loop");
delay(250);
}
