mikrocontroller.net

Forum: Compiler & IDEs Atmega 8 Led fading


Autor: Alfred P. (zigarrre)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Seit ich den code im anhang kompiliert und geflashed habe funktioniert 
mein Atmega8 nicht mehr. Der Code ist dem LED Fading-Tutorial 
nachempfunden. Fuses sind alle auf standard, auser die Freqenz des 
internen Oszilators ist auf 8Mhz eingestellt. Beim Versuch das LED 
Fading-Tutorial leicht angepasst zu flashen hab ich mir bereits einen 
Atmega8 zerstört. Wo liegt der Fehler? Kann ich die Controler noch 
retten? Wenn ja, wie?

Ich bin noch recht neu auf dem Gebiet und hoffe ihr könnt mir helfen.

mfg
zigarrre

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Bitte poste deinen gesamten Code. Ich bin kein C-Profi, aber ich 
denke hier fehlt was.
2. In fade out:
> for(tmp = 31; tmp>=0; tmp++) {
soll wohl heißen tmp--

Autor: Andi ... (xaos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
einfach nen ISP programer anschließen und gut..kaputtgehen wird der 
durch deinen code nicht..evtl aber durch angeschlossene hardware...poste 
mal einen schaltplan..

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
#define F_CPU=8000000UL

das würde ich in
#define F_CPU 8000000
umändern

Gruß Bro

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Brocken Sei schrieb:
>
> #define F_CPU=8000000UL
> 
>
> das würde ich in
>
>
> #define F_CPU 8000000
> 
> umändern

Lass es auf UL.
Im schlimmsten Fall handelst du dir ohne UL seltsame Fehler ein. Im 
besten Fall macht es keinen Unterschied.

Was aber einen Unterschied macht:
#include <avr/io.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include <stdint.h>

#define F_CPU=8000000UL

delay.h ist darauf angewiesen, dass F_CPU schon definiert ist, wenn es 
inkludiert wird. Also wenn schon, dann ...
#define F_CPU 8000000UL

#include <avr/io.h>
#include <avr/pgmspace.h>
#include <util/delay.h>
#include <stdint.h>

... F_CPU definieren, ehe ein Header inkludiert wird, der F_CPU benötigt 
(in deinem Fall delay.h). Und das #define schreibt sich ohne = (nächstes 
mal mehr Sorgfalt beim Abschreiben)


> Beim Versuch das LED Fading-Tutorial leicht angepasst zu flashen hab
> ich mir bereits einen Atmega8 zerstört.

Du hast dir deinen Controller ziemlich sicher nicht zerstört. Du hast 
einfach nur einen Programmfehler. Willkommen in der wunderbaren Welt der 
Programmierung, die uns Menschen jeden Tag aufs neue zeigt, wie sorglos 
wir im täglichen Leben vertrauen dass unser menschliches Gegenüber 
unsere Logikfehler dank seiner Intelligenz ganz von alleine ausbügelt. 
Ganz im Gegensatz zu einem Computer, der einfach nur stur nach dem 
Buchstaben des Programmes vorgeht.

(Der ++ Fehler wurde ja schon angesprochen)

Autor: Brocken Sei (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Und das #define schreibt sich ohne = (nächstes
> mal mehr Sorgfalt beim Abschreiben)

Darum habe ich auch geantwortet.

Gruß Bro

Autor: Schockii (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Atmega 8 hat doch gar kein internen Taktgenerator der 8 Mhz erzeugt, 
es kann lediglich mit ca. 1Mhz arbeiten. Für alle höheren Takte wird ein 
externes Quarz oder ähnliches benötigt. Zieh dir mal das Datenblatt 
rein!!

Habe den Atmega 32 in einer Schaltung verbaut und da kann man das 
Interne nur auf ca. 1Mhz einstellen.

Gruß

Autor: Falk Brunner (falk)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@  Schockii (Gast)

>Der Atmega 8 hat doch gar kein internen Taktgenerator der 8 Mhz erzeugt,
>es kann lediglich mit ca. 1Mhz arbeiten.

Nicht so viel kiffen, locker bleiben, Brille putzen, 8 MHz einstellen.

>Habe den Atmega 32 in einer Schaltung verbaut und da kann man das
>Interne nur auf ca. 1Mhz einstellen.

Dito.

Kleiner Tip.

http://www.engbedded.com/fusecalc/

MfG
Falk

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine Anmerkung zum faden.

Wenn du das Ganze ein wenig flexibler gestalten willst nimm dir zum 
faden eine Geradengleichung als Basis. Sprich y=mx+n. Dann kannst du von 
jedem beliebigen Wert auf einen anderen faden und dabei auch noch die 
Zeit bestimmen :-)

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erst mal entschuldigung das ich so lange nicht geantwortet habe.

Also das
#define F_CPU=8000000UL
 hab nicht ich so geschrieben. Das hat meine IDE (Code::Blocks) 
generiert (mit =). Die Position dürfte in diesem Fall auch egal sein da 
Code::Blocks das extra unter Build Options -> Compiler Settings -> 
#defines einfügt, und ich das nur hier fürs Forum in die Source Datei 
eingefügt habe damit ihr die Frequenz kennt.

Das Source File ist übrigens komplett, nur ein paar kleinigkeiten wie 
die defines für Frequenz und AVR-Typ macht Code::Blocks an anderer 
stelle.

Aber die Controler lassen sich wie gesagt nicht mehr flashen. Wenn ich 
mit Burnomat irgend ein programm flashen will gibt er immer eine 
fehlermeldung aus und das Programm läuft dann auch nicht. Habe es auch 
schon mit einem anderen Controler versucht, ich kann zuerst ganz normal 
andere Programme flashen, aber sobald ich dieses flashe (mit 
unveränderter Hardware), bekomme ich eine Fehlermeldung und ich kann 
auch kein Programm mehr flashen das davor noch funktioniert hat.

Ich habe aber eine Idee woran es liegen könnte das das Programm nicht 
funtioniert. Muss ich für pwm an Port 21 (AREF) +5V, und Port 22 (GND) 
Masse anlegen? Aber das kann doch nicht die probleme beim flashen 
verursachen, oder? Hab den Controler und die Programierausrüstung grad 
nicht in Reichweite deswegen kann ichs leider derzeit nicht ausproberen.

mfg
zigarrre

Autor: roboter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...Habe den Atmega 32 in einer Schaltung verbaut und da kann man das
Interne nur auf ca. 1Mhz einstellen.....

He, den 32ziger kannste Intern auf 8Mhz legen.

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, hab mich jetzt wieder einmal mit meiner Schaltung befasst.

Die Beschaltung sieht folgendermasen aus:

An Pin 1 ein 10k Wiederstand gegen VCC und der Reset anschluss meines 
Programmers
An Pin 7 VCC
An Pin 8 GND
Zwischen Pin 7 und Pin 8 einen 100nF Kondensator
An Pin 15 eine LED mit Vorwiederstand gegen GND
An Pin 17 den MOSI Anschluss meines Programmers
An Pin 18 den MISO Anschluss meines Programmers
An Pin 19 den SCK Anschluss meines Programmers
An Pin 20 VCC
An Pin 21 VCC
An Pin 22 GND
Zwischen Pin 21 und Pin 22 einen 100nF Kondensator

Habe leider keine 100nF Kondensatoren mehr deshalb kann ich zwischen Pin 
20 und GND leider keinen verbauen, aber das kann doch nicht so tragisch 
sein oder?

Wenn ich ein funktionierendes Programm auf einen Controler Flashen will 
auf den ich vorher mein LED-Fading Programm geflashed habe kommt 
folgende Ausgabe:
X:\WinAVR-20100110\bin\avrdude.exe -u -C X:\WinAVR-20100110\bin\avrdude.conf -p m8 -P usb -c usbasp -D -F -U flash:w:X:\zigarrre\programieren\blinken\bin\Release\blinken.elf.hex:a 

avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: error: programm enable: target doesn't answer. 1 
avrdude.exe: initialization failed, rc=-1
avrdude.exe: AVR device initialized and ready to accept instructions
avrdude.exe: Device signature = 0x000000
avrdude.exe: Yikes!  Invalid device signature.
avrdude.exe: Expected signature for ATMEGA8 is 1E 93 07

avrdude.exe done.  Thank you.

Als Programmer nutze ich das USB Avr Lab mit der USBasp_1.2 Firmware.

Als Spannungsversorgung nutze ich einen Spannungsregler der so wie im 
AVR-Tutorial beschalten ist und von eimen unstabilisierten Netzteil das 
~10,5 V liefert versorgt wird.

mfg
zigarrre

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Alfred P. (zigarrre)

>Die Beschaltung sieht folgendermasen aus:

Ohje! Schon mal was von einem Schaltplan gehört? Ein Bild sagt mehr als 
tausend Worte.

>Habe leider keine 100nF Kondensatoren mehr deshalb kann ich zwischen Pin
>20 und GND leider keinen verbauen, aber das kann doch nicht so tragisch
>sein oder?

DOCH!!! Die 100nF an Vcc/Gnd sind Pflicht. IMMER! Punkt!

>avrdude.exe: AVR device initialized and ready to accept instructions
>avrdude.exe: Device signature = 0x000000

Tja, deine AVR antwortet nicht, weil er entweder falsch angeschlossen 
ist oder durch den fehlenden 100nF sich verschlukt beim takten.

Ergo. Mach es richtig oder suh dir ein anderes Hobby.

MfG
Falk

Autor: Alfred P. (zigarrre)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>Ohje! Schon mal was von einem Schaltplan gehört? Ein Bild sagt mehr als
>tausend Worte.
Zufrieden?

>DOCH!!! Die 100nF an Vcc/Gnd sind Pflicht. IMMER! Punkt!
Ja schon, aber ich kann schwer etwas verbauen das ich nicht habe. Punkt! 
Auserdem kann das nicht der Grund dafür sein das man keine Programme 
mehr flashen kann, denn vorher habe ich an Pin 20-22 garnichts 
angeschlossen gehabt und es hat auch funktioniert.

>Ergo. Mach es richtig oder suh dir ein anderes Hobby.
Sehr freundlich!

mfg
zigarrre

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Alfred P. (zigarrre)

>Zufrieden?

Warum nicht gleich so?

>>DOCH!!! Die 100nF an Vcc/Gnd sind Pflicht. IMMER! Punkt!
>Ja schon, aber ich kann schwer etwas verbauen das ich nicht habe. Punkt!

Dann geht es halt nicht. In deinem Schaltplan sind zwei 100nF. Sind die 
nun echt vorhanden oder nicht?

>Auserdem kann das nicht der Grund dafür sein das man keine Programme
>mehr flashen kann, denn vorher habe ich an Pin 20-22 garnichts
>angeschlossen gehabt und es hat auch funktioniert.

Zufall. Oder du hast dir die AVR Fuses zerschossen, das ist auch 
eine beliebte Beschäftigung. ;-)

