Hallo,
Ich habe schon etwas länger gesucht, finde aber leider nichts
aussagekräftiges..
Momentan habe ich den AVRISP MK2, mit dem ich natürlich nicht debuggen
kann oder ähnliches. Ich müsste dann usart nutzen usw.
Der Atmel-ICE scheint ja der Nachfolger zu sein, zumindest schreibt
Atmel es so und der kann debugging.
Meine Frage wäre, kann ich sowas nutzen wie
console.log (schlechtes Beispiel, aber wem JavaScript geläufig ist kennt
es), dass mir dann zur Runtime etwas ausgegeben wird?
Als Beispiel wäre da etwas aus dem EEPROM. Dort werden Werte flexibel
gespeichert. Über einen Befehl im Code möchte ich mir anzeigen lassen,
was dort drin steht. Als Beispiel hätte ich den Codd zum Ausgeben in
while(1) { also im Cyclischen Ablauf.
Oder brauche ich da ein Experimentier-Board??
Wäre nett wenn mir da jemand kurz sein Wissen vermitteln könnte.
Danke !!
Zum Debuggen brauchst du einen Atmel ICE oder Atmel Dragon (ich könnte Dir meinen Dragon verkaufen). Das Ausgeben von Log-Meldungen ist ebenfalls eine gängige Methode. Ich habe sie hier beschrieben: http://stefanfrings.de/avr_hello_world/index.html Sowohl Atmel ICE als auch Dragon können keine Logmeldungen ausgeben. Dazu brauchst du einen I/O Pin, der mit einem USB-UART Adapter verbunden ist. > Oder brauche ich da ein Experimentier-Board?? Nein
Hallo Stefanus, Vielen Dank für deine ausführliche Antwort mit einem detaillierten Versuchsaufbau. Wenn ich es aus deiner Seite richtig interpretiere, gehst du dort auf unterschiedliche Dinge ein. Ich habe es nun so verstanden, dass ich weiterhin mit Atmel Studio 7 Flashen kann und dazu dann ein Terminal-Fenster für die UART-Meldungen habe, richtig? Wäre dieser Adapter der richtige: https://www.amazon.de/Sumind-Packung-Programmierung-Serielles-Unterstützt/dp/B01N4X3BJB/ref=mp_s_a_1_5?__mk_de_DE=ÅMÅZÕÑ&qid=1538405291&sr=8-5&refinements=p_76%3A419123031&rps=1&pi=AC_SX236_SY340_QL65&keywords=usb+uart&dpPl=1&dpID=51cMyCjCgjL&ref=plSrch Ich hoffe das Hyperlinks dieser Art erlaubt sind. Falls nicht entschuldige ich mich jetzt schon mal. Diesen Adapter einfach am USB Einstecken und die Kabel wie folgt anschließen: Rot +5v Schwarz GND Weiß RXD Grün TXD Am Beispiel des Atmega32 sollte die Belegung bzw. Das abgreifen der Signale auf diesen Pins korrekt sein: Rot +5v = PIN 30 AVCC Schwarz GND = PIN 31 GND Weiß RXD = PIN 14 / PD0 RXD Grün TXD = PIN 15 / PD1 TXD Wobei natürlich die Spannungsversorgung auch irgendwo anders abgegriffen werden kann. Und schon kann ich am PC die USART Meldungen empfangen? Danke schön !!
Stephan B. schrieb: > Wenn ich es aus deiner Seite richtig interpretiere, gehst du dort auf > unterschiedliche Dinge ein. Ich habe es nun so verstanden, dass ich > weiterhin mit Atmel Studio 7 Flashen kann und dazu dann ein > Terminal-Fenster für die UART-Meldungen habe, richtig? Ja richtig. > Wäre dieser Adapter der richtige Wenn den kannst nehmen. > Diesen Adapter einfach am USB Einstecken und die Kabel wie folgt > anschließen... Du brauchst nur zwei Leitungen anzuschließen und es ist wichtig, RxD und TxD über Kreuz zu verbinden. GND und Weiß RxD = PIN 15 / PD1 TXD RxD ist ein Eingang aus Sicht des jeweiligen Gerätes. TxD ist ein Ausgang aus Sicht des jeweiligen Gerätes. Du willst vom µC an den Computer senden, als vom µC TxD zum Computer RxD. Die 5V Leitung solltest du besser nicht verwenden, weil das aus Sicht des Kabels ein Ausgang ist. Du wirst deine Schaltung nämlich übe rein anderes Netzteil oder Batterie versorgen (zumindest würde ich dringend dazu raten). > Und schon kann ich am PC die USART Meldungen empfangen? Ja
Angehängte Dateien:
-
HTERM.jpg
320 KB
Hallo, Vielen dank für deine Antwort. Ich habe jetzt das USB-USART Kabel hier liegen. Habe mir als Software HTerm 0.8.1beta geladen und gestartet. Dann wird mir als neuer COM-Port COM4 angezeigt, welcher identisch mit dem USB-Kabel ist. Habe Schwarz auf GND gelegt und Grün/Weiß auf Pin 14/15. HTerm habe ich Verbunden und es wird mir auch immer wieder Rx angezeigt. Der Rx-Counter steigt zyklisch und bei Received-Data stehen Daten drin. Jedoch sowas in der Art wie auf dem Screenshot. Wenn ich Weiß und Grün tausche, passiert nichts mehr. Also müsste es prinzipiell Stimmen. Wie finde ich am besten raus was da das problem ist? DANKE !!
> Wie finde ich am besten raus was da das problem ist?
Trenne das Kabel vom Mikrocontroller ab und verbinde dessen Rx mit Tx.
Sende einen Text, der müsste dann wie ein Echo wieder zurück kommen.
Wenn das nicht funktioniert, könnte das USB-UART Kabel defekt sein.
Wenn das funktioniert, stimmt die eingestellt Baudrate nicht mit dem
Mikrocontroller überein.
Die häufigste Ursache ist, dass die Taktfrequenz des µC nicht mit der
F_CPU Einstellung überein stimmt. Kontrolliere die Fuses für den
Taktgeber, auch die CLKDIV8 Fuse.
Falls das nicht hilft, wäre es wohl Zeit ein Foto vom Aufbau und den
Quelltext zu zeigen.
Hallo, Ich habe auch an die Fuses gedacht. Habe dazu dann mal ein neues Thema erstellt: Beitrag "Fuses falsch eingestellt Keine Reaktion mehr vom Controller" Weil es nur indirekt was mit diesem Thema zu tun hat. Habe mir den jetzt wohl falsch Konfiguriert. Im Programm ist nämlich 16MHZ eingestellt (F_CPU). Der Controller arbeitet aber mit 1MHZ. Also das kann es tatsächlich sein... Vielleicht kann ich meinen yC ja noch retten....
Hallo Stefanus, Vielen dank für deine schnelle / super Hilfe. Habe nun die Serielle Übertragung laufen. Es kommen zwar zu jedem Text den ich sende auch kryptische Zeichen mit, aber nur am Anfang und am Ende eines jeden Textes. Das ist nicht das Thema. So ist es perfekt und ich habe das Skript am laufen. SAUBER DANKE !!
Stephan B. schrieb: > Es kommen zwar zu jedem Text den ich sende auch kryptische Zeichen mit, > aber nur am Anfang und am Ende eines jeden Textes. Das könnte daran liegen, dass der interne R/C Oszillator deines Mikrocontrollers die Frequenz nicht genau genug einhält. Für serielle Kommunikation wird ein Quarz empfohlen, idealerweise einer mit 7,3728 MHz, denn damit kannst du alle gängigen Baudraten exakt erzeugen. Eventuell handelt es sich auch um einen Programmfehler. Zeige mal die kryptischen Zeichen als Hexadezimal-Zahlen an, mache davon einen Screenshot und zeige deinen Quelltext. Am Besten reduzierst du das Programm auf möglichst wenige Zeilen, die das Problem auslösen.
Hallo, Vielen dank für alle Antworten. Habe leider nicht immer so viel Zeit für yC wie ich gerne hätte. Ist eben nur ein Hobby. Hab es mit eurer Hilfe jetzt hinbekommen, der Atmega32 lief problemlos inkl. Serieller Debug-Ausgabe. Alles super. Habe dann wegen Speicherplatz auf einen Atmega644-20PU gewechselt. Seitdem bekomme ich über die Serielle Schnittstelle wieder nur Müll rein. Habe dort eingestellt: Ext. Crystal Osc. 8.0- MHZ;Start-up time: 16K CK + 65ms Das Programm ist 1:1 gleich geblieben. Auch der Versuchsaufbau 1:1 identisch. Habe dann nochmal auf den Atmega32 gewechselt und dort keine Probleme mit Serieller Datenübertragung. Nochmals auf den 644 Gewechselt und wieder nur Müll Seriell. Jemand eine Idee dazu? Beide Atmega32 ist auch eingestellt auf Ext. Crystal. und der Quartz funktioniert... Jemand spontan eine Vermutung? Danke !!!
Hast du eventuell vergessen, die CLKDIV8 Fuse aus zu schalten? Hast du eventuell den ATmega644P mit dem ATmega644PA verwechselt? Hast du eventuell für den falschen ATmega compiliert? Achte mal auf "-mmcu=xxxx" in den Logmeldungen des Compilers.
Hallo, Peinlich.... Danke... CKDIV8 war aktiv. Was bedeutet, dass die eingestellte Frequenz durch 8 geteilt wird. Dann haut es natürlich nicht mehr hin mit dem Seriellen Bus... Danke erneut vielmals !!!!
Thread beobachten
Seitenaufteilung abschaltenBitte 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.