Bin nun aufmerksam durch das tutorial von microcontroller.net gegangen, und an dem punkt angelangt, wo die erste code geschrieben wird und rübergespielt wird. mein selbstgebauter isp funktioniert, sowie auch mein µC (atmel atmega8), denn mit ponyprog oder mit yaap wird er als atmega8 erkannt. außerdem im avr studio wird er natürlich nicht erkannt, aber ich glaube, dass das an meinem isp liegt. jedenfalls hab ich den ersten code geschrieben, assembliert und mit ponyprog rübergespielt. der code ist anscheinend auch im µC drin, denn er lässt sich ja immer wieder korrekterweise auslesen! als ich dann eine led an den PB0 (das ist der ausgang) angeschlossen habe, und über widerstand an vcc gegangen bin, leuchtet diese allerdings nicht, obwohl sie es tun müsste.... wo könnte hier der fehler sitzen? bin halt etwas neu...dadurch kann ich noch nicht ganz selbst fehleranalyse durchführen! danke im voraus für eure antworten
Hallo, normal schalte ich eíne LED über einen Widerstand gegen Masse. Wenn der Port Pin dann eingeschaltet wird (und als Ausgang konfiguriert ist), dann leuchtet die LED. Gruss Andreas
mal so ins blaue geraten: bei dir steht .include "4433def.inc" ?
hm, ich hab dir mal den code mit dran gehängt, dort sind alle pins auf masse geschaltet! dann hab ich die led an vcc mit widerstand angschlossen, aber es ist einfach keine spannung vorhanden....
die include 4433def.inc definiert die ports, so wie es wohl im tutorial steht! liegt auch im anhang! ich fand das eine ganz eigenartige geschichte....
du verwendest einen mega8, keinen 90s4433. du musst immer die zu deinem uC passende datei einbinden. heisst in deinem fall m8def.inc versuchs mal damit!
das ist des rätsels lösung! ich kauf mir jetzt ein buch, tutorials für den anfang sind doch nicht so günstig... danke vielmals für eure mühe
Bei diesem Minimal-Programm ist das wohl fast egal, was für eine def-Datei man nimmt. Ich glaube nicht, das es daran liegt. PORTB und DDRB liegen bei beiden an den selben Adressen. Aber prinzipiell sollte man schon die zum uC passende include-Datei verwenden.
Ooops, liegt doch daran :-) Na dann kann mir doch bitte sicher jemdand erklären, warum.
Ich habe da so meine Zweifel, das es wiklich an der falschen Include-Datei lag. Habe das grad mal ausprobiert. Egal ob ich die "4433def.inc" oder "m8def.inc" nehme, es wird exakt der selbe Code vom Assembler produziert (wenn man dem LIST-File trauen kann): ------------------------------------------------- .include "4433def.inc" 000000 ef0f ldi r16, 0xFF 000001 bb07 out DDRB, r16 000002 e000 ldi r16, 0b00000000 000003 bb08 out PORTB, r16 000004 cfff ende: rjmp ende ------------------------------------------------- .include "m8def.inc" 000000 ef0f ldi r16, 0xFF 000001 bb07 out DDRB, r16 000002 e000 ldi r16, 0b00000000 000003 bb08 out PORTB, r16 000004 cfff ende: rjmp ende Hätte mich auch gewundert, wenn da was anderes rausgekommen wäre. Egal, wir werden wohl nie erfahren, was der wahre Grund war :-) Gruß Ingo
Hast Du denn auch die *.hex Files verglichen? Ich denke, das es doch an der include-Datei lag, denn in der Datei werden nicht nur Ports Namen zugewiesen sondern auch anderen Einheiten (z.B. URAT).
Hab ich zwar nicht, da ich mir sicher bin, das auch da das selbe drinsteht. Habe es aber trotzdem ebend mal gemacht: 4433.hex :020000020000FC :0A0000000FEF07BB00E008BBFFCFC5 :00000001FF m8.hex :020000020000FC :0A0000000FEF07BB00E008BBFFCFC5 :00000001FF noinclude.hex :020000020000FC :0A0000000FEF07BB00E008BBFFCFC5 :00000001FF Es kommt auch exakt das selbe raus, wenn ich gar keine Definitionen mit .include einbinde. Nur dann muß ich halt anstelle der symbolischen Namen für DDRB und PORTB die Adressen dirket angeben (0x17 und 0x18). Wie auch der Name schon vermuten läßt, es wird nur definiert, aber nichts zugewiesen. Zumindest bei dem oben angegeben Mini-Programm kann es daran nicht gelegen haben. Bei größeren, komplexeren Programmen hingegen ist es schon wichtig, die richtige Definitions-Datei einzubinden. Man kommt zwar auch dort prinzipiell ganz ohne aus, die Verwendung erhöht dann aber doch die Übersichtlichkeit beträchtlich, und verringert in selbem Maße die Fehleranfälligkeit :-) Gruß Ingo
jetzt bitte nicht schlagen! bitte nicht! aber als ich eben das programm rübergespielt habe, läuft es trotzdem noch nicht! ich schmeiß mein µC in die ecke, hab die schnauze voll....;-) ne war ein witz, aber wenn ich nicht bald des rätsels lösung auf die spur komme, breche ich zusammen! was könnte ich euch noch für infos geben, dass vielleicht ihr mir etwas noch helfen könntet
liegen die include-Dateien im passenden Verzeichniss? evtl. so .inlude. "c:\xyz\m8def.inc"
Hallo, muss vielleicht der Stack initialisiert werden?
Hallo,
fehlt das vielleicht
stack: ldi temp, LOW(RAMEND) ;LOW-Byte der obersten RAM-Adresse
out SPL, temp
ldi temp, HIGH(RAMEND) ;HIGH-Byte der obersten RAM-Adresse
out SPH, temp
nur wenn man push/pop befehle benutz oder unterprogramme/ints. sonst nicht. das mini-progrämmchen braucht keinen stack um zu laufen
keine ahnung, ob das fehlt, da ich neuling bin und ich mich nur an dem tutorial halte zudem kann ich auf der stelle nichts mit stack anfangen! sollte ich das vielleicht mal probieren? wenn ja, einfach code reinschreiben....? PS: include-datei ist im gleichen verzeichnis, ansonsten würde er beim assemblieren eine fehlermeldung geben!
wenn der µC problemlos programmiert werden kann, heißt: code kann geschrieben werden und auch wieder ausgelesen werden - ist dann somit eigentlich auch die grundschaltung richtig aufgebaut, oder? mehrere mikrocontroller gleichen typs hab ich auch schon verwendet, da vielleicht der eine kaputt sein könnte. ich glaube, ich sehe den wald vor lauter bäumen nicht mehr! PS: eigenartig finde ich unter anderem, dass aus den output-pins laut messgerät eine geringe spannung von 0,5V anliegt, aber ich glaub, das sind schwankung, richtig?
Hallo, anscheinend bracuht mans nicht wenns dus reinschreiben willst setzt es an den Anfang und las das Stack: weg.
du meinst also, nur das schreiben (an den anfang)?: ldi temp, LOW(RAMEND) ;LOW-Byte der obersten RAM-Adresse out SPL, temp ldi temp, HIGH(RAMEND) ;HIGH-Byte der obersten RAM-Adresse out SPH, temp
siehe anhang! meldet fehler! geht anscheinend nicht! oh man, bei allen gehts, nur nicht bei mir heul
Hallo, les dir mal die Datei m8def.inc durch vielleicht heißt das dort nicht mehr PORTB sonder PINB und statt DDRB DDB oder vielleicht auch PORTB1.
portb und pinb sind doch wohl ein kleiner unterschied und nicht auswechselbar. ddrb heisst es auch immer noch... würde auch sonst einen fehler geben wenn die definitionen fehlen würden da kommt überigens ein fehler, weil die definition für temp fehlt, ergänz mal am anfang die zeile .def temp = r16
mach mal einen Pin auf 1 und einen auf 0 und mess dann mal die Spannung dazwischenm ob da auch 5V anliegen. Was benutzt du als Spannungsquelle, und was für einen Widerstand benutzt du vor der Led? Hast du mal alles nach Überbrückungen durchsucht, die versehentlich beim Löten entstehen können?
Hi! Nur mal so am Rande, kann auch sein ich habe es überlesen, dein Reset geht hoffentlich nach dem proggen auf 5V?? Sonst geht da garnichts. MFG Uwe
1.Keine Panik, 2.meistens findet sich der Fehler bei der Hardware. Überprüfe deshalb nochmals deinen Schaltungsaufbau, evtl. kleine Skizze dazu mitschicken. Arbeitspunkte wie: Versorgungsspannung korrekt gemessen, Lötstellen okay bzw. Verbindungen von Pin-Widerstand-LED etc. sind zu überprüfen/durchzumessen. Hast du die Polung (LED etc.) korrekt beachtet ? 3.Dann Software: Mit was hast du den ATmega8 programmiert. Bzw. klappt das wirklich mit dem verifizieren deines Programms ? Nutzt du PonyProg, dann ein- fach mal ein neues Fenster aufmachen und lesen lassen ? Soweit okay? Programm mit korrigierter *.inc für ATmega8 sieht gut aus, lt. Ingo funzt das erste auch. Lass das mit dem Stack weg, brauchste nicht. 4.Wie betreibst du den programmierten Atmega8? Quarz-Oszillator? welche Pins hast du womit verbunden? Schließlich 5.Nimm dir einen Moment Zeit, geh nochmal alles durch. Falls das immer noch nicht funktioniert schreib bitte die Doku zu deinem check hier herein. Also WAS du WOMIT gemacht hast. Anhand einer kleinen Skizze / Verschaltungsplan muss das doch möglich sein, dir zu helfen. Nur Mut und viel Erfolg, Micha
Ergänzung zu Punkt 3.: Bei deinem letzten Dateianhang hast du die Ausgänge auf 1 gestellt, oben sagtest du, du hast die Pins an Vcc gehängt -> geht so nicht, deshalb nachprüfen, was du jetzt verwendest. WEIL: Entweder 0 ausgeben und gegen Vcc, oder 1 ausgeben und gegen Masse. Ansonsten leuchtet nischt. So long, Micha
Angehängte Dateien:
-
100_2659_Kopie.jpg
70 KB
1. OK 2. Foto des Aufbaus ist im Anhang mitgeschickt. Die LED unter dem Quarz ist nur eine Kontroll-LED, die mir Auskunft gibt, ob der Stromkreis in Betrieb ist. Die LED am Ausgang des µC ist nicht vorhanden, da ich in letzter Zeit die Spannung nur noch mit Messgerät gemessen habe, welches durchaus korrekt von mir verwendet wurde ;-). Lötstellen gibt es nicht zu prüfen, weil ich auf einen Breadboard arbeite (siehe Anhang). Mein ISP funktioniert, da ich immerhin Kontakt mit meinem ATMega aufnehmen kann! 3. Den Assembler-Code habe ich im AVR Studio von Atmel geschrieben. Mir ist bekannt, das eine 1 am Pin VCC signalisiert und eine 0 Masse beschreibt. Dementsprechend habe ich auch mein Messgerät verwendet, je nachdem in welcher Richtung der Strom floss! Um den Code zu übertragen, verwende ich PonyProg. Der Code wird korrekt geschrieben, da ich den neu geschriebenen Code wieder korrekt mit PonyProg auslesen kann. Stack habe ich auch wieder weggenommen, da dies auch keine Ergebnisse erzielt hat. 4. Verwende einen Quarz-Oszillator mit 4 Mhz (siehe Anhang). Die Einstellungen, damit er mit dem Quarz läuft, habe ich mit PonyProg vorgenommen. Die Pins sind angesteckt, wie der Schaltplan vorschreibt (siehe dazu Anhang mit Schaltplan). 5. So, nun noch einmal letzten Check gemacht. Nun auch keine Problemlösung: Ich kann meinen Atmel µC beschreiben und verwalten, sowohl auch alle Daten wieder auslesen. Er wird erkannt und es werden keine Fehler gemeldet! Sobald allerdings folgender Code geschrieben wird...:
1 | .include "m8def.inc" ;Definitionsdatei einbinden, ggf. durch |
2 | ;2333def.inc ersetzen |
3 | |
4 | ldi r16, 0xFF ;0xFF ins Arbeitsregister r16 laden |
5 | out DDRB, r16 ;Inhalt von r16 ins IO-Register DDRB |
6 | ausgeben |
7 | |
8 | ldi r16, 0b00000011 ;0b11111100 in r16 laden |
9 | out PORTB, r16 ;r16 ins IO-Register PORTB ausgeben |
10 | |
11 | ende: rjmp ende |
...müsste an Pin0 und Pin1 des Atmel-Ausgangs eine Spannung von 5V anliegen. Das ist allerdings nicht der Fall. Was sagt ihr nun! Ist doch echt ziemlich seltsam! MfG, R.Hartmann
Angehängte Dateien:
...und der schaltplan für die grundschaltung
Naja, das könnte schlicht und ergreifend bedeuten, das die Ausgangsstufen defekt sind. Ich habe z.B. bei meinem Atmega8 am Port C den Ausgang 0 abgeschossen. Ich hatte da einfach im laufenden Betrieb auf dem Breadboard Leitungen umgesteckt und muß da wohl irgendwie den Pin mit VCC oder GND kurzgeschlossen haben. Egal, als ADC-Eingang funktioniert er zumindest noch bestens, nehme ich ihn halt dafür :-) Gruß Ingo
Ich gehe also davon aus, dass die MCU korrekt beschrieben ist. Okay, funktionieren sollte die auch, da du ja ansonsten nicht lesen könntest. Versuch doch mal nach dem proggen (also Programm ist drauf, FUSES sind auf den Oszillator eingestellt) alles am ATmega8 abzuklemmen, bis auf: 5V(pin7),Gnd(pin8),XTAL1(pin9) mit ATmega8 verbinden Dabei LED oder sowas für Quarzoszillator weg (, nur beim Oszillator! 5V an 14, XTAL1 an 8, GND an 7) und natürlich die Pins für deine LED (korrekt verpolt) über Wiederstand mit Gnd bzw Vcc (deine Wahl) verbinden. Also: Pin 14 und Pin 15 jeweils mit R und LED an GNDbzw.5V anschließen Jetzt sollte das eigentlich schon funktionieren. Ich meine, dass bei meinen ersten Schritten der ATmega8 auch ohne den Reset zu beschalten funktioniert hat. Weit kanns nicht mehr sein bis zum Licht :-) Also, nicht aufgeben. Gruß, Micha
@micha: hab dein rat befolgt, aber genau die gleichen ergebnisse bekommen. ich hab die atmels erst neu erworben und noch nicht großartig daran rum experimentiert! also vielleicht glaub ich nicht, dass die pins bei mir hin sind. was ich aber langsam glaube, dass meine bei kessler electronic neu erworbenen 3 µC nicht in ordnung sind oder vielleicht gar keine µC sind ;-) obwohl, sie wurden ja von ponyprog als atmega8 erkannt!
schon mal an anderer stelle auf dem bradboard aufgebaut? die dinger haben manchaml auch ein paar macken
3x µC nicht i.O., das kann ich auch irgendwie nicht glauben. Irgendwo sitzt da bestimmt nochn bug, müsste schon ein dummer Zufall sein ... Bleibt vielleicht nur noch die Schaltung, Spannungen etc. nochmals nachprüfen oder doch eine neue Bezugsquelle/MCU auftun. Gruß, Micha
@R. Hartmann Du hast an dem Wiederstand für den Reset die +5V nicht angeschlossen.
Angehängte Dateien:
-
100_2656.jpg
700 KB
doch, eigentlich hängen schon mit einem widerstand dazwischen 5V dran! schau mal in den anhang, dort hab ich jetzt ein detaillierteres foto gepackt!
Ich hätte da noch drei Vorschläge: 1. probier es mal ohne LED 2. verbinde AREF mit +5V (mußte ich schon mal machen, da ich sonst PortC (als Eingang geproggt) nicht vernünftig Abfragen konnte) 3. setze zwischen +5V und GND vom Mega8 einen 100n Kondensator (so dicht wie möglicht an den Pins) Es sind nur Möglichkeiten um den Fehler weiter einzugrenzen. Hast Du irgend welche Fuses modifiziert?
ohne LED versuche ich es in letzter Zeit nur noch. ich messe nur noch die spannung per messgerät! fuses habe ich modifiziert, um den mega8 mit einem 4mhz quarz laufen zu lassen! PS: hab es auch schon mit dem mega8 ohne modifizierte fuses versucht°!
Moin! Muss mich jetzt auch mal beteiligen. 1.Hast du den ISP-Stecker mal abgezogen? Nicht das deine Schnittstelle ne Macke hat und einen Dauerreset macht. 2.Kann das sein das der Vorwiderstand der LED am Oszillator mal kurz mit einer blanken Stelle ans Gehäuse vom Oszill. gekommen ist. Das Gehäuse ist glaub ich "gegrounded". Dadurch kurzschluß und Oszillator defekt! MFG Thomas
Könnte er die MCU in diesem Fall, wenn der Oszillator hin ist, noch beschreiben (FUSE-Bits sind ja schon umgestellt) ? Hast du vormals die Schaltung am ISP hängen gehabt, oder hast du die Spannungsversorgung mit auf das Board gebaut ? Versuch doch in diesem Fall, die Schaltung nochmal Schritt für Schritt minimal an anderer Stelle aufzubauen (ohne ISP-Verbindung). Siehe auch Beitrag von Tobi, bzw. Thomas. Stell sicher, dass Deine LED mit Widerstand funktioniert, die du für die Ausgabe benutzt. Sowie dass die 5V, die die MCU erhält, gegen GND auch wirklich anliegen. Tausche den Oszillator versuchsweise aus, den Oszi-Out möglichst nahe am Pin positionieren. Und den Reset-Pin mit 5V belegen nicht vergessen, das Datenblatt möchte es anscheinend so :-) Viel Erfolg, Micha
meine 5V-Spannungsversorgung liegt mit auf dem board und wird mit 12V betrieben! der isp wird von diesen 5V mitversorgt. allerdings hab ich bisher immer den isp drangelassen, nachdem ich das geproggt habe. ich werde die schaltung jetzt komplett neu aufbauen und dabei darauf achten, dass ich nach dem proggen den isp abziehe! ich berichte meine ergebnisse @thomas: ja, ich glaube, der ist schon mal gegen gekommen, weil urplötzlich einmal meine led ausgegangen ist, was darauf hindeutet, dass ein kurzschluss aufgetreten ist (der ic im versorgungsschaltkreis ist ja kurzschlusssicher). wusste aber die, dass es daran liegt, dass das gehäuse vom quarz geerdet ist. --> ich baue die neue schaltung mal ohne quarz auf und stelle die fuses wieder auf den internen oszillator um - müsste ja auch gehen!? habe dann zwar nur 1mhz, aber hauptsache, es funktioniert ;-)
so! hab das ding nu nach langer pause (hatte viel zu tun ;-) ) nun neu aufgebaut, und dabei allerdings dem quarz raus gelassen. der µC läuft also nun mit dem internen takt (1mhz). controller wird auch wieder super erkannt, aber..... das problem besteht weiter hin!!! heul PS: ich hab mal gehört, dass man über den lpt-port (über diesen port programmiere ich den avr ja auch) den mikrocontroller live mit dem computer ansteuern kann. man bräuchte ihn also nicht neu flashen...sollte ich das mal probieren?!
1. Hast Du den internen Takt (Int. RC Osc. Fuse) auch eingeschaltet? 2. Hast Du nach der Programmierung den ISP-Stecker abgezogen? (3. Wie oben schon genannt, die Ref-Spannungen angelegt? Auch wenn nix davon im Datenblatt steht. Bei mir hat es nur so funktioniert) Ich habe auch meine ersten Versuche auf dem Steckbrett (4433 und Mega8) gemacht, bevor ich mir ein STK500/501 gekauft habe.
Axo, nicht verzweifeln. Es ist bestimmt nur so ein kleiner Flüchtigkeitsfehler den man selbst immer übersicht. In 90 Prozent aller Problemefälle sind es immer die kleinen fiesen Fehler die einen zuschaffen machen. Und wenn Du den Fehler gefunden hast, dann faßt Du Dich an den Kopf und sagst "Ich Idiot", so mache ich es jedenfalls immer ;) Also nicht den Kopf hängen lassen.
1. interner takt? also ich habe die fuses wieder auf lieferzustand gestellt, heißt: sut0, cksel1-3. 2. ja 3. referenz-spannung von 5V am ausgang, wenn auf masse geschaltet? ja!
zu1. lt. STK500 ist der Standartwert für 1MHz interner Takt CKCEL=0001 und SUT=10 (Start-up time 6CK + 64ms). Probier die Werte mal.
dann stimmen die werte bei mir, weil 0 für aktiviert und 1 für deaktiviert steht!
Angehängte Dateien:
-
minimal.jpg
22 KB
Geht denn dieser Minimalaufbau im Anhang mit deinem Programm LEDS.ASM nicht, wenn du den internen RC-Osz. eingeschaltet hast?? Also folgender Code: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; .include "m8def.inc" ldi r16, 0xFF ;0xFF ins Arbeitsregister r16 laden out DDRB, r16 ;Inhalt von r16 ins IO-Register DDRB ausgeben ldi r16, 0b11111111 ;0b11111111 in r16 laden out PORTB, r16 ;r16 ins IO-Register PORTB ausgeben ende: rjmp ende ;Sprung zur Marke "ende" -> Endlosschleife ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Erwarte eine Erfolgsmeldung :-) Gruß, Micha
Ich habe eigentlich alles durchgelesen und bin der Meinung, dass Du die Spannung aktuell immer mit dem Messgeraet misst, richtig ? Ich habe aber nirgends gelesen WAS Du misst. Ich frag deshalb, weil ich hatte aehnliches Leid und ich Doedel habe einfach nur Kathode und anode der LED vertauscht... drehen und schwupps geht ;-)
@Ralf Hab die LED schon dreimal in meinen posts erwähnt, wirds wohl nicht sein. Aber irgendein dummer bug, auf den wir alle gerade nicht kommen, hockt da noch, gebe ich dir recht.
Angehängte Dateien:
-
fuse.gif
13 KB
Vielleicht mal diese These überprüfen: 99% aller elektrischen Fehler sind mechanische - oder Checkboxen. Hier das Zitat von Henne's Site (ganz am ende): [http://www.hoelscher-hi.de/hendrik/light/dmx.shtm] ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Eine besondere Falle wartet bei PonyProg in den "Security and Configuration Bits" auf Euch: Die Checkboxen arbeiten invertiert! (Und wenn Ihr Pech habt, gebt Ihr an Stelle Eures Quarzes einen externen Oszi als Taktgeber ein und nichts funktioniert mehr... ) Also haltet Euch an folgendes Bild!! ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
äh stopp! ich habe laut anweisungen anderer folgende checkboxen aktiviert: sut0, cksel1, cksel2, cksel3 ...und bevor ich jetzt was umstelle und womöglich kaputt mache, frage ich jetzt: sind diese einstellungen für den internen quarz von mir oder von deep throat richtig?!?!?
Die Fuse-Bits sind - mit Ponyprog - so richtig. Wenn der Oszillator nicht richtig eingestellt wäre, würde Ponyprog den Controller nicht programmieren. Das angehängte .Hex sollte auf allen Ports das Bitmuster "10101010" ausgeben, also immer abwechselnd Masse und +5V, probier das mal - ich habs eben mit einem "frischen" Mega-8 getestet. Wenn das nicht funktioniert, ist irgendetwas anderes faul.
Hier das Zitat von Scott-Falk Hühn: AVR-Programmierung mit PonyProg, Abschnitt: Fuse-Bits (ganz am Ende) ATMega8 mit Quarzoszillator [http://s-huehn.de/elektronik/avr-prog/avr-prog.htm] ====================================================================== [] Wie auch immer, an dieser Stelle sollte man unbedingt als erstes auf "Read" drücken, damit man wirklich den aktuellen Zustand der Fuses angezeigt bekommt und das sieht bei einem jungfräulichen ATmega8L so aus: +--------------------------------------------------------------------+ | Configuration and Security Bits | +--------------------------------------------------------------------+ | _7 _6 _BootLock12 _BootLock11 _BootLock02 _BootLock01 _Lock2 _Lock1| +--------------------------------------------------------------------+ | _RSTDISBL _WDTON xSPIEN _CKOPT _EESAVE xBOOTSZ1 xBOOTSZ2 _BOOTRST | | _BODLEVEL _BODEN _SUT1 xSUT0 xCKSEL3 xCKSEL2 xCKSEL1 _CKSEL0 | +--------------------------------------------------------------------+ +--------------------------------------------------------------------+ Im ersten Moment mag es etwas konfus klingen, aber: Ein Haken bedeutet hier: das Fuse-Bit ist programmiert und das entspricht einer logischen "0". Da dies immer wieder zu Missverständnissen geführt hat, liefert PonyProg seit der Version 2.06c eine kleine Hilfezeile mit, die im unteren Teil des Fensters zu sehen ist. Es gilt also: _ = Fuse nicht programmiert = logisch "1" x = Fuse programmiert = logisch "0" Die Datenblätter von Atmel verwenden immer die logischen Werte der Fuse- Bits und man sollte immer das Datenblatt zum verwendeten Controller bereithalten, wenn man Fuse-Bits ändern möchte. Das Datenblatt des ATmega8L verrät uns nun die Bedeutung der programmierten Fuses: BOOTSZ1 und BOOTSZ0 (Zustand=00): Bootloader-Größe=1024 Words, Startadresse 0xC00 (Tabelle 82 des Datenblattes, wird im folgenden Test nicht weiter berücksichtigt und auch nicht verändert) SUT1 und SUT0 (Zustand=10): Start-up Time 65ms nach Reset, Einstellung für internen Oszillator und langsam ansteigende Betriebsspannung (Tabelle 9 und 10 des Datenblattes) CKSEL3-CKSEL0 (Zustand=0001): Interner Taktoszillator 1MHz (Tabelle 9 und 10 des Datenblattes) ====================================================================== Achtung: PORTB... ldi r16, 0xFF out DDRB, r16 ; PB7..PB0 als Datenausgang ldi r16, 0b00000000 out PORTB, r16 ; PB7..PB0 auf Low Die Konfiguration "sut0, cksel1, cksel2, cksel3" heisst "Interne Taktoszillator 1MHz" aktiv, damit gibt "Alternative Port Function" PB6 und PB7 als Datenausgang frei!!! ---------------------------------------------------------------------- Am Datenusgang Pin 9 = PB6 ist der externe Oszillatorausgang angeschlossen, ->> dh. Kurzschluss!!! Test: erstmal den Oszillator-Draht herausnehmen -> LED an??? Dann: Oszillator-Draht wieder dran und xCKSEL0 konfigurieren. ---------------------------------------------------------------------- Eine Konfiguation mit externem Oszillator sieht dann so aus: CKSEL3-CKSEL0 (Zustand=0000): Externer Taktoszillator an PB6 Pin-9 (XTAL1/TOSC1) (siehe: Table 2) +--------------------------------------------------------------------+ | Configuration and Security Bits | +--------------------------------------------------------------------+ | _7 _6 _BootLock12 _BootLock11 _BootLock02 _BootLock01 _Lock2 _Lock1| +--------------------------------------------------------------------+ | _RSTDISBL _WDTON xSPIEN _CKOPT _EESAVE xBOOTSZ1 xBOOTSZ2 _BOOTRST | | _BODLEVEL _BODEN _SUT1 xSUT0 xCKSEL3 xCKSEL2 xCKSEL1 xCKSEL0 | +--------------------------------------------------------------------+ +--------------------------------------------------------------------+ Table 2. Device Clocking Options Select(1) Device Clocking Option CKSEL3..0 ---------------------------------------------------------------------- External Crystal/Ceramic Resonator 1111 - 1010 External Low-frequency Crystal 1001 External RC Oscillator 1000 - 0101 Calibrated Internal RC Oscillator 0100 - 0001 <-von hier External Clock 0000 <-nach hier ---------------------------------------------------------------------- Note: 1. For all fuses "1" means unprogrammed while "0" means programmed. ----------------------------------------------------------------------
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.