MfG
Falk

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>In deinem Schaltplan sind zwei 100nF. Sind die nun echt vorhanden oder nicht?
Ja, alles was im Schaltplan eingezeichnet ist ist auch vorhanden und 
verbaut. Und Zufall schließe ich aus, da das Problem nur nach dem 
Flashen dieses Programmes auftritt. Habs ja auch mit einem 2. Controler 
in der Selben Schaltung getestet.

>Zufall. Oder du hast dir die AVR Fuses zerschossen, das ist auch eine beliebte 
>Beschäftigung. ;-)
 Wie oben schon geschrieben habe ich nur den internen Oszilator auf 8Mhz 
getaktet und sonst nichts verändert. Fuses auslesen kann ich ja jetzt 
selbstverständlich auch nicht mehr. Ich hätte auch schon versucht so wie 
ich es irgendwo gelesen habe mit einem anderen Controler einen Takt zu 
generieren (Port in endlosschleife ein und ausschalten) und diesen als 
Taktquelle zu nutzen, aber das hat (wie erwartet) auch nichts gebracht, 
da ich ja nichts an der Taktquelle verändert habe.

Vieleicht noch relevant, ich verwende Burn-O-Mat zum Flashen.

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat den keiner eine Idee?

Ich werde jetzt einmal 100nF Kondensatoren kaufen gehen und dann mal 
überall wo einer hingehört einen verbauen. Keramikkondensatoren sind eh 
geeignet, oder?

