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
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--
einfach nen ISP programer anschließen und gut..kaputtgehen wird der
durch deinen code nicht..evtl aber durch angeschlossene hardware...poste
mal einen schaltplan..
> 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:
1
#include<avr/io.h>
2
#include<avr/pgmspace.h>
3
#include<util/delay.h>
4
#include<stdint.h>
5
6
#define F_CPU=8000000UL
delay.h ist darauf angewiesen, dass F_CPU schon definiert ist, wenn es
inkludiert wird. Also wenn schon, dann ...
1
#define F_CPU 8000000UL
2
3
#include<avr/io.h>
4
#include<avr/pgmspace.h>
5
#include<util/delay.h>
6
#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)
Karl heinz Buchegger schrieb:> Und das #define schreibt sich ohne = (nächstes> mal mehr Sorgfalt beim Abschreiben)
Darum habe ich auch geantwortet.
Gruß Bro
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ß
@ 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
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 :-)
Erst mal entschuldigung das ich so lange nicht geantwortet habe.
Also das
1
#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
...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.
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:
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
4
avrdude.exe: error: programm enable: target doesn't answer. 1
5
avrdude.exe: initialization failed, rc=-1
6
avrdude.exe: AVR device initialized and ready to accept instructions
7
avrdude.exe: Device signature = 0x000000
8
avrdude.exe: Yikes! Invalid device signature.
9
avrdude.exe: Expected signature for ATMEGA8 is 1E 93 07
10
11
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
@ 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
>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
@ 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
>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.
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
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
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.
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?:
1
for(tmp=31;tmp>=0;tmp++){
2
OCR2=pgm_read_word(pwmtable_8+tmp);
3
_delay_ms(50);
4
}
Oder an
1
#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
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
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
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.
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
>> 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"
Process terminated with status 0 (0 minutes, 2 seconds)
15
0 errors, 0 warnings
Außerdem habe ich festgestellt das unter "Other Linker Options" in
Code::Blocks folgendes eingetragen ist:
1
-mmcu=atmega8
2
-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
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.
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.
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
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.
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
1
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
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
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.
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):
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:
@ 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
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.
@ 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
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.
@ 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.
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.
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 :)
Thread beobachten
Seitenaufteilung abschalten
