Hallo, ich bin durch diese Seite auf die Idee gekommen überhaupt anzufangen mit Mikrocontrollern zu basteln. (interessant->Danke!) Leider fange ich gerade an und habe ein Problem. Ich habe eine LED an den Ausgang von Port A angeschlossen, die blinken soll. Als Quarz dient ein 8 MHz bzw. später 16 MHz - Oscillator. Ohne das ich die Bits gesetzt habe, konnte ich nur programmieren, aber nichts tat sich. Als ich die CLK-Bits richtig auf den externen Quarz einstelle, blinkte die LED erfreulicherweise. Also mit "slowly rising power" lief das Ganze. Nun hatte ich etwas rumgespielt und mal "fast rising power" ausprobiert. Leider ging dann nichts mehr so, wie ich wollte, als ich das Bit wieder zurückgesetzt habe bekam ich einen "missing device error". Eingestellt habe ich das Ganze mit Ponyprog. Und nun blinkt weder die LED, noch kann ich irgendwie was programmieren oder lesen. Habe ich irgendeine Möglichkeit da wieder zuzugreifen oder muss ich den ATmega jetzt wegwerfen? Wäre ja echt blöde. Danke für die Hilfe!
Hallo Ronny, also, bei den diversen fuses kann man sich beim Rumspielen leider auch ganz böse ins Knie schießen. Es kann sein, dass der Chip dann nur noch mittels des parallelen Programmiermodus zum Leben erweckt werden kann (spezieller Programmieradapter notwendig, z.B. STK500). Es gibt hier auch diverse alternative Tipps, die von separater Taktquelle niedriger Frequenz bis zur Verringerung der Versorgungsspannung gehen. Mangels eigener Erfahrung kann ich aber nichts dazu sagen; mußt Du mal die Suchfunktion des Forums bemühen. Gruß, Frank
Danke. Bisher hat es zwar noch nichts geklappt. Aber immerhin aber ich schon ein paar Anhaltspunkte gefunden.
Ich habe mir jetzt noch einen neuen geholt. Da habe ich die Bits auch noch einmal gesetzt. Aber laufen will der jetzt auch nicht mehr. Ich kann mir doch nicht ständig einen neuen Controller holen, bloss weil da was mit den Bits nicht stimmt. Also kurz: Ich kann den jetzt auch nicht mehr ansprechen. Ich denke wohl die ATMEL-Dinger sind nicht so der Hit. Momentan sieht das bei mir so aus (Ponyprog): 0 = angehakt, 1 = nicht angehakt OCDEN: 1 JTAGEN: 0 SPIEN: 0 (nicht änderbar) CKOPT: 1 EESAVE: 1 BOOTSZ1: 0 BOOTSZ0: 0 BOOTRST: 1 BODLEVEL: 1 BODEN: 1 SUT1: 1 SUT0: 1 CKSEL3: 1 CKSEL2: 1 CKSEL1: 1 CKSEL0: 1 Und laut Datenblatt sollte das so stimmen für einen externen 8MHz-Quarz: CKOPT: 1 (3 - 8 MHz) CKSEL3..1: 111 (3 - 8 MHz) CKSEL0: 1 (Crystal Oscillator, slowly rising power) SUT1..0: 11 (Crystal Oscillator, slowly rising power) Wo kann der Fehler liegen?
Hallo Ronny, ich hatte auch vor kurzem das Problem, das ich nicht wusste, wie ich die Bits zu setzen hab. Laut Datenblatt Seite 26 ganz unten sollte es wie folgt gesetzt werden: CLK3..0 0101 SUT habe ich auf SUT 10 stehen. Klappt wunderbar. Was hier noch fehlt im Tutorial ist eventuell nochmal eine Zusammenfassung mit Screenshot, ähnlich wie für den Mega8. Was mich auch verwirrt hat war, ob laut Datenblatt, wenn da eine 1 steht unter Ponyprog der Hacken gesetzt werden muss oder nicht. Weil irgendwas war da mit invertiert usw. Ich bin mir zwar nicht sicher, ob die Einstellung jetzt bei mir korrekt, aber es funktioniert. Zumindest mit dem externen Quarz. MfG, Andre.
Laut den Datenblättern hast Du den mit einem RC-Glied als Oscillator betrieben. Hast Du ein solches dran oder einen normalen Quarz? Naja der Ganze Mist ist, dass es keine einfache Möglichkeit gibt, das wieder zurückzusetzen. Der letztere der ATmegas von beiden lies sich sogar ab und an mal etwas ansprechen, aber es kamen immer fehlerhafte Daten rüber. Aber jetzt geht auch der nicht mehr.... Ich glaube das größte Problem sind wirklich die Fuse-Bits bei der ganzen ATMEL-Sache. Da sollte man wohl ein extra Kapitel im Tutorial zu schreiben ...
Ich betreibe den mit einem Quarzoszilator. Hmm, hab auch gerade wieder bemerkt, das ich dann einen Fehler haben dürfte. Bei einem Quarzoszilator sollte ich alle CLK Bits löschen.... :-) Und ich habe gedacht, das ein RC Ozsi fast das gleiche wäre. :-) Gruß eines Anfängers. :-)
>> Ich denke wohl die ATMEL-Dinger sind nicht so der Hit.
... sprach der Führerschein-Neuling als er aus dem Formel-1-Boliden
stieg.
Gruß, Frank
ja, das mit den fuses ist echt mist. gibts denn keine übersicht,welche gelöscht/gesetzt werden sollten, damit alle pins als i/o genutzt werden können, mit einem externem standart-quarz gearbeitet werden kann? ich brauch ja kein jtag und was es noch so alles gibt..
Leute, könnt Ihr nicht endlich mal einen Club der Ponyprog-Geschädigten aufmachen? Leider lernen die Leute offenbar nicht draus. So viele flsach gesetzte Fusebits, die das Teil mit seiner offenbar negierten Logik schon verursacht hat, das wäre doch fast ein eigenes Forum hier wert... Ronny, wenn Du Dich mal durch die existierenden Threads zum Thema wühlst, solltest Du auch genügend Anleitungen finden, wie man den Chip (mit externem Takt) dann wiederbelebt. Danach schmeiß Ponyprog endlich weg. Es gibt genügend freie Programiersoftware.
Ja ich habe mir die ja schon durchgelesen. Nur hat man zu Hause nicht so alle Möglichkeiten zur Hand. Heute werde ich mir mal einen Oscillator holen, den ich dann mal ranhauen kann. Ponyprog ist doch auch frei. Und andere Software, die auch den ATmega16 unterstützt, kenne ich nicht. Und das Problem mit den Bits ist, dass ich eigentlich wieder die gleichen, wie oben beschrieben, einstellen würde, da ich mir keines Fehlers bewusst bin - zumindest laut Dokumentation.
Hallo Leute, zusammenfassend kann man doch sagen : - Bei PonyProg heißt "Häkchen im Kästchen" "Bit programmiert" - In der AVR-Dokumentation heißt "Bit programmiert" "0" (steht da übrigens auch drin, schaut ruhig nach) - Bevor Ihr das Pony beschimpft : Erst Freeware holen und dann motzen - ist nicht ganz gerecht, außerdem kann man ja gut nachvollziehen, warum so die Notation so gewähhlt wurde. Wie oben gesagt ist da eher die AVR-Dokumentation etwas ungeschickt mit ihrer 0 als "programmiert". Das wiederum ist auch keine Beschimpfung wert, das hat Hardware-Implementationsgründe (wen's interessiert, der sehe sich mal an, wie EEPROM und FLASH funktioniert, dann versteht man auch, wieso "programmierte" Zellen mit einer 0 belegt werden) - Quarze mit 2 Beinen sind crystal oszillators und werden dann auch bei den CKSELs so behandelt. - Quarze mit 4 Beinen (n.c., Vcc, Gnd, Signal) sind EXTERNAL CLOCKS und werden dann auch nach Tabelle so behandelt. Die letzten beiden Sachen glaubt mir hier eh niemand, dazu habe ich schon genug threads laufen. Falls jemand dazu Fragen hat, möge er mich trotzdem gerne fragen, denn ich habe mich in letzter Zeit aus eigener leidvoller Erfahrung damit befasst. MfG, Daniel. P.S.: Gibt's eigentlich schon ein schriftliches Dokument über die Fuses zum "Betakten" von AVRs (insbesondere dem mega8) ? Wenn nicht, dann könnten wir ja mal eins verfassen.
@Ronny: > Ponyprog ist doch auch frei. Und andere Software, die auch den > ATmega16 unterstützt, kenne ich nicht. Dann hast Du Dich wohl schlecht umgesehen. Ich kenne nur avrdude und uisp, die unterstützen beide die ganze Palette der AVRs. Vermutlich gibt es aber noch weit mehr. @Khani: > - Bevor Ihr das Pony beschimpft : Erst Freeware holen und dann > motzen - ist nicht ganz gerecht, ... Ich hab' sie nicht geholt, ich benutze es nicht, ich stelle nur immer wieder fest, daß es ausschließlich PonyProg-Nutzer sind, die hinterher mit: ,,hab' mir die Fuses zerschossen, mann, die sind ja negiert, wie kann ich das jetzt wieder rückgängig machen?'' ankommen. Offenbar schafft alle andere Programmiersoftware das irgendwie anders, so daß die Leute sich die Dinger nicht vernageln damit.
Hm, schauen wir uns mal das an : >ausschließlich PonyProg-Nutzer sind, die hinterher >mit: ,,hab' mir die Fuses zerschossen, mann, die sind ja negiert, wie >kann ich das jetzt wieder rückgängig machen?'' ankommen Das mag daran liegen, dass PonyProg a) bekannt ist und in google oft gefunden wird und b) das Programm simpelst auf eine ganze Menge Hardware angewendet werden kann. Außerdem, wer die Fuses verballert, weil er/sie sich ausschließlich auf "rule of thumb" und das eine oder andere Tutorial im Internet verlässt, der hat eben Pech. µController sind eben keine PCs, bei denen (fast) jeder Fehler verziehen wird, wenn man nur das Betriebssystem neu installiert. Da kann man jedem nur raten, erst mal ein gutes Tutorial zu lesen (gibt's hier ja schließlich) und dann in Anbetracht der Gefahr mit dem Datenblatt etwas zu unternehmen. Aber vielleicht ist der nachfolgende Spruch auch hier anwendbar : "Es gibt drei Arten etwas zu erlernen : 1. durch abschauen - das ist am Einfachsten 2. aus den Fehlern anderer - das ist am Sichersten 3. aus den eigenen Fehlern - das ist am Härtesten, dafür vergisst man es nicht so schnell" In diesem Sinne, Daniel
Das mit den Bits, dass die invertiert sind in PonyProg ist klar. Des mit den Quarzen auch. Deshalb habe ich mir heute noch einen mit 4 Pinner geholt und hoffe damit meine AVRs zu retten. Ich bin mir auch nicht bewusst einen Fehler gemacht zu haben. Wie ich die Bits eingestellt habe, habe ich ja oben schon geschrieben. Und deshalb ist es auch schwer aus den Fehlern zu lernen. Das mit den abschauen aus dem Internet habe ich mir geschenkt, da es mir doch lieber war in die Anleitung zu schauen...
Hi. @Jörg Wunsch: Schwingst hier ganz schön die Keule. Ist Dir aufgefallen, das avrdude und uisp für Linuxsysteme ist ? Müssen dann Deiner Meinung nach alle noch ebend schnell Linux installieren ?? Ich habe versucht, YAPP zu benutzen, klappt leider nicht wegen dem speziellen Porttreiber, den ich aus anderen Gründen nicht einsetzen kann. Was kommt einem da näher als Ponyprog ? Ziehen, installieren und problemlos damit arbeiten. Dann immer wieder hier die Hinweise: Schau ins Forum, schau ins Datenblatt, schau ins Google, schau im Katalog von Quelle oder Hornbach... Ich bin in vielen Foren tätig und da ist es so, wenn sich ein Problem häuft, wird eine Doku geschrieben. Grandios ist z.B. das entstandene Tutorial von Gerhard Paulus !!! Ich würd gern eine Doku über genau diese Problematik hier schreiben, aber leider bin ich mir nicht ganz sicher, ob ich mit meinem Wissen hier genau richtig liege. Die Antworten von Khani hier sind durchaus nützlich, danke ! Alle anderen Beiträge in diesem Thread sind wieder pure Verschwendung von Plattenplatz des Servers, vielleicht meiner eingeschlossen. Sorry, aber das musste mal raus, auch wenn ich mich unbeliebt mache. Foren sind zum reden, Lösungen finden und zum Diskutieren. Sonst kann man das Forum gleich dicht machen. Ein zufriedener Ponyprog User grüßt, Andre.
Hmm... warum denn gleich so verbittert? ;) Okay ... ihr werdet lachen. Alle meine (inzwischen 3 AVRs) lassen sich jetzt wieder ansprechen. Der Fehler lag ganz woanders ... Das Kabel war zu lang. Ich habe es auf 1m halbiert und jetzt geht das alles super. Allerdings tritt das nächste Problem auf: Mein Testprogramm "blinkende LED" scheint nicht zu starten. Ab und an ging es mal und dann wieder überhaupt nicht. Ich konnte einmal sogar mit externer Taktung und den internen verschiedenen Oscillatoren rumprobieren und die LED hat immer verschieden schnell geblinkt. Aber jetzt geht bei allen nichts mehr.
Na für den internen 8 MHz-Quarz sieht das dann so aus. Dabei ist 0 angehakt und 1 nicht ... also nicht unbedingt nur für Ponyprog. OCDEN: 1 JTAGEN: 0 SPIEN: 0 (nicht änderbar) CKOPT: 1 EESAVE: 1 BOOTSZ1: 0 BOOTSZ0: 0 BOOTRST: 1 BODLEVEL: 1 BODEN: 1 SUT1: 1 SUT0: 0 CKSEL3: 0 CKSEL2: 1 CKSEL1: 0 CKSEL0: 0 Und danke für die vielen Ratschläge .. nur wenn der jetzt noch richtig läuft, wäre das genial.
@Andre: > Ist Dir aufgefallen, das avrdude und uisp für Linuxsysteme ist ? Nein, ist mir nicht. avrdude ist auf einem FreeBSD entwickelt worden. ;-) Damit läuft es von Haus aus unter den Unixen mehr oder weniger gut, aber offensichtlich ist Dir nicht aufgefallen, daß sowohl uisp als auch avrdude bei WinAVR mit dabei sind. Irgendwas scheint also an Deiner Behauptung nicht zu stimmen, man müsse sich dann erst ein Linux installieren... (Davon abgesehen, ich halte Unixe für deutlich besser geeignet für Programmieraufgaben -- aber wie die Amis sagen: your mileage may vary.) Außerdem hatte ich niemandem empfehlen wollen, diese zu benutzen, sondern dies lediglich als Gegenargument benutzt, daß ich mir nicht erst das kostenlose PonyProg genommen hätte und dann drüber meckern würde. Allerdings mag die Art und Weise, wie man mit avrdude die Fusebits setzt, durchaus dazu beitragen, daß man dabei weniger Fehler macht: man muß sie derzeit als Bytewert angeben. Damit hat man deutlich mehr Zwang, sich erstmal das Datenblatt zu Gemüte zu führen. Wie Daniel eben schon schrieb, MCUs sind keine PCs, sie sind an mancher Stelle weniger verzeihend, was Fehler angeht. (Definier' Dir den /RESET an einem ATmega8 weg, und Du bist erstmal auf der Suche nach einem HV-Programmer...) Stellt sich die Frage, ob es eben wirklich so 'ne gute Idee ist zu versuchen, MCU-Programmierung kindergartentauglich zu machen (klickicklacki, am besten nur noch Bilder und nichts mehr zu lesen...) @Ronny: Wo hast Du denn Dein Testprogramm? Ansonsten: bei WinAVR kommt ein Demo mit, was eine auf- und abschwellende LED (per PWM) macht, kannste ja auch gern ausprobieren. Andererseits, Dein Programm lief ja schon mal, was hast Du denn verändert seither?
Hallo Joerg, die Probleme werden immer weniger ... oder es kommen neue hinzu. Das Programm lief natürlich nur zufällig, weil ich den Stackpointer nicht richtig initialisiert hatte und damit hat der mir mein Programm zerhackt. War doch einfach .. ;) Sonst habe ich hier Ewigkeiten rumgedoktert, bis ich mal zum Multimeter gegriffen habe ... das olle JTAG muss man auch abschalten, damit man die Ports benutzen kann. Auf sowas muss man erst einmal kommmen.
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.