mfg
zigarrre

Autor: Alfred P. (zigarrre)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe jetzt den fehlenden 100nF Kondensator eingebaut. Jetzt ist die 
Beschaltung so wie im angehengten Schaltbild. Zusätzlich habe ich noch 
ein Bild der Schaltung hochgeladen.

Flashen kann ich jedoch noch immer nicht. Deshalb schließe ich einen 
Hardwaredefekt jetzt fast aus (Ich wüsste zumindest nicht an was es 
sonnst liegen könnte).

Ich hoffe mir kann jetzt endlich jemand helfende Fehler zu finden, da 
ich auf der Suche nach dem Fehler nicht noch unmengen µC zerstören will.

mfg
zigarre

Autor: luke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sollten Kondensatoren sein mit einer möglichst kleinen parasitären 
Induktivität. Du kannst dazu was nachlesen unter: Abblockkondensator
Keramikkondensatoren kannst Du nehmen. Verlöte sie so nahe wie möglich 
an die Anschlusspins.

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja sind eh Keramikkondensatoren. Mit Löten wirds aber fürcht ich nix 
werden am Steckbrett. Aber an den Kondensatoren kanns nicht leigen, den 
ich hab jetzt an jeden Pin an den VCC angeschlossen wird einen 
Kondensator gegen GND angeschlossen.

