www.mikrocontroller.net

Forum: Analoge Elektronik und Schaltungstechnik ATMega8 funktioniert super, aber KEINE spannung an i/o-ports


Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Hesse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mal so ins blaue geraten: bei dir steht .include "4433def.inc" ?

Autor: R. Hartmann (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: R. Hartmann (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ooops,
liegt doch daran :-)
Na dann kann mir doch bitte sicher jemdand erklären, warum.

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Oly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
liegen die include-Dateien im passenden Verzeichniss?

evtl. so
.inlude.   "c:\xyz\m8def.inc"

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
gibts das nicht sonst ne fehlermeldung?

Autor: Thomas Oly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

muss vielleicht der Stack initialisiert werden?

Autor: Thomas Oly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nur wenn man push/pop befehle benutz oder unterprogramme/ints. sonst
nicht.
das mini-progrämmchen braucht keinen stack um zu laufen

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Thomas Oly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

anscheinend bracuht mans nicht wenns dus reinschreiben willst setzt es
an den Anfang und las das Stack: weg.

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Oly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ja genau so meine ich das.

Autor: R. Hartmann (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
siehe anhang! meldet fehler! geht anscheinend nicht!

oh man, bei allen gehts, nur nicht bei mir heul

Autor: Thomas Oly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: R. Hartmann (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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...:
.include "m8def.inc"       ;Definitionsdatei einbinden, ggf. durch
                             ;2333def.inc ersetzen

         ldi r16, 0xFF       ;0xFF ins Arbeitsregister r16 laden
         out DDRB, r16       ;Inhalt von r16 ins IO-Register DDRB
ausgeben

         ldi r16, 0b00000011 ;0b11111100 in r16 laden
         out PORTB, r16      ;r16 ins IO-Register PORTB ausgeben

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

Autor: R. Hartmann (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
...und der schaltplan für die grundschaltung

Autor: Ingo Henze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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!

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schon mal an anderer stelle auf dem bradboard aufgebaut? die dinger
haben manchaml auch ein paar macken

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@R. Hartmann

Du hast an dem Wiederstand für den Reset die +5V nicht angeschlossen.

Autor: R. Hartmann (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
doch, eigentlich hängen schon mit einem widerstand dazwischen 5V dran!

schau mal in den anhang, dort hab ich jetzt ein detaillierteres foto
gepackt!

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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°!

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann stimmen die werte bei mir, weil 0 für aktiviert und 1 für
deaktiviert steht!

Autor: Micha (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: deep throat (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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!!
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

Autor: R. Hartmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ä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?!?!?

Autor: thkais (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: deep throat (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
----------------------------------------------------------------------

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.