Meiner Meinung nach leigts an der Software, aber an der kanns ja laut 
Andi D. nicht liegen.

Ich hab jetzt noch mal den Source überarbeitet, ihr findet ihn im 
Anhang.

Kann es vieleicht an der Endlosschleife liegen?:
for(tmp = 31; tmp>=0; tmp++) {
        OCR2 = pgm_read_word(pwmtable_8+tmp);
        _delay_ms(50);
    }

Oder an
#define F_CPU=8000000UL
weil es mit = ist?

Oder weil Code::Blocks vieleicht das define nach den includes einfügt? 
Hab das jetzt mal manuel davor geschrieben und das einfügen von 
Code::Blocks deaktiviert.

Hab diese Fehler jetzt einmal alle behoben aber ich will nicht noch 
einen Controler riskieren sollange ich nicht weiß ob das Problem damit 
beseitig ist.

Außerdem würde es mich interessieren ob un wenn ja wie ich meine 2 
Controler wiederherstellen kann. Und sie lassen sich definitiv nicht 
mehr flashen, mit Prograsmmen die auf neuen einwandfrei funktionieren. 
Außerdem lassen sich weder Fuses lesen noch schreiben und auch das 
derzeitige Programm nicht auslesen.

mfg
zigarrre

Autor: Alfred P. (zigarrre)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sry, hab Anhang vergessen und der lässt sich durch bearbeiten nicht mehr 
anfügen.

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am C-Programm liegt es nicht. An der Hardware - vielleicht.

Bevor Du irgendwas programmierst, solltes Du erst mal eine Verbindung 
vom Brenner zum Controller herstellen, die Signatur auslesen und die 
Fuses lesen.

Und DANN erst die neuen Fuse-Einstellungen schreiben. Danach 
programmieren (*.hex-File und *.eep-File).

Blackbird

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es liegt definitiv an der Software. Ich habe gerade noch einmalversuch 
ein anderes funktionierendes Programm auf einen neuen Controller zu 
flashen und es funktioniert. Bei beiden Controlern auf die ich das 
LedFading programm geflashed habe (das alte aus dem ersten Beitrag), 
kann ich das funktionierende jedoch nciht flashen. Burn O Mat bricht 
immer mit dem Fehler "programm enable: target doesn't answer. 1" ab. 
Auserdem bekomme ich folgende Warnung (auch bei einem neuen Controler): 
"cannot set sck period. please check for usbasp firmware update.". Habe 
aber die neueste Software vom AVR Lab.

Das kann doch nicht sein das ich einen Fehler habe den noch nie jemand 
hatte und das keiner weiß woran das liegt.

mfg
zigarrre

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alfred P. schrieb:
> Es liegt definitiv an der Software.

Völlig unmöglich.
Du kannst kein Programm schreiben, mit dem du einem Mega8 die ISP Pins 
abdrehst.
Das geht nur über die Fuses und an die kommst du aus dem laufenden 
Programm so nicht ran.

Es muss irgendwas beim Brennen des Programms in den µC sein.

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit dem USB AVR Lab, der USBasp_1.2 Firmware AVRdude und Burn O 
Mat geflashed.

Code::Blocks hat ein "LedFading.elf.hex" und ein "LedFading.elf.eep.hex" 
file erstellt. Das "LedFading.elf.hex" habe ich in den Flash 
geschrieben. In den eeprom hab ich nichts geschrieben (und das ging 
dannach auch gar nicht mehr).

Ich habe es jetzt auch einmal mit der AVRISPmkII Firmware und AVR-Studio 
versucht, selbes Problem. Jeglicher Zugriff auf den µC bricht mit der 
Fehlermeldung "A problem occured when executing the command...." ab.

mfg
zigarrre

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Am C-Programm liegt es nicht.

Es gab mal einen Fall bei dem die C-Source für den falschen AVR 
übersetzt wurde. Ich weiss aber nicht mehr ob nur die normale Funktion 
oder auch die ISP-Programmierung betroffen war.

Durch die Kontrolle der HEX-Datei ist der falsche Target AVR 
aufgefallen. Die Kontrolle bestand darin die HEX-Datei in den Simulator 
des AVR Studios zu laden und dort kritisch zu beäugen, ob sie das macht 
was im C-Code stand.

In deinem Fall könntest du uns die kritische HEX-Datei hochladen 
und/oder die Kommandozeile inkl. Ausgabe des Kompilerlaufs anzeigen.

Die unabhängige Kontrolle vorm Flashen würde jedenfalls das Risiko für 
den nächsten AVR etwas senken.

Allerdings müsste ich mich stark anstrengen, um einen Weg zu überlegen, 
welche Bitfolgen in einem falschen Binärcode einen AVR schrotten 
könnten. Insbesondere wenn nur die ISP Pins und ggf. die Fading-LED 
angeschlossen sind.

Es wäre interessant, ob man die jetzt stummen AVRs noch mal zur 
Mitarbeit überreden kann, z.B. mit einem HV-Programmer. Leider habe ich 
keinen solchen, sonst hätte ich dir angeboten "rein zu schauen"

Autor: Alfred P. (zigarrre)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das sind alle Files die von Code::Blocks erstellt werden (Ich wusste 
nicht welche genau du brauchst) und noch einmal der Sourcecode.

Das Build-Log:
-------------- Clean: Release in LedFading ---------------

Cleaned "LedFading - Release"

-------------- Build: Release in LedFading ---------------

Compiling: main.c
Linking console executable: bin\Release\LedFading.elf
Output size is 1,93 KB
Running project post-build steps
avr-objcopy -O ihex -R .eeprom -R .eesafe bin\Release\LedFading.elf bin\Release\LedFading.elf.hex
avr-objcopy --no-change-warnings -j .eeprom --change-section-lma .eeprom=0 -O ihex bin\Release\LedFading.elf bin\Release\LedFading.elf.eep.hex
cmd /c "avr-objdump -h -S bin\Release\LedFading.elf > bin\Release\LedFading.elf.lss"
Process terminated with status 0 (0 minutes, 2 seconds)
0 errors, 0 warnings

Außerdem habe ich festgestellt das unter "Other Linker Options" in 
Code::Blocks folgendes eingetragen ist:
-mmcu=atmega8
-Wl,-Map=$(TARGET_OUTPUT_FILE).map,--cref

Ich hoffe das reicht an Informationen damit du mir helfen kannst.

Einen HV-Programmer kann ich vieleicht auftreiben, wenn du mir sagst was 
ich damit machen muss kann ich versuchen mir einen auszuborgen und das 
zu machen.

mfg
zigarre

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auf den ersten oberflächlichen Blick sieht das richtig aus. In der MAP 
Datei ist das richtige Target Atmega8 (m8) erkennbar. Trotzdem werde ich 
heute abend der Sache im Simulator nach gehen.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider kann ich nix grundsätzlich problematisches erkennen.

Dein Programm hat zwar einen Fehler, es wird PB2 auf Ausgang gesetzt 
aber die PWM läuft auf OC2, d.h. PB3 müsste auf Ausgang sein damit es 
faded...

Jedoch ohne die Fehlerkorrektur als auch mit Fehlerkorrektur 
funktioniert mein Atmega8 auch nach dem Flashen noch.

Woran kann es sonst noch hängen?

Eventuell an einer Kommandozeile für das Flashprogramm bei dem außer dem 
Flashen auch noch falsche Fuses gesetzt werden (Klassiker external 
Clock). Wie genau hast du das Flashen gemacht?

Eventuell an einer falsch angeschlossenen LED ohne korrektem 
Vorwiderstand und einer Überlastung des Atmega8.

Hast du die LED noch montiert, wenn du versuchst ein neues Programm 
aufzuspielen? Wenn ja, entferne die LED und ihren Vorwiderstand wenn du 
einen ISP Programmierversuch machst.

Ansonsten bin ich ratlos.

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Erstmal danke für deine bisherigen Mühen!

Ich habe mit avrdude aus WinAVR (mit Burn-O-Mat v2 als GUI) unter 
Windows XP und dem USB AVR Lab 
(http://wiki.ullihome.de/index.php/USBAVR-ISP/de) mit der USBasp 
Firmware als ISP geflashed. Dazu habe ich zuerst den internen Takt per 
Fuses auf 8.0Mhz geändert (sonst habe ich nichts verändert) und die 
Fuses geschrieben. Anschließend habe ich unter Flash das 
"LedFading.elf.hex" File ausgewählt und per klick auf write geschrieben. 
Das hat noch funktioniert, aber da das Programm nicht funktioniert hat 
wollte ich es nach einer kleinen Korektur (bei der ich wie man sieht 
noch immer genügend übershen habe) noch einmal flashen und habe dabei 
bemerkt das es nicht mehr funktioniert. Die Led war mit korektem 
Vorwiederstand gegen GND beim flashen angeschlossen.

Mir fällt ein ich hatte einmal einen Kurzschluss (die 10V VCC vom 
Netzteil kommend direkt in die 5V Reihe am Steckbrett gesteckt, was den 
Spannungsregler ganz schön erhitzt hat. Das war aber nachdem der 
Controller nicht mehr funktioniert hat (Ich nehme an den Controler der 
dabei verbaut war kann ich jetzt sowiso vergessen, oder?). Nachdem ich 
sofort als ich es bemerkt habe, ausgesteckt habe und den Spannungsregler 
auskühlen hab lassen funktionierte der Spannungsregler aber wieder 
(liefert laut Voltmeter 5V).

Wenn du gegen meinen Flashvorgang nichts auszusetzten hast werde ich 
nach ausbesserung des von dir entdeckten Fehlers noch einen Flashversuch 
starten.

Funktioniert das Faden bei dir eigentlich?

mfg
zigarrre

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das faded so vor sich hin. LED ebenfalls mit Vorwiderstand gegen GND. 
Der Leuchteffekt ist nicht so prall aber es geht.

Du musst nicht auf 8 MHz umstellen sondern du kannst erstmal die [[AVR 
Fuses]] in Ruhe lassen, um diese Fehlerquelle (s.o.) auszuschliessen.

Dafür dann F_CPU auf 1000000 anpassen und den Prescaler bei der PWM um 8 
kleiner setzen. 128/8 = 16. Wenn du 16 laut Datenblatt nicht setzen 
kannst, dann 8 (schneller) oder 32 (langsamer).

> Mir fällt ein ich hatte einmal einen Kurzschluss (die 10V VCC vom
> Netzteil kommend direkt in die 5V Reihe am Steckbrett gesteckt, was den
> Spannungsregler ganz schön erhitzt hat.

Übel. Der µC dürfte das nicht überlebt haben.

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es funktioniert!

Ich habe einfach wie du gesagt hast die Taktfreqenz bei 1Mhz belassen 
und den Prescaler auf 32 gesetzt (hatte vorher 256 und nicht 128 also 
256/8=32).

Noch einmal Danke an alle für die Hilfe!

Der Fading Effekt ist nicht schlecht aber so ganz zufrieden bin ich 
damit noch nicht.

Mein erster Kritikpunkt war das die LED nicht ganz ausgeht, aber das 
habe ich gleich mit einem
TCCR2 = 0;
am Ende der fadeOut() Funktion gelöst gehabt.

Aber irgendwie kommt mir vor das das Faden nicht ganz gleichmäßig ist. 
Es wird beim einfaden irgendwie zuerst langsam hell aber dann immer 
schneller. Ich muss mir nochmal die genaue Funktionsweiße von pwm 
ansehen, das hab ich noch nicht ganz verstanden und das dann noch mal 
überarbeiten.

Außerdem kommt mir vor das die LED beim ausfaden ein wenig flackert. 
Liegt das an einer zu niedrigen Fading-Auflösung oder müsste ich da das 
pwm Signal glätten?

Verbesserungsvorschläge sind natürlich immer wilkommen.

mfg
zigarrre

Autor: Blackbird (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Damit weißt Du aber immer noch nicht genau, warum Du 2 Megas gehimmelt 
hast.

Meine Vermutung sind die Fuses, die Du bisher im gutem Glauben falsch 
gesetzt hattest und jetzt beim 3. Mega nicht angefaßt hast?

Blackbird

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe die Fuses ganz sicher nicht zerschoßen. Ich habe nur mit der 
GUI von Burn-O-Mat den internen Takt auf 8Mhz gesetzt. Wenn dann war das 
ein Bug von Burn-O-Mat.

Autor: Gerd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
wie kann man den internen takt auf 8MHz setzen? Dazu müssen doch die 
Fuses anders gesetzt werden!

Autor: Alfred P. (zigarrre)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, und? Das kann man auch mit Burn-O-Mat machen und deswegen ist der µC 
auch nicht gleich kaput!

Autor: Christian B. (luckyfu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei deinem Brennproblem kann ich dir leider nicht helfen Aber hierbei:

Alfred P. schrieb:
> Aber irgendwie kommt mir vor das das Faden nicht ganz gleichmäßig ist.
> Es wird beim einfaden irgendwie zuerst langsam hell aber dann immer
> schneller. Ich muss mir nochmal die genaue Funktionsweiße von pwm
> ansehen, das hab ich noch nicht ganz verstanden und das dann noch mal
> überarbeiten.

das liegt nicht an der PWM sondern an deinem Auge!
Ähnlich wie bei Tönen das Ohr hat dein Auge ein logarithmisches 
Verhalten, Du musst dieses ausgleichen, indem du nicht linear fadest 
sondern eine Logarithmusfunktion zu Grunde legst.
Dazu nimmst du dir am besten ein Array mit zum Beispiel 45 Werten die du 
vorher ausrechnest und dann jeweils als Reloadwert für die pwm an den 
Timer übergibst. So kann man gefühlt linear dimmen, allerdings brauchst 
du recht viele Stützstellen um im dunklen Bereich "ruckelfrei" zu 
dimmen. Ich hab sowas bei mir schon realisiert, was dir die Berechnung 
erspart (ist allerdings nicht ganz ruckelfrei, dafür aber halbwegs 
gleichmäßig):
char Logarithmustabelle[45]=
{
  3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
  13, 15, 16, 17, 19, 21, 23, 25, 27, 29,
   32, 35, 38, 41, 45, 49,  54, 58, 64, 70,
  76, 83, 90, 98, 107, 117, 127, 139, 152, 165, 
  180, 196, 214, 234, 254
};

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Der TO hatte auch schon eine nicht lineare PWM Tabelle, allerdings mit 
weniger Stufen (32 statt 45), s. Anhang

Mich würde interessieren, wie man diese PWM-Werte im Programm schneller 
als in 50 ms berechnen kann. <50ms, weil im Programm eh eine 
Warteschleife drin ist:
 
  for(...) 
  {
    OCR2 = pgm_read_word(pwmtable_8+tmp);
    _delay_ms(50);
  }

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Stefan B. (stefan) Benutzerseite

>Mich würde interessieren, wie man diese PWM-Werte im Programm schneller
>als in 50 ms berechnen kann.

Warum willst du die berechnen? Einfacher und scheller als ein Tabelle 
wird es nicht.

MFG
Falk

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rein akademisches Interesse, weil ich keine Idee habe, wie schnell ein 
AVR sowas rechnen könnte. Hätte ja sein können, dass jemand das zufällig 
schon gemacht hat.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Stefan B. (stefan) Benutzerseite

>Rein akademisches Interesse, weil ich keine Idee habe, wie schnell ein
>AVR sowas rechnen könnte. Hätte ja sein können, dass jemand das zufällig
>schon gemacht hat.

Gabs mal einen Thread, Ergebnis wie erwartet, rein akademisch ;-)

Beitrag "Erweiterung zum Artikel LED Fading"

MfG
Falk

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan B. schrieb:
> Rein akademisches Interesse, weil ich keine Idee habe, wie schnell ein
> AVR sowas rechnen könnte. Hätte ja sein können, dass jemand das zufällig
> schon gemacht hat.


Gibt ne einfache Möglichkeit:
Schreib dir ein Programm (brauchst ja nur die Berechnung), geh in den 
Simulator, stell deine Taktfrequenz ein, breakpoint vor den Code, 
Simulator-Zeitpunkt aufschreiben. Breakpunkt nach die Berechnung, wieder 
die Simualtor-Zeit aufschreiben, voneinander abziehen und du weißt wie 
lange es dauert.


Und die 50ms.
vergiss sie am besten gleich wieder.
Die waren im Vorlage-Programm, weil es dem Autor auf das Faden bzw. die 
nichtlineare Kennlinie ankam und er sich nicht mit dem Rest rumschlagen 
wollte (zb Timersteuerung) um nicht das in diesem Artikel Wichtige zu 
verschleiern.
In einem realen Fading-Programm, vielleicht auch noch mit 20 LED, wird 
man sowieso keine 50ms delays machen. Schon gar nicht in einer Schleife.

Autor: me (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Alfred P. (zigarrre)
> hab ich mir bereits einen Atmega8 zerstört.
nur als Tip: (falls kein HV-Programmer verfügbar ist)
http://diy.elektroda.eu/atmega-fusebit-doctor-hvpp/
Habe ich mir gebaut. Funktioniert einwandfrei.

Autor: Stefan B. (stefan) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:

> Gibt ne einfache Möglichkeit:
> Schreib dir ein Programm (brauchst ja nur die Berechnung), geh in den

Klar, werde ich auch mal machen. Danke an Falk für den Link. Die 
Berechnung wird vermutlich aufwändiger, weil 3 Taylorelemente 
anscheinend zu grob sind.

Autor: DJManuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MMM

http://mdiy.pl/atmega-fusebit-doctor-hvpp/

Der Beitrag :D würde ich vlt. machen wenns deutsch wäre :) Ist aber 
erstaunlich, dass nach ungefähr 4Jahren dieser Link noch funktioniert, 
meistens ist es in Foren so, dass die Links schon nach kurzer zeit nicht 
mehr funktionieren :)

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.